From noreply@sourceforge.net  Wed Aug  1 00:18:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Jul 2001 16:18:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-446602 ] Large File Support for Linux
Message-ID: <E15Rim3-000863-00@usw-sf-web3.sourceforge.net>

Bugs item #446602, was opened at 2001-07-31 16:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446602&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick Day (pday)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Large File Support for Linux

Initial Comment:
In section 8.1.1 (Large File Support) of the Python
Library Reference a method of activating large file
support in Linux was described as follows:

CC="-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
export CC
./configure

This does not work. I think what was meant was
something like:

CC="gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
export CC
./configure


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

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


From noreply@sourceforge.net  Wed Aug  1 00:31:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Jul 2001 16:31:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-446551 ] profiler invents error in nested scopes
Message-ID: <E15Riyk-0008Fg-00@usw-sf-web3.sourceforge.net>

Bugs item #446551, was opened at 2001-07-31 13:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446551&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: W. G. Mitchener (caeshmer)
>Assigned to: Jeremy Hylton (jhylton)
Summary: profiler invents error in nested scopes

Initial Comment:
I'm trying to use the profiler in the Python 2.1 RPM on
Red Hat 7.0.

Here's the most reduced form of problem I could come up
with.  This is the file ProfilerBug.py:

from __future__ import nested_scopes

class Spam:

    def __init__(self, x, y, z):
        eggs = (self, x, y, z)
        a = 4
        b = 5
        c = 6
        def f(t):
            return a + b + c + t


def _test1():
    pr = Spam(1, 2, 3)

If I do this:

Python 2.1 (#1, Jul 13 2001, 10:27:46) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import ProfilerBug
>>> ProfilerBug._test1()
>>> 

there's no error.  But here's what I get when I run the
profiler:

Python 2.1 (#1, Jul 13 2001, 10:27:46) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import ProfilerBug
>>> profile.run('ProfilerBug._test1()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.1/profile.py", line 356, in run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.1/profile.py", line 362, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "ProfilerBug.py", line 15, in _test1
    pr = Spam(1, 2, 3)
  File "ProfilerBug.py", line 6, in __init__
    eggs = (self, x, y, z)
UnboundLocalError: local variable 'self' referenced
before assignment

It has something to do with nested scopes, because if I
comment out the definition of f, the error goes away.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-31 16:31

Message:
Logged In: YES 
user_id=6380

Sounds like one for Jeremy.  Have you tried this with the
bugfix release 2.1.1 yet?

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

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


From noreply@sourceforge.net  Wed Aug  1 03:21:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Jul 2001 19:21:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-446645 ] rexec and function attributes
Message-ID: <E15Rldv-0004rq-00@usw-sf-web1.sourceforge.net>

Bugs item #446645, was opened at 2001-07-31 19:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446645&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Brecknell (brecknell)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec and function attributes

Initial Comment:
The behaviour of the rexec module seems to be 
inconsistent with respect to function attributes. The 
function attribute dictionary is read-only in the 
restricted environment until you go and write to it 
outside the restricted environment. After that, the 
dictionary becomes writable in the restricted 
environment too. See the following examples:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> def f(): pass
... 
>>> r.modules['__main__'].f = f
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Or, looking at it another way:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> r.r_exec("def f(): pass")
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f = r.modules['__main__'].f
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Please don't abuse me too much for still being on 
Python 2.1, since I haven't had time to try 2.1.1 or 
2.2a1! If I don't put this in now, I'll forget. I'm 
guessing that neither rexec nor function attributes 
are widely used, so not too many people would have 
come across this. If I get more time down the track, 
I'll look into it further.

Regards,
Matt.


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

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


From noreply@sourceforge.net  Wed Aug  1 07:02:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 31 Jul 2001 23:02:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-446671 ] configure ignores --mandir
Message-ID: <E15Rp5o-0004ep-00@usw-sf-web3.sourceforge.net>

Bugs item #446671, was opened at 2001-07-31 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446671&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure ignores --mandir

Initial Comment:
Actually, Makefile.in (in various places) ignores the 
--mandir configuration option to configure.

As such, man pages are always installed under 
$(PREFIX)/man regardless of what the user 
specifies.

(I have noticed that an awful lot of GNU packages 
have a similar bug.  Yet, a few BSD derived 
operating systems like man pages to be installed 
in /usr/local/share/man/)

b.bum


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

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


From noreply@sourceforge.net  Wed Aug  1 14:30:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 06:30:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-446671 ] configure ignores --mandir
Message-ID: <E15Rw4a-0003Mi-00@usw-sf-web3.sourceforge.net>

Bugs item #446671, was opened at 2001-07-31 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446671&group_id=5470

Category: Build
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure ignores --mandir

Initial Comment:
Actually, Makefile.in (in various places) ignores the 
--mandir configuration option to configure.

As such, man pages are always installed under 
$(PREFIX)/man regardless of what the user 
specifies.

(I have noticed that an awful lot of GNU packages 
have a similar bug.  Yet, a few BSD derived 
operating systems like man pages to be installed 
in /usr/local/share/man/)

b.bum


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 06:30

Message:
Logged In: YES 
user_id=6380

I'm not sure who's to blame.  I've never even heard of
--mandir.  Unclear whether it's a bug.  If someone feels
like fixing this, let them go ahead, but I don't see this as
a priority unless you provide a good motivating example as
to why you would need this.

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

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


From noreply@sourceforge.net  Wed Aug  1 17:21:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 09:21:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-446671 ] configure ignores --mandir
Message-ID: <E15RykK-0001R6-00@usw-sf-web3.sourceforge.net>

Bugs item #446671, was opened at 2001-07-31 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446671&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure ignores --mandir

Initial Comment:
Actually, Makefile.in (in various places) ignores the 
--mandir configuration option to configure.

As such, man pages are always installed under 
$(PREFIX)/man regardless of what the user 
specifies.

(I have noticed that an awful lot of GNU packages 
have a similar bug.  Yet, a few BSD derived 
operating systems like man pages to be installed 
in /usr/local/share/man/)

b.bum


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 09:21

Message:
Logged In: NO 


The option is in configure within the 2.2 source, is a 
standard part of autoconf, and is easy to support.   A lot 
of GNU programs are starting to do so.

As well, there are a handful of systems that have the 
man pages split away from the binary/library/includes.

I'll try and generate/submit the appropriate patch.




[localhost:/tmp/Python-2.2a1] bbum% ./configure --help
Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
  --cache-file=FILE       cache test results in FILE
  --help                  print this message
  --no-create             do not create output files
  --quiet, --silent       do not print `checking...' messages
  --version               print the version of autoconf that 
created configure
Directory and file names:
  --prefix=PREFIX         install architecture-independent 
files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent 
files in EPREFIX
                          [same as prefix]
  --bindir=DIR            user executables in DIR [EPREFIX/
bin]
  --sbindir=DIR           system admin executables in DIR 
[EPREFIX/sbin]
  --libexecdir=DIR        program executables in DIR 
[EPREFIX/libexec]
  --datadir=DIR           read-only architecture-
independent data in DIR
                          [PREFIX/share]
  --sysconfdir=DIR        read-only single-machine data in 
DIR [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-
independent data in DIR
                          [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data 
in DIR [PREFIX/var]
  --libdir=DIR            object code libraries in DIR 
[EPREFIX/lib]
  --includedir=DIR        C header files in DIR [PREFIX/
include]
  --oldincludedir=DIR     C header files for non-gcc in 
DIR [/usr/include]
  --infodir=DIR           info documentation in DIR [PREFIX/
info]
  --mandir=DIR            man documentation in DIR 
[PREFIX/man]
  --srcdir=DIR            find the sources in DIR [configure 
dir or ..]
  --program-prefix=PREFIX prepend PREFIX to installed 
program names
  --program-suffix=SUFFIX append SUFFIX to installed 
program names
  --program-transform-name=PROGRAM


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 06:30

Message:
Logged In: YES 
user_id=6380

I'm not sure who's to blame.  I've never even heard of
--mandir.  Unclear whether it's a bug.  If someone feels
like fixing this, let them go ahead, but I don't see this as
a priority unless you provide a good motivating example as
to why you would need this.

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

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


From noreply@sourceforge.net  Wed Aug  1 17:51:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 09:51:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-444842 ] array's buffer_info() -> length in bytes
Message-ID: <E15RzDA-0003AT-00@usw-sf-web1.sourceforge.net>

Bugs item #444842, was opened at 2001-07-26 08:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444842&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: array's buffer_info() -> length in bytes

Initial Comment:
In arraymodule.c, the array's method buffer_info() is
documented to return (address, length), where 'length'
is measured in bytes. Unfortunately, it currently
returns the number of items instead. It should be fixed.

Changing the return value could potentially break code
relying on the actual (undocumented) behavior. On the
other hand, merely changing the documentation to
'officialize' the bug would be a departure from
buffer_info()'s original goal to provide direct raw
memory access.

I think the bug should be fixed, with a note about the
different behavior of previous versions in the docs --
for maximum portability, users can always compute the
length in bytes separately as "len(a)*a.itemsize".
Current users of buffer_info() may already have noticed
the bug and used the above formula to get the length,
so their code won't break.
Fix: in arraymodule.c: array_buffer_info:

PyTuple_SET_ITEM(retval, 1,
PyInt_FromLong((long)(self->ob_size *
self->ob_descr->itemsize)));
The multiplication should not overflow (care was taken
about it at resize time).

Armin

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-01 09:51

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libarray.tex revision 1.30.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 09:07

Message:
Logged In: YES 
user_id=6380

Hm, perhaps buffer_info() should be deprecated?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 09:03

Message:
Logged In: YES 
user_id=6380

Boy what a mess.

There are two possibilities:

(a) essentially nobody uses this

(b) occasionally someone uses it

In case (a), fixing the code won't make a difference, so why
bother.

In case (b), fixing the code will break somebody's code.

So I see no choice but to fix the documentation.

Since the item size is readily available through the
a.itemsize attribute,
the actual buffer size is readily calculated as
len(a)*a.itemsize.

Reassigned to Fred for doc updates.  I'll fix the docstring.

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

Comment By: Tim Peters (tim_one)
Date: 2001-07-26 15:56

Message:
Logged In: YES 
user_id=31435

Assigned to Guido cuz it's a mess.  buffer_info() has 
worked this way since it was first checked in (about 4 
years ago).  Armin is right that it doesn't match the 
manual or the docstring, and the docs make more sense than 
what it actually does.  Dare we "break" this?  Does 
buffer_info() even serve a purpose now given that arrays 
also support the buffer interface?

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

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


From noreply@sourceforge.net  Wed Aug  1 17:57:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 09:57:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-446136 ] regex documentation
Message-ID: <E15RzJE-0003G2-00@usw-sf-web1.sourceforge.net>

Bugs item #446136, was opened at 2001-07-30 14:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446136&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: regex documentation

Initial Comment:
Python Library Reference:

In Contents_of_Module_re.html please add this example.
I think a lot
of people will benefit:

sub(...)

# '"foo"' --> 'foo'
def remove_quotation_mark(s):
   return re.sub('^"(.*)"$', "\1", s)
  

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-01 09:57

Message:
Logged In: YES 
user_id=3066

I don't think the specific example is very helpful, but an
example is needed.  I've added one and fixed some other re
module doc problems in Doc/lib/libre.tex revision 1.65.

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

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


From noreply@sourceforge.net  Wed Aug  1 18:00:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 10:00:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-446602 ] Large File Support for Linux
Message-ID: <E15RzMU-0003eH-00@usw-sf-web1.sourceforge.net>

Bugs item #446602, was opened at 2001-07-31 16:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446602&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Patrick Day (pday)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Large File Support for Linux

Initial Comment:
In section 8.1.1 (Large File Support) of the Python
Library Reference a method of activating large file
support in Linux was described as follows:

CC="-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
export CC
./configure

This does not work. I think what was meant was
something like:

CC="gcc -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"
export CC
./configure


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-01 10:00

Message:
Logged In: YES 
user_id=3066

This ias already been fixed.  The fix was released as part
of the Python 2.1.1 documentation package.

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

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


From noreply@sourceforge.net  Wed Aug  1 18:17:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 10:17:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-445749 ] Tutorial (5.6) "Smaller" means "lesser"
Message-ID: <E15Rzd8-0003Vn-00@usw-sf-web3.sourceforge.net>

Bugs item #445749, was opened at 2001-07-29 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445749&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Tutorial (5.6) "Smaller" means "lesser"

Initial Comment:
I would propose an addition to section 5.6 of the 
tutorial, to clarify that "smaller" in comparisons 
means "lesser".  To do so, I might recommend 
adding "(lesser)" after the precise and mathematically 
correct adjective "smaller", as in:

"If one sequence is an initial sub-sequence of the 
other, the shorter sequence is the smaller (lesser) 
one."



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-01 10:17

Message:
Logged In: YES 
user_id=3066

I've made the suggested change.
Checked in as Doc/tut/tut.tex revision 1.146.

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

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


From noreply@sourceforge.net  Wed Aug  1 18:47:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 10:47:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-446874 ] 2.2a1: constructors have no docstring
Message-ID: <E15S05o-0002ks-00@usw-sf-web2.sourceforge.net>

Bugs item #446874, was opened at 2001-08-01 10:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446874&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: constructors have no docstring

Initial Comment:
In 2.2a1 the constructors of the builtin types don't 
have docstrings:

>>> list.__init__
<slot wrapper '__init__' of 'list' objects>
>>> list.__init__.__doc__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'wrapper_descriptor' object has no 
attribute '__doc__'

If this can't be fixed, the documentation for the 
constructor arguments should be part of the docstring 
for the type object as it's done for list, but not for 
dictionary:
>>> print list.__doc__
list() -> new list
list(sequence) -> new list initialized from sequence's 
items
>>> print dictionary.__doc__
dictionary type

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

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


From noreply@sourceforge.net  Wed Aug  1 19:34:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 11:34:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__
Message-ID: <E15S0oz-00042M-00@usw-sf-web2.sourceforge.net>

Bugs item #442791, was opened at 2001-07-19 08:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: New style classes and __delitem__

Initial Comment:
And another one: New style class don't seem to support 
__delitem__:
----
class Foo(object):
   def __delitem__(self, key):
      print "__delitem__"

del Foo()[42]
----
This results in:
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
TypeError: object doesn't support item deletion
----
Changing the base class to dictionary results in:
----
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
KeyError: 42
----
but Foo.__delitem__ doesn't seem to be called.


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

>Comment By: Walter Dіrwald (doerwalter)
Date: 2001-08-01 11:34

Message:
Logged In: YES 
user_id=89016

I checked out the descr-branch and it seems that dictionary 
still doesn't support __delitem__:

>>> x = {}
>>> dictionary.__setitem__(x, 1, 1)
>>> x
{1: 1}
>>> dictionary.__delitem__(x, 1)     
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: type object 'dictionary' has no 
attribute '__delitem__'


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 09:36

Message:
Logged In: YES 
user_id=6380

Whoops, you found a whole slew of bugs in this area!

I've fixed this now in the descr-branch of the CVS tree, in
Object/typeobject.c:2.16.8.69.

I've also added a bit to the test suite that checks these
(and slices).

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

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


From noreply@sourceforge.net  Wed Aug  1 20:53:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 12:53:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-446551 ] profiler invents error in nested scopes
Message-ID: <E15S23e-0001xD-00@usw-sf-web1.sourceforge.net>

Bugs item #446551, was opened at 2001-07-31 13:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446551&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: W. G. Mitchener (caeshmer)
Assigned to: Jeremy Hylton (jhylton)
Summary: profiler invents error in nested scopes

Initial Comment:
I'm trying to use the profiler in the Python 2.1 RPM on
Red Hat 7.0.

Here's the most reduced form of problem I could come up
with.  This is the file ProfilerBug.py:

from __future__ import nested_scopes

class Spam:

    def __init__(self, x, y, z):
        eggs = (self, x, y, z)
        a = 4
        b = 5
        c = 6
        def f(t):
            return a + b + c + t


def _test1():
    pr = Spam(1, 2, 3)

If I do this:

Python 2.1 (#1, Jul 13 2001, 10:27:46) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import ProfilerBug
>>> ProfilerBug._test1()
>>> 

there's no error.  But here's what I get when I run the
profiler:

Python 2.1 (#1, Jul 13 2001, 10:27:46) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import profile
>>> import ProfilerBug
>>> profile.run('ProfilerBug._test1()')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.1/profile.py", line 356, in run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.1/profile.py", line 362, in runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "ProfilerBug.py", line 15, in _test1
    pr = Spam(1, 2, 3)
  File "ProfilerBug.py", line 6, in __init__
    eggs = (self, x, y, z)
UnboundLocalError: local variable 'self' referenced
before assignment

It has something to do with nested scopes, because if I
comment out the definition of f, the error goes away.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 12:53

Message:
Logged In: YES 
user_id=31392

This appears to be fixed in 2.1.1.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-31 16:31

Message:
Logged In: YES 
user_id=6380

Sounds like one for Jeremy.  Have you tried this with the
bugfix release 2.1.1 yet?

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

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


From noreply@sourceforge.net  Wed Aug  1 21:00:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:00:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-446645 ] rexec and function attributes
Message-ID: <E15S2A3-0002Ox-00@usw-sf-web1.sourceforge.net>

Bugs item #446645, was opened at 2001-07-31 19:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446645&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Matthew Brecknell (brecknell)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: rexec and function attributes

Initial Comment:
The behaviour of the rexec module seems to be 
inconsistent with respect to function attributes. The 
function attribute dictionary is read-only in the 
restricted environment until you go and write to it 
outside the restricted environment. After that, the 
dictionary becomes writable in the restricted 
environment too. See the following examples:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> def f(): pass
... 
>>> r.modules['__main__'].f = f
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Or, looking at it another way:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> r.r_exec("def f(): pass")
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f = r.modules['__main__'].f
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Please don't abuse me too much for still being on 
Python 2.1, since I haven't had time to try 2.1.1 or 
2.2a1! If I don't put this in now, I'll forget. I'm 
guessing that neither rexec nor function attributes 
are widely used, so not too many people would have 
come across this. If I get more time down the track, 
I'll look into it further.

Regards,
Matt.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 13:00

Message:
Logged In: YES 
user_id=31392

You can see this behavior without using rexec.  The problem
you're seeing is that a function's __dict__ is None until
you set an attribute on the function.  Then the __dict__
slot is created and a new dictionary bound there.  The error
you see, which you attributed to rexec, is attempting to
execute f.__dict__["attr"] => None["attr"].

There are two policy questions here, which Barry can better
answer:

1. Should a function's __dict__ be accessible in restricted
mode?  A class's __dict__ is not, but it's a horse of a
different color.

2. Is it okay for __dict__ to occasionally return None?  I
don't think it is.  It's fine to be lazy about the creation
of __dict__, but it should be created as soon as it is
referenced.  Otherwise, any code that wants to use __dict__
should be prepared to deal with None.


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

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


From noreply@sourceforge.net  Wed Aug  1 21:01:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:01:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-446525 ] python 2.1 debug library missing _sre?
Message-ID: <E15S2B7-0002QH-00@usw-sf-web1.sourceforge.net>

Bugs item #446525, was opened at 2001-07-31 12:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470

>Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: python 2.1 debug library missing _sre?

Initial Comment:
I downloaded the most current python 2.1 debug library 
as follows:

Python-2.1-Debug.zip    16-Apr-2001 23:06   1.3M  ZIP 
archive

After initialization of the interpreter, a simple call 
like "PyRun_SimpleString("import re");" will return 
the following error:

Traceback (most recent call last):
...
  File "c:\python21\lib\sre_compile.py", line 11, in ?
    import _sre
ImportError: No module named _sre

By comparision, running the same code using the Python 
Release library gives no such problem.

Is this a bug? 

Much Thanks,
Hugo

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

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


From noreply@sourceforge.net  Wed Aug  1 21:20:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:20:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-446525 ] python 2.1 debug library missing _sre?
Message-ID: <E15S2TU-0008FC-00@usw-sf-web2.sourceforge.net>

Bugs item #446525, was opened at 2001-07-31 12:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: python 2.1 debug library missing _sre?

Initial Comment:
I downloaded the most current python 2.1 debug library 
as follows:

Python-2.1-Debug.zip    16-Apr-2001 23:06   1.3M  ZIP 
archive

After initialization of the interpreter, a simple call 
like "PyRun_SimpleString("import re");" will return 
the following error:

Traceback (most recent call last):
...
  File "c:\python21\lib\sre_compile.py", line 11, in ?
    import _sre
ImportError: No module named _sre

By comparision, running the same code using the Python 
Release library gives no such problem.

Is this a bug? 

Much Thanks,
Hugo

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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-01 13:20

Message:
Logged In: YES 
user_id=31435

Not enough info.  You downloaded the .zip file, and *then* 
what?  Did you unpack it?  If so, to where?  Note that the 
zip file is captured from a build tree, not a release tree.

Then what?  I don't know how you run your app, or how you 
compile it, or really anything else relevant.  Try running 
python_d with -vv to see *where* it's looking for _sre.  
Also try getting your own extensions out of the picture.

Note that I'm no longer going to ship the ...-Debug.zip 
file in 2.2, as tracking down misuses of it is a time 
sink.  If you want to build things in debug mode, much 
better to compile Python yourself from the source release.

In the meantime, if you want help with this, I'm afraid 
you're going to have attach enough files and info to this 
report so that I can reproduce your problem on my machine.


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

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


From noreply@sourceforge.net  Wed Aug  1 21:35:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:35:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-446874 ] 2.2a1: constructors have no docstring
Message-ID: <E15S2iI-0008Rf-00@usw-sf-web2.sourceforge.net>

Bugs item #446874, was opened at 2001-08-01 10:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446874&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: constructors have no docstring

Initial Comment:
In 2.2a1 the constructors of the builtin types don't 
have docstrings:

>>> list.__init__
<slot wrapper '__init__' of 'list' objects>
>>> list.__init__.__doc__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'wrapper_descriptor' object has no 
attribute '__doc__'

If this can't be fixed, the documentation for the 
constructor arguments should be part of the docstring 
for the type object as it's done for list, but not for 
dictionary:
>>> print list.__doc__
list() -> new list
list(sequence) -> new list initialized from sequence's 
items
>>> print dictionary.__doc__
dictionary type

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:35

Message:
Logged In: YES 
user_id=6380

Good catch!  Turns out wrapper descriptors do have
docstrings (albeit rather generic ones), but the necessary
things to extract these were omitted.  I've fixed this in
CVS now.

I'll fix the dictionary docstring when I've decided on the
signature.


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

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


From noreply@sourceforge.net  Wed Aug  1 21:53:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:53:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-445474 ] warn about import * inside functions
Message-ID: <E15S2zd-0002cI-00@usw-sf-web3.sourceforge.net>

Bugs item #445474, was opened at 2001-07-28 06:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445474&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Jeremy Hylton (jhylton)
Summary: warn about import * inside functions

Initial Comment:
According to the reference manual, import * is now only
allowed at the module level. This is not enforced. We
should add a warning for this.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 13:53

Message:
Logged In: YES 
user_id=31392

Do you really want to get a warning about this?  Last time
it came up, we discovered that you were the most common user
of this feature in Python.  Fredrik also said he used it a
lot, not surprising since the most common idiom is:

def test():
    from Tkinter import *



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

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


From noreply@sourceforge.net  Wed Aug  1 21:55:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:55:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S31A-0004Ej-00@usw-sf-web1.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
>Resolution: Works For Me
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Wed Aug  1 21:56:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 13:56:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-445474 ] warn about import * inside functions
Message-ID: <E15S332-0000zr-00@usw-sf-web2.sourceforge.net>

Bugs item #445474, was opened at 2001-07-28 06:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445474&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: warn about import * inside functions

Initial Comment:
According to the reference manual, import * is now only
allowed at the module level. This is not enforced. We
should add a warning for this.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:56

Message:
Logged In: YES 
user_id=6380

Yes, let's get this over with.

If I really hate it I'll rip it out myself, but more likely
I'll fix my code. :-)

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 13:53

Message:
Logged In: YES 
user_id=31392

Do you really want to get a warning about this?  Last time
it came up, we discovered that you were the most common user
of this feature in Python.  Fredrik also said he used it a
lot, not surprising since the most common idiom is:

def test():
    from Tkinter import *



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

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


From noreply@sourceforge.net  Wed Aug  1 23:00:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:00:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S42C-0004sU-00@usw-sf-web3.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:08:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:08:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S4Ak-0003d6-00@usw-sf-web2.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:12:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:12:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-445484 ] pickle lacks float('inf')
Message-ID: <E15S4Dy-0005ic-00@usw-sf-web3.sourceforge.net>

Bugs item #445484, was opened at 2001-07-28 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445484&group_id=5470

>Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Doggett (anthonydoggett)
>Assigned to: Tim Peters (tim_one)
Summary: pickle lacks float('inf')

Initial Comment:
Support for float('inf') still appears to be missing in

Python 2.1.1 (#1, Jul 28 2001, 14:15:01) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2

>>> cPickle.dumps(float('inf'), 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: frexp() result out of range
>>> pickle.dumps(float('inf'), 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 943, in dumps
    Pickler(file, bin).dump(object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 109, in dump
    self.save(object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 211, in save
    f(self, object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 273, in save_float
    self.write(BINFLOAT + pack('>d', object))
SystemError: frexp() result out of range


Both structmodule.c and cPickle.c require changes.
Surely something like 

  if (x == HUGE_VAL) {    /* Inf */
      e = 1024;
      f = 0.0;
  }
  else {
      f = frexp(x, &e);
      ...

and

  if (e == 1024)
      x = HUGE_VAL;		/* Inf */
  else {

is all that is required for all IEEE754 machines?

(structmodule.c requires similar changes for Float
also)

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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-445986 ] test_locale fails on IRIX 6.5
Message-ID: <E15S4Fi-0005kB-00@usw-sf-web3.sourceforge.net>

Bugs item #445986, was opened at 2001-07-30 08:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445986&group_id=5470

Category: Python Library
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: test_locale fails on IRIX 6.5

Initial Comment:
Built Python 2.2a1 on a 64-bit SGI box running IRIX
6.5.  test_locale fails as follows:

$ ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '     -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200      ' != '4,200     '


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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-445987 ] test_pty fails on IRIX 6.5
Message-ID: <E15S4Fh-0005k4-00@usw-sf-web3.sourceforge.net>

Bugs item #445987, was opened at 2001-07-30 08:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445987&group_id=5470

Category: Python Library
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: test_pty fails on IRIX 6.5

Initial Comment:
Built 2.2a1 on a 64-bit SGI box running IRIX 6.5. 
test_pty fails; here's the output from "make test":


test_pty
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
**********************************************************************
test_pty
**********************************************************************
Then ...
We expected (repr): 'I wish to buy a fish license.\nFor
my pet fish, Eric.\n'
But instead we got: 'I wish to buy a fish
license.\r\nFor my pet fish, Eric.\n'
test test_pty failed -- Writing: 'I wish to buy a fish
license.\r\nFor my pet fish, Eric.\n', expected: 'I
wish to buy a fish license.\nFor my pet fish, Eric.\n'

and here's what I get running the test script directly:
./python Lib/test/test_pty.py
Calling master_open()
Got master_fd '3', slave_name '/dev/ttyq7'
Calling slave_open('/dev/ttyq7')
Got slave_fd '4'
Writing to slave_fd
Writing chunked output
I wish to buy a fish license.
For my pet fish, Eric.
calling pty.fork()
Waiting for child (193150) to finish.
Child (193150) exited with status 4 (1024).

$ 


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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-445980 ] _socket fails to build on IRIX 6.5
Message-ID: <E15S4Fi-0005kO-00@usw-sf-web3.sourceforge.net>

Bugs item #445980, was opened at 2001-07-30 08:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445980&group_id=5470

Category: Extension Modules
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: _socket fails to build on IRIX 6.5

Initial Comment:
Building 2.2a1 on a 64-bit SGI box running IRIX 6.5.  I
 used the MIPSPro 7.30 compiler, using the "-n32" flag
("new 32-bit object").  Building the interpreter and
most extensions works, but creating _socket.so fails as
 follows:

ld -shared -all
build/temp.irix64-6.5-2.2/socketmodule.o
-L/usr/local/ssl/lib -L/usr/local/lib -lssl -lcrypto -o
build/lib.irix64-6.5-2.2/_socket.so
ld32: FATAL   12 : Expecting n32 objects:
/usr/local/ssl/lib/libssl.so is o32.
WARNING: building of extension "_socket" failed:
command 'ld' failed with exit status 4

I think this is a local configuration error, but the
build process should probably be more resilient to it.
At the very least, there should probably be a
--without-ssl configure option so linking against
OpenSSL can be disabled on systems with broken OpenSSL
installations (like this one).



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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-445991 ] test_struct dumps core on IRIX 6.5
Message-ID: <E15S4Fh-0005jx-00@usw-sf-web3.sourceforge.net>

Bugs item #445991, was opened at 2001-07-30 08:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445991&group_id=5470

Category: Extension Modules
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: test_struct dumps core on IRIX 6.5

Initial Comment:
Built 2.2a1 on a 64-bit SGI box running IRIX 6.5. 
test_struct dumps core:

$ /python Lib/test/test_struct.py
trying: xcbhilfd
trying: xcBHILfd
trying: @xcbhilfd
[...]
'f' 2.0 '@\x00\x00\x00' '\x00\x00\x00@'
'd' 2.0 '@\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00@'
'f' -2.0 '\xc0\x00\x00\x00' '\x00\x00\x00\xc0'
'd' -2.0 '\xc0\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00\xc0'
zsh: 193500 bus error (core dumped)  ./python
Lib/test/test_struct.py

Analyzing the coredump with dbx reveals:

$ dbx ./python core                                   
                                             
dbx version 7.3 MR 55458_Apr30_MR Apr 30 1999 13:44:41
Core from signal SIGBUS: Bus error
(dbx) where
>  0 np_longlong(0x101aaf8c, 0x1012c354, 0x5fff88fc,
0xc388060, 0x5, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Modules/structmodule.c":703,
0x5ffe304c]
   1 struct_pack(0x0, 0x1022ce6c, 0x0, 0xc388060,
0x101aaf8c, 0x5, 0x0, 0x1013d015)
["/tmp/Python-2.2a1/Modules/structmodule.c":1362,
0x5ffe50b0]
   2 call_cfunction(0x101a75a4, 0x1022ce6c, 0x0,
0xc388060, 0x5, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/ceval.c":3064, 0x1005d37c]
   3 eval_frame(0x101f55fc, 0x101f5748, 0x83,
0x101f5748, 0x10231b98, 0x10230ffa, 0x0, 0x0)
["/tmp/Python-2.2a1/Python/ceval.c":1913, 0x10058dec]
   4 PyEval_EvalCodeEx(0x10231b98, 0x10139924,
0x10139924, 0x0, 0x0, 0x0, 0x0, 0x0)
["/tmp/Python-2.2a1/Python/ceval.c":2518, 0x1005b59c]
   5 PyEval_EvalCode(0x10231b98, 0x10139924,
0x10139924, 0xc388060, 0x5, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/ceval.c":491, 0x10053590]
   6 run_node(0x1019ac50, 0x7fff3009, 0x10139924,
0x10139924, 0x7fff2df4, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/pythonrun.c":1057, 0x10062704]
   7 run_err_node(0x1019ac50, 0x7fff3009, 0x10139924,
0x10139924, 0x7fff2df4, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/pythonrun.c":1044,
0x10062660]   8 PyRun_FileExFlags(0xfb4e640,
0x7fff3009, 0x101, 0x10139924, 0x10139924, 0x1,
0x7fff2df4, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/pythonrun.c":1035, 0x100625e4]
   9 PyRun_SimpleFileExFlags(0xfb4e640, 0x7fff3009,
0x1, 0x7fff2df4, 0x5, 0x5, 0x0, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/pythonrun.c":672, 0x10060dc4]
   10 PyRun_AnyFileExFlags(0xfb4e640, 0x7fff3009, 0x1,
0x7fff2df4, 0x5, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Python/pythonrun.c":482, 0x1006037c]
   11 Py_Main(0x2, 0x7fff2ea4, 0x0, 0xfb4e640, 0x5,
0x0, 0x0, 0x0) ["/tmp/Python-2.2a1/Modules/main.c":320,
0x1000d378]
   12 ::main(0x2, 0x7fff2ea4, 0xfb4e3d8, 0xc388060,
0x5, 0x5, 0x8, 0x7fff27f7)
["/tmp/Python-2.2a1/Modules/ccpython.cc":10,
0x1000c7ec]   13 __start()
["/xlv55/kudzu-apr12/work/irix/lib/libc/libc_n32_M3/csu/crt1text.s":177,
0x1000c788]



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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-445984 ] test___all__ fails when _socket absent
Message-ID: <E15S4Fi-0005kI-00@usw-sf-web3.sourceforge.net>

Bugs item #445984, was opened at 2001-07-30 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445984&group_id=5470

Category: Python Library
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: test___all__ fails when _socket absent

Initial Comment:
If the _socket extension couldn't be built (see bug
#445980), test___all__ fails somewhat mysteriously:

$ ./python Lib/test/test___all__.py
Traceback (most recent call last):
  File "Lib/test/test___all__.py", line 42, in ?
    check_all("CGIHTTPServer")
  File "Lib/test/test___all__.py", line 10, in check_all
    exec "import %s" % modname in names
  File "<string>", line 1, in ?
  File "/tmp/Python-2.2a1/Lib/CGIHTTPServer.py", line
27, in ?
    import BaseHTTPServer
  File "/tmp/Python-2.2a1/Lib/BaseHTTPServer.py", line
72, in ?
    import SocketServer
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
273, in ?
    class TCPServer(BaseServer):
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
316, in TCPServer
    address_family = socket.AF_INET
AttributeError: 'module' object has no attribute 'AF_INET'



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 08:50

Message:
Logged In: YES 
user_id=6380

This can be "fixed" by inserting "import _socket" in front
of the check_all("socket") line.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:14:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:14:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-445960 ] Compiler warnings on IRIX 6.5
Message-ID: <E15S4Fi-0005kX-00@usw-sf-web3.sourceforge.net>

Bugs item #445960, was opened at 2001-07-30 07:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445960&group_id=5470

Category: Build
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Greg Ward (gward)
Summary: Compiler warnings on IRIX 6.5

Initial Comment:
Building 2.2a1 on IRIX 6.5 with the MIPSPro 7.30 C
compiler results in a handful of minor compiler
warnings.  Some of them are legit, some are compiler
stupidity.  I've just included the warnings here that
look legit to me, ie. it looks like the MIPSPro
compiler is catching an error.

cc-1552 cc: WARNING File = Python/import.c, Line = 857
The variable "f" is set but never used.

struct _frozen *f;
                ^

cc-1552 cc: WARNING File = Python/import.c, Line = 1379
  The variable "mod" is set but never used.

        PyObject *mod;
                    ^

[GW: both variables are only used in "(f = (...)) !=
NULL)" constructs,
 so it looks like the warning is legit and these
variables are unneeded]

cc-1552 cc: WARNING File =
/tmp/Python-2.2a1/Modules/xreadlinesmodule.c, Line = 
174
  The variable "m" is set but never used.

        PyObject *m;
                  ^

cc-1552 cc: WARNING File =
/tmp/Python-2.2a1/Modules/selectmodule.c, Line = 335
  The variable "j" is set but never used.

        int i, j, pos;
               ^


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

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


From noreply@sourceforge.net  Wed Aug  1 23:15:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:15:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-435455 ] Python 2.0.1c1 fails to build on RH7.1
Message-ID: <E15S4H7-0005lp-00@usw-sf-web3.sourceforge.net>

Bugs item #435455, was opened at 2001-06-22 06:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435455&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Ole H. Nielsen (ohnielse)
>Assigned to: Thomas Wouters (twouters)
Summary: Python 2.0.1c1 fails to build on RH7.1

Initial Comment:
Building Python 2.0.1c1 on a RedHat 7.1 (2.4.2-2 on
i586) fails at this point:

cd Modules;  make OPT="-g -O2 -Wall -Wstrict-prototypes
-fPIC" VERSION="2.0" \
                prefix="/usr/local"
exec_prefix="/usr/local" \
                sharedmods
make[1]: Entering directory
`/scratch/ohnielse/Python-2.0.1/Modules'
gcc -fpic  -g -O2 -Wall -Wstrict-prototypes -fPIC
-I./../Include -I.. -DHAVE_CONFIG_H -c ./bsddbmodule.c
./bsddbmodule.c: In function `newdbhashobject':
./bsddbmodule.c:55: `HASHINFO' undeclared (first use in
this function)
./bsddbmodule.c:55: (Each undeclared identifier is
reported only once
./bsddbmodule.c:55: for each function it appears in.)
./bsddbmodule.c:55: parse error before `info'
./bsddbmodule.c:60: `info' undeclared (first use in
this function)
./bsddbmodule.c:71: warning: implicit declaration of
function `dbopen'
./bsddbmodule.c:71: warning: assignment makes pointer
from integer without a cast
./bsddbmodule.c: In function `newdbbtobject':
./bsddbmodule.c:100: `BTREEINFO' undeclared (first use
in this function)
./bsddbmodule.c:100: parse error before `info'
./bsddbmodule.c:105: `info' undeclared (first use in
this function)
./bsddbmodule.c:118: warning: assignment makes pointer
from integer without a cast
./bsddbmodule.c: In function `newdbrnobject':
./bsddbmodule.c:147: `RECNOINFO' undeclared (first use
in this function)
./bsddbmodule.c:147: parse error before `info'
./bsddbmodule.c:152: `info' undeclared (first use in
this function)
./bsddbmodule.c:164: warning: assignment makes pointer
from integer without a cast
./bsddbmodule.c: In function `bsddb_dealloc':
./bsddbmodule.c:202: too few arguments to function
./bsddbmodule.c: In function `bsddb_length':
./bsddbmodule.c:232: structure has no member named
`seq'
./bsddbmodule.c:233: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:235: structure has no member named
`seq'
./bsddbmodule.c:236: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:229: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_subscript':
./bsddbmodule.c:265: warning: passing arg 2 of pointer
to function from incompatible pointer type
./bsddbmodule.c:265: too few arguments to function
./bsddbmodule.c: In function `bsddb_ass_sub':
./bsddbmodule.c:307: warning: passing arg 2 of pointer
to function from incompatible pointer type
./bsddbmodule.c:307: too few arguments to function
./bsddbmodule.c:330: warning: passing arg 2 of pointer
to function from incompatible pointer type
./bsddbmodule.c:330: too few arguments to function
./bsddbmodule.c: In function `bsddb_close':
./bsddbmodule.c:357: too few arguments to function
./bsddbmodule.c: In function `bsddb_keys':
./bsddbmodule.c:386: structure has no member named
`seq'
./bsddbmodule.c:386: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:407: structure has no member named
`seq'
./bsddbmodule.c:407: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:376: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_has_key':
./bsddbmodule.c:440: warning: passing arg 2 of pointer
to function from incompatible pointer type
./bsddbmodule.c:440: too few arguments to function
./bsddbmodule.c: In function `bsddb_set_location':
./bsddbmodule.c:466: structure has no member named
`seq'
./bsddbmodule.c:466: `R_CURSOR' undeclared (first use
in this function)
./bsddbmodule.c:453: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_seq':
./bsddbmodule.c:503: structure has no member named
`seq'
./bsddbmodule.c:489: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_next':
./bsddbmodule.c:531: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_previous':
./bsddbmodule.c:536: `R_PREV' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_first':
./bsddbmodule.c:541: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_last':
./bsddbmodule.c:546: `R_LAST' undeclared (first use in
this function)
make[1]: *** [bsddbmodule.o] Error 1

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2001-07-10 01:30

Message:
Logged In: YES 
user_id=43607

I have no trouble building the current CVS version on RedHat
7.1.  However, when I try the gcc command given in the error
message, I get much the same errors.
The deciding difference was: setup.py (part of the standard
current build process) adds -DHAVE_DB_185_H=1 to the
compiler command line.

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

Comment By: Ole H. Nielsen (ohnielse)
Date: 2001-07-09 07:51

Message:
Logged In: YES 
user_id=27232

twouters wrote:
> I suspect the problem here is that you don't have the
> appropriate -devel RPM installed. I think you need
>  'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel'
> might work too.
Sorry, no.  These RPMs seem to be installed by default on RedHat 7.1:
# rpm -qa | grep devel | grep db
db1-devel-1.85-5
db2-devel-2.4.14-5
gdbm-devel-1.8.0-5
db3-devel-3.1.17-7

It would be nice if a Python developer could gain access to a RedHat 7.1
machine to sort this problem out :-)

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

Comment By: Thomas Wouters (twouters)
Date: 2001-07-09 07:06

Message:
Logged In: YES 
user_id=34209

I suspect the problem here is that you don't have the
appropriate -devel RPM installed. I think you need
'db3-devel', but 'db2-devel', 'db1-devel' or 'db-devel'
might work too.

Can you confirm that you have none of those installed ? I
think what happens is that distutils can't find an include
header to include, so it assumes the DB implementation is
included in libc, instead. (Changing catagory to distutils
on that assumption.)



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

Comment By: Ole H. Nielsen (ohnielse)
Date: 2001-06-26 14:52

Message:
Logged In: YES 
user_id=27232

loewis wrote:
> I have asked you to report things, not to change things. 
> It is not easy to repeat for me, as I don't have Redhat 
7.1.

Sorry about the confusion.  My report is for RedHat 7.1:
1. Untar the distribution 2.0.1c1
2. ./configure
3. make

The errors reported occur.  I have changed nothing.
I don't know what bsddb is, nor why it's getting compiled.

Hopefully, someone knowing Python 2.0.1 and having 
access to a RedHat 7.1 box could look into the problem.
At this point Python building seems broken on RH7.1 :-(

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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-26 00:02

Message:
Logged In: YES 
user_id=21627

I have asked you to report things, not to change things. It
is not easy to repeat for me, as I don't have Redhat 7.1.

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

Comment By: Ole H. Nielsen (ohnielse)
Date: 2001-06-25 15:20

Message:
Logged In: YES 
user_id=27232

loewis wrote:
> Please report the following things:
> - the line in Setup that you activated to enable 
> compilation of bsddb
> - the exact version of the bsddb RPM package that 
provides 
> db.h
> - whether or not this packages includes a file db_185.h

Sorry, I didn't change ANYTHING !  I was trying a vanilla
build on RedHat 7.1 !  Should be easy to repeat...
Maybe the build scripts make some incorrect choices 
on RedHat 7.1 ?

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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-23 13:58

Message:
Logged In: YES 
user_id=21627

Please report the following things:
- the line in Setup that you activated to enable 
compilation of bsddb
- the exact version of the bsddb RPM package that provides 
db.h
- whether or not this packages includes a file db_185.h



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

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


From noreply@sourceforge.net  Wed Aug  1 23:17:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:17:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-446971 ] im_func, user-defined method
Message-ID: <E15S4J3-000449-00@usw-sf-web2.sourceforge.net>

Bugs item #446971, was opened at 2001-08-01 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446971&group_id=5470

Category: Documentation
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: im_func, user-defined method

Initial Comment:
>From the language reference:

3.2 The standard type hierarchy 

User-defined methods:

A user-defined method object combines a class, a class 
instance (or None) and a user-defined function.
...

I take issue with 'user-defined function'.  In my 
experiments with Python 2.1.1 on Windows 2000, using 
the C API, a user-defined method can combine a 'user-
defined function' OR a 'builtin function'.

I call PyObject_GetAttrString( pPyObject, "im_func" ), 
and a built-in function type object is returned.

Tom.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:19:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:19:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S4LF-0007Zd-00@usw-sf-web1.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:34:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:34:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S4ZX-0004HK-00@usw-sf-web2.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:39:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__
Message-ID: <E15S4eW-0004fc-00@usw-sf-web2.sourceforge.net>

Bugs item #442791, was opened at 2001-07-19 08:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: New style classes and __delitem__

Initial Comment:
And another one: New style class don't seem to support 
__delitem__:
----
class Foo(object):
   def __delitem__(self, key):
      print "__delitem__"

del Foo()[42]
----
This results in:
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
TypeError: object doesn't support item deletion
----
Changing the base class to dictionary results in:
----
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
KeyError: 42
----
but Foo.__delitem__ doesn't seem to be called.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:39

Message:
Logged In: YES 
user_id=6380

Reopened.  I'll investigate.


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

Comment By: Walter Dіrwald (doerwalter)
Date: 2001-08-01 11:34

Message:
Logged In: YES 
user_id=89016

I checked out the descr-branch and it seems that dictionary 
still doesn't support __delitem__:

>>> x = {}
>>> dictionary.__setitem__(x, 1, 1)
>>> x
{1: 1}
>>> dictionary.__delitem__(x, 1)     
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: type object 'dictionary' has no 
attribute '__delitem__'


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 09:36

Message:
Logged In: YES 
user_id=6380

Whoops, you found a whole slew of bugs in this area!

I've fixed this now in the descr-branch of the CVS tree, in
Object/typeobject.c:2.16.8.69.

I've also added a bit to the test suite that checks these
(and slices).

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

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


From noreply@sourceforge.net  Wed Aug  1 23:41:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:41:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-445484 ] pickle lacks float('inf')
Message-ID: <E15S4ft-0004h4-00@usw-sf-web2.sourceforge.net>

Bugs item #445484, was opened at 2001-07-28 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445484&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 4
Submitted By: Anthony Doggett (anthonydoggett)
Assigned to: Tim Peters (tim_one)
Summary: pickle lacks float('inf')

Initial Comment:
Support for float('inf') still appears to be missing in

Python 2.1.1 (#1, Jul 28 2001, 14:15:01) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2

>>> cPickle.dumps(float('inf'), 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: frexp() result out of range
>>> pickle.dumps(float('inf'), 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 943, in dumps
    Pickler(file, bin).dump(object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 109, in dump
    self.save(object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 211, in save
    f(self, object)
  File "/var/ajd111/python/lib/python2.1/pickle.py",
line 273, in save_float
    self.write(BINFLOAT + pack('>d', object))
SystemError: frexp() result out of range


Both structmodule.c and cPickle.c require changes.
Surely something like 

  if (x == HUGE_VAL) {    /* Inf */
      e = 1024;
      f = 0.0;
  }
  else {
      f = frexp(x, &e);
      ...

and

  if (e == 1024)
      x = HUGE_VAL;		/* Inf */
  else {

is all that is required for all IEEE754 machines?

(structmodule.c requires similar changes for Float
also)

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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-01 15:41

Message:
Logged In: YES 
user_id=31435

Note that Python has no intentional support for Infs and 
NaNs anywhere; even that float('inf') doesn't blow up when 
you do it is a platform accident (it blows up ("invalid 
literal") on my box).

Given that, in the absence of a comprehensive plan for 
supporting this stuff across the board, and worker bees to 
implement it, I downgraded the priority.  A good plan would 
refactor the code so that dealing with the platform double 
and float formats occurs in only one place.

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

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


From noreply@sourceforge.net  Wed Aug  1 23:57:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 15:57:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15S4vL-0006z8-00@usw-sf-web3.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:57

Message:
Logged In: NO 

$ ./python
'import site' failed; use -v for traceback
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> import sys
>>> sys.path
['', '.', '/home/mahler/local/PYTHON/Meta',
'/home/mahler/local/PYTHON/kwP',
'/home/mahler/local/lib/python',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/APPS/jack-2.2.0',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/lib/python2.2/',
'/home/mahler/local/lib/python2.2/plat-linux2',
'/home/mahler/local/lib/python2.2/lib-tk',
'/home/mahler/local/lib/python2.2/lib-dynload']
>>> 


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Thu Aug  2 04:21:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 20:21:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-416901 ] 2.1 on OpenBSD 2.8: lots of bugs @ build
Message-ID: <E15S92n-0001cs-00@usw-sf-web1.sourceforge.net>

Bugs item #416901, was opened at 2001-04-17 17:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416901&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brad Allen (valaulmo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 2.1 on OpenBSD 2.8: lots of bugs @ build

Initial Comment:
I am doing a survey of current distributed information
systems, to see
if they are close to what they should be (I figured out
what they should
be in 1984), and am forced to find a Python which Mojo
Nation is compatible
with.  I will probably go back to Python 2.0, but since
the latest released
version (released today!) was 2.1, I just started there
(since the stable
one for OpenBSD 2.8 was way back at Python 1.6 and I
figured anything
past that was experimenting anyway).

--- Python 2.1 on OpenBSD 2.8 with Pentium I:

I'm getting these warnings while compiling Python 2.1
on OpenBSD 2.8:

cc   -o python \
                Modules/python.o \
                libpython2.1.a -lc_r -lutil
-L/usr/local/lib -lz  -lm  
./Modules/posixmodule.c:2995: warning: this program
uses setreuid(), which is deprecated.
./Modules/posixmodule.c:3014: warning: this program
uses setregid(), which is deprecated.
./Modules/posixmodule.c:4147: warning: tempnam()
possibly used unsafely; consider using mkstemp()
./Modules/posixmodule.c:4193: warning: tmpnam()
possibly used unsafely; consider using mkstemp()
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x31168 for "_flockfile"
ld: libpython2.1.a(fileobject.o): RRS text relocation
at 0x311af for "_funlockfile"
PYTHONPATH= ./python ./setup.py build
running build


Please consider fixing those things.

---

***   HUNG   test_bufio.py

When running tests as "MAKE=gmake gmake test", it hung
under
test_bufio.  It required a SIGKILL to stop.  I tried
two things:

* Running test as README says manually with "python
...".
     python ./Lib/test/test_bufio.py
  This worked OK and produced no output that I was
aware of
  (unless it was hidden).

* Tried defining DONT_USE_FGETS_IN_GETLINE in the file
where it
  was looked at (./Objects/fileobject.c).  This did not
help;
  it still hung.  Running the test manually again at
this point worked also.


So, I had to find a way to skip that test (hid it in a
subdirectory
called HIDE).

***   HUNG   test_complex.py

The same thing happened with test_complex.py: it hung
during "...make test",
but ran OK manually; then I hid it to skip.  For
test_dl, I got slightly
different results; after the usual hanging, I then
manually ran it and got:

***   HUNG   test_dl.py*

Q:/usr/local/src/python/Python-2.1:2148$ python
Lib/test/test_dl.py
Traceback (most recent call last):
  File "Lib/test/test_dl.py", line 6, in ?
    import dl
ImportError: No module named dl
Q:/usr/local/src/python/Python-2.1:2149$ 

In each case, lots of CPU by the "python" process was
used as its
"hung" state.  I waited approximately three minutes of
CPU.  A
133Megahertz Pentium with a CPU cache on a Dell
computer is extremely
fast, and ought to finish any test within two minutes. 
Tell me if
I just failed to wait long enough for an increadibly
inefficiently
programmed test to complete, and I'll retry it.  The
fact that it did
not respond to signals except KILL also indicates to me
that it was
comotose.  (This discussion reminds me of a date where
the person
told me that the commands in Unix are very violent
sounding and the
names of the principles used by programmers are very
anti-social.
I'm glad someone thinks that way, since English itself
is far, far
worse, according to
http://www.islandnet.com/~edonon/decoding.htm, and
I said to myself "how can anybody use this language?"
in disgust.
Someday we'll fix that, too (and not just for
historical politeness;
for pureness of utility and efficiency -- snowballed
efficiency!).)

---

***   MEMORY FAULT   test_fork1.py

While the tests were running "test_fork1", I got a
Memory Fault.
Rerunning it manually worked, though, and I hid it
also.  (I did not
test rerunning it.)

While waiting for all these tests to hang, I got tired
of it and
now I want to request that you have all the tests run
in parallel.
That way, it is easier to weed out all the hanging ones
in one shot.
This is easy, right?

***   HUNG   test_compile.py

Next to hang was this one:

$ python ./Lib/test/test_compile.py
Running tests on argument handling
testing complex args
1 2
1 2
3 4
1 2 3
1 2 3
2 3 4
$

As you can see, it ran OK manually, and this time I had
some output to
look at.  While looking at it I realized that I do not
know if those
are the expected results, and in the house I'm in, I
have to listen to
too much hollaring to be able to learn Python in a few
minutes like
I am usually able to do in proper environments.

***   HUNG   test_doctest.py

test_doctest.py passed manually but automatically hung,
too.
It had too much output to include it all, but the last
line said
the test passed.


***   HUNG & SEGFAULT test_threadedtempfile.py

For test_threadedtempfile, I got a bad error:

$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
Segmentation fault (core dumped)
$ rm *core
$ python Lib/test/test_threadedtempfile.py 
Creating
Starting
Reaping
^C^C^C^Z
^Z^X^C
Killed
$ 
$ jobs
[1]-  Stopped                 less README
[2]+  Stopped                 MAKE=gmake gmake test
$ sync
$ rm Lib/test/test_threadedt

So far, a few tests ran better the second time than the
first.  Is
the compiling working better than the interpreting?

---

Brad Allen <Ulmo@Q.Net>

*

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-01 20:21

Message:
Logged In: YES 
user_id=3066

--sigh--  Still having problems getting access on an OpenBSD
machine.  Appearantly one has been set up at my employers
main office, but I can't get to it from the PythonLabs
office yet.  ;-(

No, I'm not ignoring this, but the priority isn't high given
that I can't get to a usable installation.  (It would be
great if SourceForge could provide one on the compile farm,
or if their FreeBSD machine actually responded.)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-17 08:22

Message:
Logged In: YES 
user_id=3066

I'm looking into getting access to an OpenBSD machine to
test on.

The last comment in the bug report makes me wonder a bit,
however: did you wait for long to see if the tests
terminated?  Many of the tests will appear to run faster
during the second phase of the test since the test modules
will have already been byte-compiled, but the byte-code used
 to execute the tests will be the same during both phases.

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

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

Message:
Logged In: YES 
user_id=3066

The warnings are irrelevant -- any package that wraps those
functions to make them available to applications will cause
those warnings on OpenBSD, even if they are never used.

The other issues require more attention than I can spare
this week, so I'll leave this open.

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

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


From noreply@sourceforge.net  Thu Aug  2 07:21:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 01 Aug 2001 23:21:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-446671 ] configure ignores --mandir
Message-ID: <E15SBqx-0005cB-00@usw-sf-web3.sourceforge.net>

Bugs item #446671, was opened at 2001-07-31 23:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446671&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure ignores --mandir

Initial Comment:
Actually, Makefile.in (in various places) ignores the 
--mandir configuration option to configure.

As such, man pages are always installed under 
$(PREFIX)/man regardless of what the user 
specifies.

(I have noticed that an awful lot of GNU packages 
have a similar bug.  Yet, a few BSD derived 
operating systems like man pages to be installed 
in /usr/local/share/man/)

b.bum


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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-01 23:21

Message:
Logged In: YES 
user_id=21627

Fixed in Makefile.pre.in 1.48.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 09:21

Message:
Logged In: NO 


The option is in configure within the 2.2 source, is a 
standard part of autoconf, and is easy to support.   A lot 
of GNU programs are starting to do so.

As well, there are a handful of systems that have the 
man pages split away from the binary/library/includes.

I'll try and generate/submit the appropriate patch.




[localhost:/tmp/Python-2.2a1] bbum% ./configure --help
Usage: configure [options] [host]
Options: [defaults in brackets after descriptions]
Configuration:
  --cache-file=FILE       cache test results in FILE
  --help                  print this message
  --no-create             do not create output files
  --quiet, --silent       do not print `checking...' messages
  --version               print the version of autoconf that 
created configure
Directory and file names:
  --prefix=PREFIX         install architecture-independent 
files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent 
files in EPREFIX
                          [same as prefix]
  --bindir=DIR            user executables in DIR [EPREFIX/
bin]
  --sbindir=DIR           system admin executables in DIR 
[EPREFIX/sbin]
  --libexecdir=DIR        program executables in DIR 
[EPREFIX/libexec]
  --datadir=DIR           read-only architecture-
independent data in DIR
                          [PREFIX/share]
  --sysconfdir=DIR        read-only single-machine data in 
DIR [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-
independent data in DIR
                          [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data 
in DIR [PREFIX/var]
  --libdir=DIR            object code libraries in DIR 
[EPREFIX/lib]
  --includedir=DIR        C header files in DIR [PREFIX/
include]
  --oldincludedir=DIR     C header files for non-gcc in 
DIR [/usr/include]
  --infodir=DIR           info documentation in DIR [PREFIX/
info]
  --mandir=DIR            man documentation in DIR 
[PREFIX/man]
  --srcdir=DIR            find the sources in DIR [configure 
dir or ..]
  --program-prefix=PREFIX prepend PREFIX to installed 
program names
  --program-suffix=SUFFIX append SUFFIX to installed 
program names
  --program-transform-name=PROGRAM


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 06:30

Message:
Logged In: YES 
user_id=6380

I'm not sure who's to blame.  I've never even heard of
--mandir.  Unclear whether it's a bug.  If someone feels
like fixing this, let them go ahead, but I don't see this as
a priority unless you provide a good motivating example as
to why you would need this.

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

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


From noreply@sourceforge.net  Thu Aug  2 11:15:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 03:15:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E15SFVW-0003MA-00@usw-sf-web2.sourceforge.net>

Bugs item #405227, was opened at 2001-03-01 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405227&group_id=5470

Category: Unicode
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jon Saenz (jsaenz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:15

Message:
Logged In: YES 
user_id=38388

This should fixed now; see Fredrik's response.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-26 13:05

Message:
Logged In: YES 
user_id=31435

Thank you, /F -- excellent news!

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

Comment By: Fredrik Lundh (effbot)
Date: 2001-06-26 12:21

Message:
Logged In: YES 
user_id=38376

in the current CVS codebase, there's a new (experimental) 
define in Include/unicodeobject.h:

    #undef USE_UCS4_STORAGE

if this is defined, Py_UNICODE will be set to the same 
thing as Py_UCS4 (usually unsigned int or unsigned long).  
currently, basic unicode functions and SRE works just fine 
with this setting, but some other modules (including the 
UTF-16 codec) may not work (yet).

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-18 06:17

Message:
Logged In: YES 
user_id=38388

Of course, you could declare Py_UNICODE as "unsigned int"
and then store Unicode characters in e.g. 4 bytes each on
platforms which don't have a 16-bit integer type. 

The reason for being picky about the 16 bits is that we
chose UTF-16 as internal data storage format and that format
defines the byte stream in terms of entities which have 2
bytes for each character. This format provides the best
low-level integration with other Unicode storage formats
such as wchar_t on Windows. That's why I would like to keep
this compatibility if at all possible.

I am not sure, but I think that sre also makes the 2-byte
assumption internally in some places.

A simple test for this would be to define Py_UNICODE as
unsigned long and then run the regression suite...

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-06-18 05:38

Message:
Logged In: YES 
user_id=6380

Huh?  That depends on how ch is declared, and what kind of
data is in the array.  If it's an array of Py_UNICODE
elements, and ch is declared as "Py_UNICODE *ch;", then ch++
will do the right thing (increment it by one Py_UNICODE
unit).

Now, the one thing you can NOT assume is that if you read
external 16-bit data into a character buffer, that the
Unicode characters correspond to Py_UNICODE characters --
perhaps this is what you're after?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-18 01:19

Message:
Logged In: YES 
user_id=38388

Ok, I agree that the math will probably work in most cases
due to the fact that UTF-16 will never produce values
outside the 16-bit range, but you still have the problem
with iterating over Py_UNICODE arrays: the compiler will
assume that
ch++ means to move the pointer by sizeof(Py_UNICODE) bytes
and this breaks in case you use e.g. a 32-bit integer type
for Py_UNICODE.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-17 14:05

Message:
Logged In: YES 
user_id=31435

The code snippet there will work fine with any integral 
type >= 2 bytes if you just add the line

ch &= 0xffff;

between the computation and the "if".

It will actually work fine even if you *don't* put in that 
mask, but deducing that required analysis of the specific 
operations (you shift 4 bits left 12, 6 bits left 6 so they 
don't overlap with the first chunk and so the "+" can't 
cause a carry, and then add another chunk of non-
overlapping 6 bits, so again there's no carry, and 
therefore the infinite-precision result fits in no more 
than 16 bits, and so there's no need to mask).

About pointers, I don't see a problem there either, unless 
you're casting a Py_UNICODE* to a char* then adding a 
hardcoded 2.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-17 12:57

Message:
Logged In: YES 
user_id=38388

The codecs are full of things like:

            ch = ((s[0] & 0x0f) << 12) + ((s[1] & 0x3f) <<
6) + (s[2] & 0x3f);
            if (ch < 0x800 || (ch >= 0xd800 && ch < 0xe000))
{
                errmsg = "illegal encoding";
                goto utf8Error;
            }

where ch is a Py_UNICODE character.

The other "problem" is that pointer dereferencing is used a
lot in the code (using arrays of Py_UNICODE chars). We could
probably shift the calculations to Py_UCS4 integers and then
only do the data buffer access with Py_UNICODE which would
then be mapped to a a 2-char-array to get the data buffer
layout right.

Still, I think this is low priority. Patches are welcome of
course :-)

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-17 12:44

Message:
Logged In: YES 
user_id=31435

Point me to one of the calculations that's thought to be a 
problem, and happy to suggest something (I didn't find one 
on my own, but I'm not familiar with the details here).  
BTW, I reopened this because we got another report of T3E 
woes on c.l.py that day.

You certainly need at least 16 bits, but it's hard to see 
how having more than that could be a genuine problem -- at 
worst "this kind of thing" usually requires no more than 
masking with 0xffff at the end.  That can be hidden in a 
macro that's a nop on platforms that don't need it, if 
micro-efficiency is a concern.

Often even that isn't needed.  For example, binascii_crc32 
absolutely must compute a 32-bit checksum, but works fine 
on platforms with 8-byte longs.  The only "trick" needed to 
make that work was to compute the complement via

crc ^ 0xFFFFFFFFUL

instead of via

~crc


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-17 11:47

Message:
Logged In: YES 
user_id=38388

It may be a design error, but getting this right for all
platforms is hard and by choosing the 16-bit type we managed
to handle 95% of all platforms in a fast and reliable way.

Any idea how we could "emulate" a 16-bit integer type ? We
need the integer type because we do calculcations on the
values.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-13 22:28

Message:
Logged In: YES 
user_id=31435

I opened this again.  It's simply unacceptable to require 
that the platform have a 2-byte integer type.  That doesn't 
mean it's easy to fix, but it's a design error all the same.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-16 11:27

Message:
Logged In: YES 
user_id=38388

The current Unicode implementation needs Py_UNICODE to
be a 16-bit entity and so does SRE.

To get this to work on the Cray, you could try to use a
2-char
struct which is then cast to a short in all those places
which
assume a 16-bit number representation.

Simply using a 4-byte entity as basis will not work, since
the fact that Py_UNICODE fits into 2 bytes is hard-coded
into the implementation in a number of places.

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

Comment By: Tim Peters (tim_one)
Date: 2001-03-01 15:29

Message:
Logged In: YES 
user_id=31435

Notes:

+ Python was ported to T3E last year, IIRC by Marc Poinot.  
May want to track him down.

+ Python's Unicode support doesn't rely on any platform 
Unicode support.  Whether it's "useless" depends on the 
user, not the platform.

+ Face it <wink>:  Crays are the only platforms that don't 
have a native 16-bit integer type.

+ Even so, I believe at least SRE is happy to work with 32-
bit Unicode (glibc's wchar_t is 4 bytes, IIRC), so that 
much was likely a shallow problem.


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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:09

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

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

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From noreply@sourceforge.net  Thu Aug  2 16:02:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 08:02:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-446049 ] file type is callable but crashes
Message-ID: <E15SJzp-0007Dp-00@usw-sf-web3.sourceforge.net>

Bugs item #446049, was opened at 2001-07-30 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446049&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: file type is callable but crashes

Initial Comment:
Calling the type of a file object results
in a crash.  More details to follow.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 08:02

Message:
Logged In: YES 
user_id=6380

The direct cause is that the tp_new slot inherited from
'object' creates a file object that is initialized to all
zeros, and the file object's tp_repr slot doesn't anticipate
that.

I can fix the file object in a number of ways (make it work
for uninitialized objects, or add a tp_new slot that
initializes it properly). But I expect that file is not the
only type that is vulnerable to this kind of attack,
especially 3rd party types that adopt
PyObject_GenericGetAttr() but don't define their own tp_new
are vulnerable.

The alternative would be to remove the default tp_new
implementation from 'object', and add one to dynamically
created types. That would mean you couldn't call object() to
get a featureless object, which is currently supported and
even tested in test_descr.py.

Any preferences?

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:57

Message:
Logged In: YES 
user_id=11365

Python 2.2a1 (#2, Jul 26 2001, 11:50:01) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> f = open('README')
>>> type(f)()
Segmentation fault (core dumped)

Seems to me that it would be nice if FileType
worked like the 'open' builtin.
You could have a 'file' builtin and alias it to open.
Wild speculation: I guess open could be eventually
deprecated.  At which point you could safely do 
from os import *  ;-)


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

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


From noreply@sourceforge.net  Thu Aug  2 18:19:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 10:19:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15SM82-0001gU-00@usw-sf-web2.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 10:19

Message:
Logged In: NO 

Guido,

Yes, the sys.path does make sense.
I use stow <http://www.gnu.org/software/stow/manual.html>
to manage my downloaded software.
So package X ends up being installed at $HOME/local/STOW/X.
Stow then creates symlinks to make it look like it is
installed at $HOME/local.
This makes it easy to tell which file belongs to which
package without having PATH, INCLUDE etc be as long as your
arm.
I have a make file $HOME/local which when invoked with "make
X", 
untars $HOME/local/TAR/X.tgz into $HOME/local/SRC
does 
$ cd $HOME/local/SRC/X
where it then does
$ ./configure --prefix=$HOME/local/STOW/X
$ make
$ make install
finally it then does
$ cd $HOME/local/STOW
$ stow X

Therefore, PYTHONPATH is $HOME/local
so I do not have to change it between installs.
This has worked with
versions 1.5.2, 1.6, 2.0, and 2.1,
and with all GNU software,
and most other autoconfiguring software. 

Here is the python section of my .bashrc

# Python
export PYAPPS=$LOCAL/PYTHON
alias pyapps='/bin/ls -d $PYAPPS/*'
alias pyappspath='jn : `pyapps`'
export PYTHONHOME=$LOCAL
export PYTHONSTARTUP=~/.pythonrc.global.py
export PYTHONSTARTUPPATH=~/.pythonrc.py:./.pythonrc.py
export PYTHONPATH=.:`pyappspath`:$LIB/python:$PYTHONPATH
export PATH=$PYTHONPATH:$PATH

Here is the makefile
I use to build GNU style software.
+++++++++++++++++++++++++++++++++++++++++++
.SUFFIXES: .jar .tar .tar.bz2 .tar.gz .tgz .Z .zip .build
.kill .clean .check .test


#ANT_JARS=find $(JAVA_DIR)/SRC/dist -name "*.jar"
#ANT_PATH=jn : \



%: STOW/%
	rm -f $</info/dir; # remove this line if installing emacs
itself
	(cd STOW; stow $(<F));

STOW/%: SRC/%/Makefile
	 $(MAKE) $(@F).kill;
	 cp -a STOW/LOCAL $@
	 $(MAKE) -C SRC/$(@F) install;

#%: SRC/%/build.xml
#	 CLASSPATH=`$(ANT_PATH)`:$(CLASSPATH)
#	 ant -buildfile $< all

#STOW/%: SRC/%/build.sh
#	(cd $(<D); sh ./build.sh -Dbuild=$@)

#%: SRC/%/build.sh
#	$(<D)/build.sh -buildfile $< all

# SRC/%/build.sh: SRC/%

# SRC/%/build.xml: SRC/%

#SRC/%.build: SRC/%/Makefile
#	 $(MAKE) -C $(<D);

SRC/%/Makefile: SRC/%
#	(HERE=`(cd ..; pwd)`; cd $<;  ./configure
--prefix=$$HERE/STOW/$(<F))
	cd $<; ./configure --prefix=$(STOW)/$(<F)

SRC/%: TAR/%.tgz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.gz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.Z
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.zip
	unzip -d $(@) $<

SRC/%: TAR/%.tar
	tar fx $< --directory $(@D);

TAR/%.tar: TAR/%.tar.bz2
	bunzip2 $<

SRC/%: TAR/%.jar
	jar fx $< --directory $(@D);

%.kill:
	(cd STOW; stow -D $(*F))
	rm -rf  STOW/$(*F);

%.clean: %.kill
	rm -rf SRC/$(*F);

%.check: SRC/%/Makefile
	 $(MAKE) -C $(<D) check;

%.test: SRC/%/Makefile
	 $(MAKE) -C $(<D) test;
+++++++++++++++++++++++++++++++++++++++++++++++++

My ~/pythonrc.global.py is

+++++++++++++++++++++++++++++++++++++++++++++++++
import os
import string

path = string.split(os.environ.get('PYTHONSTARTUPPATH'),':')
for file in path:
    if os.path.isfile(file):
        execfile(file)
+++++++++++++++++++++++++++++++++++++++++++++++++

but that should not be coming into play
when python is being invoked by make

regards
Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 05:28

Message:
Logged In: YES 
user_id=6380

You have to do some thinking yourself too, you know. :-)

Does that sys.path value make any sense to you? It doesn't
match the prefix.

Are the missing modules found on any of those?

What other env vars do you have set that start with PYTHON?
Do you have PYTHONHOME?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:57

Message:
Logged In: NO 

$ ./python
'import site' failed; use -v for traceback
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> import sys
>>> sys.path
['', '.', '/home/mahler/local/PYTHON/Meta',
'/home/mahler/local/PYTHON/kwP',
'/home/mahler/local/lib/python',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/APPS/jack-2.2.0',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/lib/python2.2/',
'/home/mahler/local/lib/python2.2/plat-linux2',
'/home/mahler/local/lib/python2.2/lib-tk',
'/home/mahler/local/lib/python2.2/lib-dynload']
>>> 


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Thu Aug  2 12:39:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 04:39:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-405227 ] sizeof(Py_UNICODE)==2 ????
Message-ID: <E15SGpK-0003O9-00@usw-sf-web1.sourceforge.net>

Bugs item #405227, was opened at 2001-03-01 11:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405227&group_id=5470

Category: Unicode
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jon Saenz (jsaenz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: sizeof(Py_UNICODE)==2 ????

Initial Comment:
We are trying to install Python 2.0 in a Cray T3E.

After a painful process of removing several modules
which produce some errors (mmap, sha, md5), we get core
dumps when we run python because under this platform,
there does not exist a 16-bit numeric type. Unsigned
short is 4 bytes long.

We have finally defined unicode objects as unsigned
short, despite they are 4 bytes long, and we have
changed a sentence in 
Objects/unicodeobject.c
to:
if (sizeof(Py_UNICODE)!=sizeof(unsigned short){

It compiles and runs now, but the test on regular
expressions crashes and the whole regression test does,
too.

Support of Unicode for this platform is not correct in
version 2.0 of Python.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 04:39

Message:
Logged In: NO 

has tim's UTF-16 codec patch been checked in yet?

</F>

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:15

Message:
Logged In: YES 
user_id=38388

This should fixed now; see Fredrik's response.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-26 13:05

Message:
Logged In: YES 
user_id=31435

Thank you, /F -- excellent news!

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

Comment By: Fredrik Lundh (effbot)
Date: 2001-06-26 12:21

Message:
Logged In: YES 
user_id=38376

in the current CVS codebase, there's a new (experimental) 
define in Include/unicodeobject.h:

    #undef USE_UCS4_STORAGE

if this is defined, Py_UNICODE will be set to the same 
thing as Py_UCS4 (usually unsigned int or unsigned long).  
currently, basic unicode functions and SRE works just fine 
with this setting, but some other modules (including the 
UTF-16 codec) may not work (yet).

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-18 06:17

Message:
Logged In: YES 
user_id=38388

Of course, you could declare Py_UNICODE as "unsigned int"
and then store Unicode characters in e.g. 4 bytes each on
platforms which don't have a 16-bit integer type. 

The reason for being picky about the 16 bits is that we
chose UTF-16 as internal data storage format and that format
defines the byte stream in terms of entities which have 2
bytes for each character. This format provides the best
low-level integration with other Unicode storage formats
such as wchar_t on Windows. That's why I would like to keep
this compatibility if at all possible.

I am not sure, but I think that sre also makes the 2-byte
assumption internally in some places.

A simple test for this would be to define Py_UNICODE as
unsigned long and then run the regression suite...

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-06-18 05:38

Message:
Logged In: YES 
user_id=6380

Huh?  That depends on how ch is declared, and what kind of
data is in the array.  If it's an array of Py_UNICODE
elements, and ch is declared as "Py_UNICODE *ch;", then ch++
will do the right thing (increment it by one Py_UNICODE
unit).

Now, the one thing you can NOT assume is that if you read
external 16-bit data into a character buffer, that the
Unicode characters correspond to Py_UNICODE characters --
perhaps this is what you're after?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-18 01:19

Message:
Logged In: YES 
user_id=38388

Ok, I agree that the math will probably work in most cases
due to the fact that UTF-16 will never produce values
outside the 16-bit range, but you still have the problem
with iterating over Py_UNICODE arrays: the compiler will
assume that
ch++ means to move the pointer by sizeof(Py_UNICODE) bytes
and this breaks in case you use e.g. a 32-bit integer type
for Py_UNICODE.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-17 14:05

Message:
Logged In: YES 
user_id=31435

The code snippet there will work fine with any integral 
type >= 2 bytes if you just add the line

ch &= 0xffff;

between the computation and the "if".

It will actually work fine even if you *don't* put in that 
mask, but deducing that required analysis of the specific 
operations (you shift 4 bits left 12, 6 bits left 6 so they 
don't overlap with the first chunk and so the "+" can't 
cause a carry, and then add another chunk of non-
overlapping 6 bits, so again there's no carry, and 
therefore the infinite-precision result fits in no more 
than 16 bits, and so there's no need to mask).

About pointers, I don't see a problem there either, unless 
you're casting a Py_UNICODE* to a char* then adding a 
hardcoded 2.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-17 12:57

Message:
Logged In: YES 
user_id=38388

The codecs are full of things like:

            ch = ((s[0] & 0x0f) << 12) + ((s[1] & 0x3f) <<
6) + (s[2] & 0x3f);
            if (ch < 0x800 || (ch >= 0xd800 && ch < 0xe000))
{
                errmsg = "illegal encoding";
                goto utf8Error;
            }

where ch is a Py_UNICODE character.

The other "problem" is that pointer dereferencing is used a
lot in the code (using arrays of Py_UNICODE chars). We could
probably shift the calculations to Py_UCS4 integers and then
only do the data buffer access with Py_UNICODE which would
then be mapped to a a 2-char-array to get the data buffer
layout right.

Still, I think this is low priority. Patches are welcome of
course :-)

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-17 12:44

Message:
Logged In: YES 
user_id=31435

Point me to one of the calculations that's thought to be a 
problem, and happy to suggest something (I didn't find one 
on my own, but I'm not familiar with the details here).  
BTW, I reopened this because we got another report of T3E 
woes on c.l.py that day.

You certainly need at least 16 bits, but it's hard to see 
how having more than that could be a genuine problem -- at 
worst "this kind of thing" usually requires no more than 
masking with 0xffff at the end.  That can be hidden in a 
macro that's a nop on platforms that don't need it, if 
micro-efficiency is a concern.

Often even that isn't needed.  For example, binascii_crc32 
absolutely must compute a 32-bit checksum, but works fine 
on platforms with 8-byte longs.  The only "trick" needed to 
make that work was to compute the complement via

crc ^ 0xFFFFFFFFUL

instead of via

~crc


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-17 11:47

Message:
Logged In: YES 
user_id=38388

It may be a design error, but getting this right for all
platforms is hard and by choosing the 16-bit type we managed
to handle 95% of all platforms in a fast and reliable way.

Any idea how we could "emulate" a 16-bit integer type ? We
need the integer type because we do calculcations on the
values.

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-13 22:28

Message:
Logged In: YES 
user_id=31435

I opened this again.  It's simply unacceptable to require 
that the platform have a 2-byte integer type.  That doesn't 
mean it's easy to fix, but it's a design error all the same.


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-03-16 11:27

Message:
Logged In: YES 
user_id=38388

The current Unicode implementation needs Py_UNICODE to
be a 16-bit entity and so does SRE.

To get this to work on the Cray, you could try to use a
2-char
struct which is then cast to a short in all those places
which
assume a 16-bit number representation.

Simply using a 4-byte entity as basis will not work, since
the fact that Py_UNICODE fits into 2 bytes is hard-coded
into the implementation in a number of places.

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

Comment By: Tim Peters (tim_one)
Date: 2001-03-01 15:29

Message:
Logged In: YES 
user_id=31435

Notes:

+ Python was ported to T3E last year, IIRC by Marc Poinot.  
May want to track him down.

+ Python's Unicode support doesn't rely on any platform 
Unicode support.  Whether it's "useless" depends on the 
user, not the platform.

+ Face it <wink>:  Crays are the only platforms that don't 
have a native 16-bit integer type.

+ Even so, I believe at least SRE is happy to work with 32-
bit Unicode (glibc's wchar_t is 4 bytes, IIRC), so that 
much was likely a shallow problem.


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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:09

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

Comment By: Jon Saenz (jsaenz)
Date: 2001-03-01 15:08

Message:
Logged In: YES 
user_id=12122

We have finally given up to install Python in the Cray T3E
due to its lack of support of shared objects. This causes
difficulties in the loading of different external libraries
(Numeric, Lapack, and so on) because of the static linking.

In any case, we still think that this "bug" should be
repaired. There may be other platforms which:
1) Do not support Unicode, so that the Unicode feature of
Python is useless in these cases.
2) The users may be interested in using Python in them (for
Numeric applications, for instance)
3) May not have a 16-bit native numerical type.

Under these circunstances, the current version of Python can
not be used.

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

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

Message:
Logged In: YES 
user_id=3066

Marc-Andre, can you deal with the general Unicode issues here and then pass this along to Fredrik for SRE updates?  (Or better yet, work in parallel?)

Thanks!

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

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


From noreply@sourceforge.net  Thu Aug  2 11:08:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 03:08:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15SFPX-0005X0-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Thu Aug  2 11:17:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 03:17:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E15SFY0-0003NW-00@usw-sf-web2.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Schinckel (schinckel)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Thu Aug  2 11:21:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 03:21:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-430269 ] python -U breaks import with 2.1
Message-ID: <E15SFbL-0003Q5-00@usw-sf-web2.sourceforge.net>

Bugs item #430269, was opened at 2001-06-05 03:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430269&group_id=5470

Category: Unicode
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: python -U breaks import with 2.1

Initial Comment:
python -U under Windows is broken with Python 2.1:

D:\>python
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import urllib
>>>
^C
D:\>python -U
Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>> import urllib
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: No module named urllib


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:21

Message:
Logged In: YES 
user_id=38388

Closing this bug report -- please refile as feature request. Python is still a long way from making the standard lib 
play nice with Unicode.

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

Comment By: Walter Dіrwald (doerwalter)
Date: 2001-06-09 11:11

Message:
Logged In: YES 
user_id=89016

To make -U more useful as a testbed for Unicode migration, 
it might be useful to change str(), repr() and chr(), so 
that they return Unicode objects when running with python -
U.


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

Comment By: Tim Peters (tim_one)
Date: 2001-06-06 15:51

Message:
Logged In: YES 
user_id=31435

Changed Group from Platform-Specific (since it's got 
nothing to do with Windows specifically) to Feature Request 
(since nobody believes it *should* work now).

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

Comment By: Tim Peters (tim_one)
Date: 2001-06-06 12:28

Message:
Logged In: YES 
user_id=31435

Martin, see email to Python-Dev:  best I can tell, nobody 
expects -U to work yet.

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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-06 00:21

Message:
Logged In: YES 
user_id=21627

The (first) problem appears to be in string.py, which has
_idmap = ''
for i in range(256): _idmap = _idmap + chr(i)

With -U, _idmap is a unicode string, and adding chr(128) 
to it will give an ASCII decoding error. Therefore, 
importing string fails. In turn, many other things fail as 
well.

That can be solved by writing
_idmap=str('')
but then it will still complain that distutils.util cannot 
be imported in site. One problem may be that site.py 
changes the strings of sys.path into Unicode strings. In 
fact, when starting Python with -U -S, it will properly 
locate urllib.


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

Comment By: Tim Peters (tim_one)
Date: 2001-06-05 18:04

Message:
Logged In: YES 
user_id=31435

Assigned to Marc-Andre.  M-A, do you expect -U to be useful 
at this point?  I thought I saw docs at one point, but 
can't seem to find them again ...


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

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


From noreply@sourceforge.net  Thu Aug  2 13:11:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 05:11:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-447152 ] WeakValueDictionary wrong except. rised
Message-ID: <E15SHKT-0001PC-00@usw-sf-web3.sourceforge.net>

Bugs item #447152, was opened at 2001-08-02 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447152&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Nobody/Anonymous (nobody)
Summary: WeakValueDictionary wrong except. rised

Initial Comment:
PythonWin 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit
(Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond
(MarkH@ActiveState.com) - see 'Help/About PythonWin'
for further copyright information.
>>> import weakref
>>> wd = weakref.WeakValueDictionary()
>>> class test: pass
...
>>> t = test()
>>> wd[1] = t
>>> del t
>>> wd[1]
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "c:\python21\lib\weakref.py", line 35, in __getitem__
o = self.data.get(key)()
TypeError: object is not callable: None
>>> 


FIX:
change
o = self.data.get(key)()
to
o = self.data[key]()


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

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


From noreply@sourceforge.net  Thu Aug  2 13:28:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 05:28:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15SHa4-0001dZ-00@usw-sf-web3.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 05:28

Message:
Logged In: YES 
user_id=6380

You have to do some thinking yourself too, you know. :-)

Does that sys.path value make any sense to you? It doesn't
match the prefix.

Are the missing modules found on any of those?

What other env vars do you have set that start with PYTHON?
Do you have PYTHONHOME?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:57

Message:
Logged In: NO 

$ ./python
'import site' failed; use -v for traceback
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> import sys
>>> sys.path
['', '.', '/home/mahler/local/PYTHON/Meta',
'/home/mahler/local/PYTHON/kwP',
'/home/mahler/local/lib/python',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/APPS/jack-2.2.0',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/lib/python2.2/',
'/home/mahler/local/lib/python2.2/plat-linux2',
'/home/mahler/local/lib/python2.2/lib-tk',
'/home/mahler/local/lib/python2.2/lib-dynload']
>>> 


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Thu Aug  2 16:32:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 08:32:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-442791 ] 2.2a1: New style classes and __delitem__
Message-ID: <E15SKSo-0003sI-00@usw-sf-web1.sourceforge.net>

Bugs item #442791, was opened at 2001-07-19 08:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442791&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: New style classes and __delitem__

Initial Comment:
And another one: New style class don't seem to support 
__delitem__:
----
class Foo(object):
   def __delitem__(self, key):
      print "__delitem__"

del Foo()[42]
----
This results in:
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
TypeError: object doesn't support item deletion
----
Changing the base class to dictionary results in:
----
Traceback (most recent call last):
  File "test.py", line 5, in ?
    del Foo()[42]
KeyError: 42
----
but Foo.__delitem__ doesn't seem to be called.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 08:32

Message:
Logged In: YES 
user_id=6380

There were no __delitem__ wrappers corresponding to the
__setitem__ wrappers.  Fixed now in the CVS trunk:
typeobject.c rev. 2.20.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:39

Message:
Logged In: YES 
user_id=6380

Reopened.  I'll investigate.


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

Comment By: Walter Dіrwald (doerwalter)
Date: 2001-08-01 11:34

Message:
Logged In: YES 
user_id=89016

I checked out the descr-branch and it seems that dictionary 
still doesn't support __delitem__:

>>> x = {}
>>> dictionary.__setitem__(x, 1, 1)
>>> x
{1: 1}
>>> dictionary.__delitem__(x, 1)     
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: type object 'dictionary' has no 
attribute '__delitem__'


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 09:36

Message:
Logged In: YES 
user_id=6380

Whoops, you found a whole slew of bugs in this area!

I've fixed this now in the descr-branch of the CVS tree, in
Object/typeobject.c:2.16.8.69.

I've also added a bit to the test suite that checks these
(and slices).

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

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


From noreply@sourceforge.net  Thu Aug  2 17:30:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 09:30:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-442813 ] 2.2a1: list.__getitem__ and index<0
Message-ID: <E15SLND-00025k-00@usw-sf-web3.sourceforge.net>

Bugs item #442813, was opened at 2001-07-19 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: list.__getitem__ and index<0

Initial Comment:
list.__getitem__ doesn't handle negative indizes when 
called directly:
>>> x = [1]
>>> list.__getitem__(x, -1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: list index out of range

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

>Comment By: Walter Dіrwald (doerwalter)
Date: 2001-08-02 09:30

Message:
Logged In: YES 
user_id=89016

BTW, __setslice__  has the same problem:
>>> x = [1,2,3,4]
>>> x.__setslice__(-2,-1, [5])
>>> x
[5, 1, 2, 3, 4]


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-20 13:33

Message:
Logged In: YES 
user_id=6380

This is deeper than it seems.

The list object  never interprets negative indices -- that's
all done under the covers of the implementation in
PySequence_GetItem().

So list.__getitem__(), which is a very thin wrapper around
the list object's tp_as_sequence->sq_item function
(list_item in listobject.c), also doesn't interpret negative
indices.

But because __getitem__ is ambiguous (it can be a sequence
or a mapping operation, with slightly different semantics),
when you define a subclass that implements __getitem__, and
you pass an instance of that subclass a negative index, the
special handling of negative indices is skipped, so a[-1]
ends up calling a.__getitem__(-1).

This is not good.  I'll have to think about a way out of
this dilemma. Moving the negative index handling into the
objects is an option, but this might break with 3rd party
sequence objects. Doing the negative index handling twice
(once in PySequence_GetItem() and again in the object) is
bad, because it changes the semantics of very large negative
indices.


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

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


From noreply@sourceforge.net  Thu Aug  2 18:37:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 10:37:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15SMPD-000088-00@usw-sf-web1.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Works For Me
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 10:37

Message:
Logged In: NO 

Guido,

I forgot to mention that
the new image would not find
any of the standard modules
on the sys.path since I unstowed
my old instatallation be fore the build
and ~/local/SRC/Python2.2a1/Lib is not
on sys.path.
(You expected it to be there automatically if I remeber)

Daniel

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 10:19

Message:
Logged In: NO 

Guido,

Yes, the sys.path does make sense.
I use stow <http://www.gnu.org/software/stow/manual.html>
to manage my downloaded software.
So package X ends up being installed at $HOME/local/STOW/X.
Stow then creates symlinks to make it look like it is
installed at $HOME/local.
This makes it easy to tell which file belongs to which
package without having PATH, INCLUDE etc be as long as your
arm.
I have a make file $HOME/local which when invoked with "make
X", 
untars $HOME/local/TAR/X.tgz into $HOME/local/SRC
does 
$ cd $HOME/local/SRC/X
where it then does
$ ./configure --prefix=$HOME/local/STOW/X
$ make
$ make install
finally it then does
$ cd $HOME/local/STOW
$ stow X

Therefore, PYTHONPATH is $HOME/local
so I do not have to change it between installs.
This has worked with
versions 1.5.2, 1.6, 2.0, and 2.1,
and with all GNU software,
and most other autoconfiguring software. 

Here is the python section of my .bashrc

# Python
export PYAPPS=$LOCAL/PYTHON
alias pyapps='/bin/ls -d $PYAPPS/*'
alias pyappspath='jn : `pyapps`'
export PYTHONHOME=$LOCAL
export PYTHONSTARTUP=~/.pythonrc.global.py
export PYTHONSTARTUPPATH=~/.pythonrc.py:./.pythonrc.py
export PYTHONPATH=.:`pyappspath`:$LIB/python:$PYTHONPATH
export PATH=$PYTHONPATH:$PATH

Here is the makefile
I use to build GNU style software.
+++++++++++++++++++++++++++++++++++++++++++
.SUFFIXES: .jar .tar .tar.bz2 .tar.gz .tgz .Z .zip .build
.kill .clean .check .test


#ANT_JARS=find $(JAVA_DIR)/SRC/dist -name "*.jar"
#ANT_PATH=jn : \



%: STOW/%
	rm -f $</info/dir; # remove this line if installing emacs
itself
	(cd STOW; stow $(<F));

STOW/%: SRC/%/Makefile
	 $(MAKE) $(@F).kill;
	 cp -a STOW/LOCAL $@
	 $(MAKE) -C SRC/$(@F) install;

#%: SRC/%/build.xml
#	 CLASSPATH=`$(ANT_PATH)`:$(CLASSPATH)
#	 ant -buildfile $< all

#STOW/%: SRC/%/build.sh
#	(cd $(<D); sh ./build.sh -Dbuild=$@)

#%: SRC/%/build.sh
#	$(<D)/build.sh -buildfile $< all

# SRC/%/build.sh: SRC/%

# SRC/%/build.xml: SRC/%

#SRC/%.build: SRC/%/Makefile
#	 $(MAKE) -C $(<D);

SRC/%/Makefile: SRC/%
#	(HERE=`(cd ..; pwd)`; cd $<;  ./configure
--prefix=$$HERE/STOW/$(<F))
	cd $<; ./configure --prefix=$(STOW)/$(<F)

SRC/%: TAR/%.tgz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.gz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.Z
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.zip
	unzip -d $(@) $<

SRC/%: TAR/%.tar
	tar fx $< --directory $(@D);

TAR/%.tar: TAR/%.tar.bz2
	bunzip2 $<

SRC/%: TAR/%.jar
	jar fx $< --directory $(@D);

%.kill:
	(cd STOW; stow -D $(*F))
	rm -rf  STOW/$(*F);

%.clean: %.kill
	rm -rf SRC/$(*F);

%.check: SRC/%/Makefile
	 $(MAKE) -C $(<D) check;

%.test: SRC/%/Makefile
	 $(MAKE) -C $(<D) test;
+++++++++++++++++++++++++++++++++++++++++++++++++

My ~/pythonrc.global.py is

+++++++++++++++++++++++++++++++++++++++++++++++++
import os
import string

path = string.split(os.environ.get('PYTHONSTARTUPPATH'),':')
for file in path:
    if os.path.isfile(file):
        execfile(file)
+++++++++++++++++++++++++++++++++++++++++++++++++

but that should not be coming into play
when python is being invoked by make

regards
Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 05:28

Message:
Logged In: YES 
user_id=6380

You have to do some thinking yourself too, you know. :-)

Does that sys.path value make any sense to you? It doesn't
match the prefix.

Are the missing modules found on any of those?

What other env vars do you have set that start with PYTHON?
Do you have PYTHONHOME?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:57

Message:
Logged In: NO 

$ ./python
'import site' failed; use -v for traceback
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> import sys
>>> sys.path
['', '.', '/home/mahler/local/PYTHON/Meta',
'/home/mahler/local/PYTHON/kwP',
'/home/mahler/local/lib/python',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/APPS/jack-2.2.0',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/lib/python2.2/',
'/home/mahler/local/lib/python2.2/plat-linux2',
'/home/mahler/local/lib/python2.2/lib-tk',
'/home/mahler/local/lib/python2.2/lib-dynload']
>>> 


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Thu Aug  2 20:34:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 12:34:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-446588 ] Python-2.2a1 build dies
Message-ID: <E15SOEW-0000NI-00@usw-sf-web3.sourceforge.net>

Bugs item #446588, was opened at 2001-07-31 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446588&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Python-2.2a1 build dies

Initial Comment:
after doing:

./configure --prefix=$HOME/local/STOW
make

the build bombs in the install phase with:

usr/bin/install -c ./install-sh
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/install-sh
/usr/bin/install -c -m 644 ./Misc/Makefile.pre.in
/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/config/Makefile.pre.in
PYTHONPATH= ./python ./setup.py install \

--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in ?
    import sys, os, getopt
ImportError: No module named os
make[1]: *** [sharedinstall] Error 1
make[1]: Leaving directory
`/mcallister0/home/mahler/local/SRC/Python-2.2a1'
make: *** [STOW/Python-2.2a1] Error 2
rm SRC/Python-2.2a1make: unlink: SRC/Python-2.2a1: Is a
directory
 STOW/Python-2.2a1make: unlink: STOW/Python-2.2a1: Is a
directory
 SRC/Python-2.2a1/Makefile


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:34

Message:
Logged In: YES 
user_id=6380

Aha.  The .bashrc plus the remark about the unstow solves
the mystery.
This is fixed in CVS but not yet in the 2.2a1 release.
To make it work with this release you have to unset
PYTHONHOME.
In 2.2a2 and later this is solved by the -E command line
option.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 10:37

Message:
Logged In: NO 

Guido,

I forgot to mention that
the new image would not find
any of the standard modules
on the sys.path since I unstowed
my old instatallation be fore the build
and ~/local/SRC/Python2.2a1/Lib is not
on sys.path.
(You expected it to be there automatically if I remeber)

Daniel

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 10:19

Message:
Logged In: NO 

Guido,

Yes, the sys.path does make sense.
I use stow <http://www.gnu.org/software/stow/manual.html>
to manage my downloaded software.
So package X ends up being installed at $HOME/local/STOW/X.
Stow then creates symlinks to make it look like it is
installed at $HOME/local.
This makes it easy to tell which file belongs to which
package without having PATH, INCLUDE etc be as long as your
arm.
I have a make file $HOME/local which when invoked with "make
X", 
untars $HOME/local/TAR/X.tgz into $HOME/local/SRC
does 
$ cd $HOME/local/SRC/X
where it then does
$ ./configure --prefix=$HOME/local/STOW/X
$ make
$ make install
finally it then does
$ cd $HOME/local/STOW
$ stow X

Therefore, PYTHONPATH is $HOME/local
so I do not have to change it between installs.
This has worked with
versions 1.5.2, 1.6, 2.0, and 2.1,
and with all GNU software,
and most other autoconfiguring software. 

Here is the python section of my .bashrc

# Python
export PYAPPS=$LOCAL/PYTHON
alias pyapps='/bin/ls -d $PYAPPS/*'
alias pyappspath='jn : `pyapps`'
export PYTHONHOME=$LOCAL
export PYTHONSTARTUP=~/.pythonrc.global.py
export PYTHONSTARTUPPATH=~/.pythonrc.py:./.pythonrc.py
export PYTHONPATH=.:`pyappspath`:$LIB/python:$PYTHONPATH
export PATH=$PYTHONPATH:$PATH

Here is the makefile
I use to build GNU style software.
+++++++++++++++++++++++++++++++++++++++++++
.SUFFIXES: .jar .tar .tar.bz2 .tar.gz .tgz .Z .zip .build
.kill .clean .check .test


#ANT_JARS=find $(JAVA_DIR)/SRC/dist -name "*.jar"
#ANT_PATH=jn : \



%: STOW/%
	rm -f $</info/dir; # remove this line if installing emacs
itself
	(cd STOW; stow $(<F));

STOW/%: SRC/%/Makefile
	 $(MAKE) $(@F).kill;
	 cp -a STOW/LOCAL $@
	 $(MAKE) -C SRC/$(@F) install;

#%: SRC/%/build.xml
#	 CLASSPATH=`$(ANT_PATH)`:$(CLASSPATH)
#	 ant -buildfile $< all

#STOW/%: SRC/%/build.sh
#	(cd $(<D); sh ./build.sh -Dbuild=$@)

#%: SRC/%/build.sh
#	$(<D)/build.sh -buildfile $< all

# SRC/%/build.sh: SRC/%

# SRC/%/build.xml: SRC/%

#SRC/%.build: SRC/%/Makefile
#	 $(MAKE) -C $(<D);

SRC/%/Makefile: SRC/%
#	(HERE=`(cd ..; pwd)`; cd $<;  ./configure
--prefix=$$HERE/STOW/$(<F))
	cd $<; ./configure --prefix=$(STOW)/$(<F)

SRC/%: TAR/%.tgz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.gz
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.tar.Z
	tar zfx $< --directory $(@D);

SRC/%: TAR/%.zip
	unzip -d $(@) $<

SRC/%: TAR/%.tar
	tar fx $< --directory $(@D);

TAR/%.tar: TAR/%.tar.bz2
	bunzip2 $<

SRC/%: TAR/%.jar
	jar fx $< --directory $(@D);

%.kill:
	(cd STOW; stow -D $(*F))
	rm -rf  STOW/$(*F);

%.clean: %.kill
	rm -rf SRC/$(*F);

%.check: SRC/%/Makefile
	 $(MAKE) -C $(<D) check;

%.test: SRC/%/Makefile
	 $(MAKE) -C $(<D) test;
+++++++++++++++++++++++++++++++++++++++++++++++++

My ~/pythonrc.global.py is

+++++++++++++++++++++++++++++++++++++++++++++++++
import os
import string

path = string.split(os.environ.get('PYTHONSTARTUPPATH'),':')
for file in path:
    if os.path.isfile(file):
        execfile(file)
+++++++++++++++++++++++++++++++++++++++++++++++++

but that should not be coming into play
when python is being invoked by make

regards
Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 05:28

Message:
Logged In: YES 
user_id=6380

You have to do some thinking yourself too, you know. :-)

Does that sys.path value make any sense to you? It doesn't
match the prefix.

Are the missing modules found on any of those?

What other env vars do you have set that start with PYTHON?
Do you have PYTHONHOME?

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:57

Message:
Logged In: NO 

$ ./python
'import site' failed; use -v for traceback
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> import sys
>>> sys.path
['', '.', '/home/mahler/local/PYTHON/Meta',
'/home/mahler/local/PYTHON/kwP',
'/home/mahler/local/lib/python',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/APPS/jack-2.2.0',
'/home/mahler/local/lib/python2.1',
'/home/mahler/local/lib/python2.2/',
'/home/mahler/local/lib/python2.2/plat-linux2',
'/home/mahler/local/lib/python2.2/lib-tk',
'/home/mahler/local/lib/python2.2/lib-dynload']
>>> 


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:34

Message:
Logged In: YES 
user_id=6380

Need more info.  Try this:

./python
>>> import sys
>>> print sys.path



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:19

Message:
Logged In: NO 

python only starts correctly if I give it the Lib path:
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ ./python -v
'import site' failed; traceback:
ImportError: No module named site
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
Traceback (most recent call last):
  File "/home/mahler/.pythonrc.global.py", line 1, in ?
    import os
ImportError: No module named os
>>> 
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
$ PYTHONPATH=Lib ./python -v
# Lib/site.pyc matches Lib/site.py
import site # precompiled from Lib/site.pyc
# Lib/os.pyc matches Lib/os.py
import os # precompiled from Lib/os.pyc
import posix # builtin
# Lib/posixpath.pyc matches Lib/posixpath.py
import posixpath # precompiled from Lib/posixpath.pyc
# Lib/stat.pyc matches Lib/stat.py
import stat # precompiled from Lib/stat.pyc
# Lib/UserDict.pyc matches Lib/UserDict.py
import UserDict # precompiled from Lib/UserDict.pyc
Python 2.2a1 (#4, Aug  1 2001, 16:55:28) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on
linux2
Type "copyright", "credits" or "license" for more
information.
#
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
matches
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.py
import string # precompiled from
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Lib/string.pyc
>>>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Daniel


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 15:08

Message:
Logged In: YES 
user_id=6380

Hm.  Why does the newly built image not know that ./Lib is
the library?  This works for me!  (Note that PYTHONPATH gets
appended to the default sys.path, so setting it empty
shouldn't make a difference.)

What happens when you execute ./python at the command line? 
Does "import site" also fail there?

Please try to poke around for more evidence.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-01 15:00

Message:
Logged In: NO 

Yes, I made a boo boo:
--prefix=$HOME/local/STOW/Python-2.2a1
$PYTHONHOME is $HOME/local
since I use stow to manage all my dowloaded software in
$HOME/local.
This has always worked in the past.
I have a script which automactes the whole
untar, configure,make, install process to stop me making 
errors like the above.
The problem appears to be that last command:
PYTHONPATH= ./python ./setup.py install  ...
sets the $PYTHONPATH to be empty and the newly built image
does not know that the libraries are in the Lib directory
just below it.
doing
PYTHONPATH=./Lib ./python ./setup.py install
--install-platlib=/home/mahler/local/STOW/Python-2.2a1/lib/python2.2/lib-dynload
does not crash but produces a whole bunch of warnings like:

building 'zlib' extension
skipping
/mcallister0/home/mahler/local/SRC/Python-2.2a1/Modules/zlibmodule.c
(build/temp.linux-i686-2.2/zlibmodule.o up-to-date)
gcc -shared build/temp.linux-i686-2.2/zlibmodule.o
-L/usr/local/lib -lz -o build/lib.linux-i686-2.2/zlib.so
WARNING: removing "zlib" since importing it failed

Daniel

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:55

Message:
Logged In: YES 
user_id=6380

I can't reproduce this; configuring with a prefix works
fine.

Your story seems inconsistent: you say you configured with
prefix $HOME/local/STOW, but the output you cite looks like
it was configured with prefix $HOME/local/STOW/Python-2.2a1.

What platform?  What's $PYTHONHOME?

Try adding -v to the python invocation that fails to see the
failure traceback.

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

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


From noreply@sourceforge.net  Thu Aug  2 20:41:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 12:41:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15SOLh-000732-00@usw-sf-web2.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Thu Aug  2 20:44:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 12:44:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Unicode Build Prob.
Message-ID: <E15SOOS-0001C8-00@usw-sf-web3.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Unicode Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Thu Aug  2 20:47:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 12:47:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-447152 ] WeakValueDictionary wrong except. rised
Message-ID: <E15SORU-0005Dk-00@usw-sf-web1.sourceforge.net>

Bugs item #447152, was opened at 2001-08-02 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447152&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Niki Spahiev (nikis)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: WeakValueDictionary wrong except. rised

Initial Comment:
PythonWin 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit
(Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond
(MarkH@ActiveState.com) - see 'Help/About PythonWin'
for further copyright information.
>>> import weakref
>>> wd = weakref.WeakValueDictionary()
>>> class test: pass
...
>>> t = test()
>>> wd[1] = t
>>> del t
>>> wd[1]
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "c:\python21\lib\weakref.py", line 35, in __getitem__
o = self.data.get(key)()
TypeError: object is not callable: None
>>> 


FIX:
change
o = self.data.get(key)()
to
o = self.data[key]()


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:47

Message:
Logged In: YES 
user_id=6380

Assigned to Fred.

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

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


From noreply@sourceforge.net  Thu Aug  2 22:38:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 14:38:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-446971 ] im_func, user-defined method
Message-ID: <E15SQAl-0002ar-00@usw-sf-web2.sourceforge.net>

Bugs item #446971, was opened at 2001-08-01 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446971&group_id=5470

Category: Documentation
>Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: im_func, user-defined method

Initial Comment:
>From the language reference:

3.2 The standard type hierarchy 

User-defined methods:

A user-defined method object combines a class, a class 
instance (or None) and a user-defined function.
...

I take issue with 'user-defined function'.  In my 
experiments with Python 2.1.1 on Windows 2000, using 
the C API, a user-defined method can combine a 'user-
defined function' OR a 'builtin function'.

I call PyObject_GetAttrString( pPyObject, "im_func" ), 
and a built-in function type object is returned.

Tom.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-02 14:38

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref3.tex revision 1.71.

The manual used to be right, but more flexibility was added.
 Normal usage still only finds user-defined functions there,
but the exceptions module uses built-in functions, and the
"new" module can be used to construct more interesting
objects as well.

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

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


From noreply@sourceforge.net  Fri Aug  3 01:49:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 17:49:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-447370 ] typo in urllib2.py
Message-ID: <E15ST9u-0008Bz-00@usw-sf-web1.sourceforge.net>

Bugs item #447370, was opened at 2001-08-02 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447370&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: typo in urllib2.py

Initial Comment:
in line 662 of urllib2.py the 'o' and 'w' are 
transposed:

passwd = HTTPPassowrdMgr()



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

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


From noreply@sourceforge.net  Fri Aug  3 02:22:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 18:22:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-447370 ] typo in urllib2.py
Message-ID: <E15STfy-0000v1-00@usw-sf-web1.sourceforge.net>

Bugs item #447370, was opened at 2001-08-02 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447370&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: typo in urllib2.py

Initial Comment:
in line 662 of urllib2.py the 'o' and 'w' are 
transposed:

passwd = HTTPPassowrdMgr()



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 18:22

Message:
Logged In: YES 
user_id=6380

Assigned to Jeremy.  There are more typos, e.g. OpenerDirectory instead of OpenerDirector.  Should I paste 
the pychecker output here?

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

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


From noreply@sourceforge.net  Fri Aug  3 05:12:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 02 Aug 2001 21:12:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-447152 ] WeakValueDictionary wrong except. rised
Message-ID: <E15SWKF-00088o-00@usw-sf-web2.sourceforge.net>

Bugs item #447152, was opened at 2001-08-02 05:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447152&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Niki Spahiev (nikis)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: WeakValueDictionary wrong except. rised

Initial Comment:
PythonWin 2.1 (#15, Jun 18 2001, 21:42:28) [MSC 32 bit
(Intel)] on win32.
Portions Copyright 1994-2001 Mark Hammond
(MarkH@ActiveState.com) - see 'Help/About PythonWin'
for further copyright information.
>>> import weakref
>>> wd = weakref.WeakValueDictionary()
>>> class test: pass
...
>>> t = test()
>>> wd[1] = t
>>> del t
>>> wd[1]
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
File "c:\python21\lib\weakref.py", line 35, in __getitem__
o = self.data.get(key)()
TypeError: object is not callable: None
>>> 


FIX:
change
o = self.data.get(key)()
to
o = self.data[key]()


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-02 21:12

Message:
Logged In: YES 
user_id=3066

Fixed in Lib/weakref.py revision 1.11.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:47

Message:
Logged In: YES 
user_id=6380

Assigned to Fred.

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

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


From noreply@sourceforge.net  Fri Aug  3 08:50:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 00:50:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15SZii-0001xM-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Fri Aug  3 20:55:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 12:55:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-445196 ] Hexadecimal character references break HTMLParser
Message-ID: <E15Sl2K-0007JP-00@usw-sf-web2.sourceforge.net>

Bugs item #445196, was opened at 2001-07-27 08:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445196&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Hexadecimal character references break HTMLParser

Initial Comment:
This bug affects both the Python standard library and Zope TAL. 

Input such as this:

     &#x201C;Backwards substitution&#x201D; 

in a Page Template results in this error:

 <!-- Page Template Diagnostics
  Compilation failed
  TAL.HTMLParser.HTMLParseError: EOF in middle of entity or char ref, at line
 759, column 150

Chris Withers writes:
 > Squishdot has experienced this problem too.
 > It's a problem in HTMLPArser.py apparently.



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 12:55

Message:
Logged In: YES 
user_id=3066

Fixed in Lib/HTMLParser.py revision 1.4 for Python.  Will be checked into the Zope repository as well once the repository is back online later today.

A regression test was added for this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 09:06

Message:
Logged In: YES 
user_id=6380

Aha. I guess you are already fixing it then. :-)

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

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

Message:
Logged In: YES 
user_id=3066

The summary line was wrong (now fixed); these are *not* malformed; they are hexidecimal character references and a legal XHTML.  As long as HTMLParser is trying to accept XHTML (which was part of its original purpose), it needs to accept these.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:55

Message:
Logged In: YES 
user_id=6380

Malformed HTML in general causes an exception.

What would you *want* to see happen?

Why can't you just fix the HTML source?  After all, it's
malformed!


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

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


From noreply@sourceforge.net  Fri Aug  3 21:25:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 13:25:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15SlVn-0003v1-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Fri Aug  3 21:46:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 13:46:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file
Message-ID: <E15SlqB-00036n-00@usw-sf-web1.sourceforge.net>

Bugs item #439710, was opened at 2001-07-09 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: User-defined mime.types file

Initial Comment:
Zope users sometimes asks to add
additional mime.types entries to Zope. 
Zopes mime-types handling is mostly 
based on mimetypes.py. In such cases
users should be able to maintain their
own mime.types files. 

mimetypes.py currently tries to look
for mime.types files in 4 hardcoded locations.

It would be more convinient to specify
additional locations e.g. by an env. var
that holds a list of additional locations
or by any other mechanism that allows user-defined
locations. 

The hardcoded locations also don't work on
Windows.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 13:46

Message:
Logged In: YES 
user_id=3066

Ok, I've revised this again, to be a little cleaner and more consistent internally.  I've attached a copy and will check it in as soon as I'm sure the updated documentation won't break the formatting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-27 07:28

Message:
Logged In: YES 
user_id=3066

OK, I really should update the version here to be the fixed one; sorry about the broken versions!  If there are no objections, I'll check this in soon.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-23 19:51

Message:
Logged In: YES 
user_id=3066

I've attached a new version of mimetypes.py; something like this should do the trick and be easy to extend as needed.

Comments welcome.

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

Comment By: Andreas Jung (ajung)
Date: 2001-07-23 13:12

Message:
Logged In: YES 
user_id=11084

A more OO approach would be nice. At least a possibility to add "somehow"
different file locations. I have not special preference for any solution. 

Andreas

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-23 13:07

Message:
Logged In: YES 
user_id=3066

Sounds like there should be an object which can be configured with a search path at construction time.  Applications could then store an appropriate mime.types file in a location that makes sense for them.

Would this suite your purposes?

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

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


From noreply@sourceforge.net  Fri Aug  3 22:04:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 14:04:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-439710 ] User-defined mime.types file
Message-ID: <E15Sm7O-0003ku-00@usw-sf-web1.sourceforge.net>

Bugs item #439710, was opened at 2001-07-09 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439710&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: User-defined mime.types file

Initial Comment:
Zope users sometimes asks to add
additional mime.types entries to Zope. 
Zopes mime-types handling is mostly 
based on mimetypes.py. In such cases
users should be able to maintain their
own mime.types files. 

mimetypes.py currently tries to look
for mime.types files in 4 hardcoded locations.

It would be more convinient to specify
additional locations e.g. by an env. var
that holds a list of additional locations
or by any other mechanism that allows user-defined
locations. 

The hardcoded locations also don't work on
Windows.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 14:04

Message:
Logged In: YES 
user_id=3066

Checked in the new version as Lib/mimetypes.py revision 1.15, with documentation in Doc/lib/libmimetypes.tex revision 1.8.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 13:46

Message:
Logged In: YES 
user_id=3066

Ok, I've revised this again, to be a little cleaner and more consistent internally.  I've attached a copy and will check it in as soon as I'm sure the updated documentation won't break the formatting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-27 07:28

Message:
Logged In: YES 
user_id=3066

OK, I really should update the version here to be the fixed one; sorry about the broken versions!  If there are no objections, I'll check this in soon.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-23 19:51

Message:
Logged In: YES 
user_id=3066

I've attached a new version of mimetypes.py; something like this should do the trick and be easy to extend as needed.

Comments welcome.

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

Comment By: Andreas Jung (ajung)
Date: 2001-07-23 13:12

Message:
Logged In: YES 
user_id=11084

A more OO approach would be nice. At least a possibility to add "somehow"
different file locations. I have not special preference for any solution. 

Andreas

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-23 13:07

Message:
Logged In: YES 
user_id=3066

Sounds like there should be an object which can be configured with a search path at construction time.  Applications could then store an appropriate mime.types file in a location that makes sense for them.

Would this suite your purposes?

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

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


From noreply@sourceforge.net  Fri Aug  3 22:40:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 14:40:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15Smfr-00076t-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sat Aug  4 03:00:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 19:00:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-440037 ] Extending: need import examples
Message-ID: <E15SqkI-0007jF-00@usw-sf-web3.sourceforge.net>

Bugs item #440037, was opened at 2001-07-10 06:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440037&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Extending: need import examples

Initial Comment:
Hello,

I have been writing a code generator to call functions
in a Python script from C. The code seems to be working
fine.
In the process, I found some things in the C API manual
that can be improved:

- I would expect 7.4 (numeric objects) before 7.2
(sequence objects)
- PyList_SetItem() does not specify return value
(probably the same as PyTuple_SetItem() "It returns 0
on success.")
- PyList_SET_ITEM() returns a borrowed reference
without specifying to what it refers.
- PyDict_SetItem() doesnot use 'p' in the description
(same for PyDict_SetItemString())
- Return value of both functions is also not specified.
- In PyLong_AsLong(), a stray 'OverflowError' is at the
end of the description.
- Also at PyLong_AsUnsignedLong() (next entry)

What I found lacking in the embedding and extending
manual is the importing of modules, and finding a
function with a specific name from C.  Is this
something that should be included in the EE manual ?
(I'd be willing to give it some thought)

Also, I found 2 'problems' in the interface at code
level. I will add this seperately to the bug report
data base.

Albert (a.t.hofkamp@tue.nl)


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 19:00

Message:
Logged In: YES 
user_id=3066

Albert Hofkamp contributed a section that included a good example of importing a module and using it.  It will appear in the "Embedding Python" chapter.

Checked in as Doc/ext/ext.tex revision 1.102 and Doc/ext/run-func.c revision 1.1.

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

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

Message:
Logged In: YES 
user_id=3066

The recommended re-ordering of sections has been implemented
in Doc/api/api.tex revisions 1.130 and 1.117.2.9.  The
change was included in the 2.1 maintenance branch since this
is a readability bug.

All that remains for this issue are the additions to the
Extending & Embedding manual, so I'm changing the summary as
well.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-10 09:14

Message:
Logged In: YES 
user_id=3066

The corrections and additions to the API manual have been
committed as Doc/api/api.tex revisions 1.129 and 1.117.2.8.
 Re-ordering of sections will be considered separately.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-10 09:06

Message:
Logged In: NO 

Regarding the order of numeric and sequence objects:

My idea is that numeric objects are easier to understand
than sequence objects. So when browsing through the
documentation (I know the docs are not supposed to be
browsed, but before being able to work with it, one has to
read the EE manual, and probably browse the API manual to
get a feel for the API calls available), the interface for
the numeric objects are relatively easy to understand. With
that knowledge, the next sections become easier, because the
api's for the other objects have a similar structure.

Albert

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-10 08:23

Message:
Logged In: YES 
user_id=3066

I don't understand the comment on the ordering of the
Numeric and Sequence object sections; what is the motivation
for changing the ordering?

Regarding the issue of import & function lookup:  Yes, the
EE manual should cover this.  Suggested text would be
greatly appreciated (without markup is fine), or I can work
on it when time permits.

I've fixed the other issues in my working copy; these should
be checked in before too long.

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

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


From noreply@sourceforge.net  Sat Aug  4 04:11:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 20:11:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-444486 ] Potential leak in Py_InitModule4()
Message-ID: <E15Srqn-0006Ph-00@usw-sf-web2.sourceforge.net>

Bugs item #444486, was opened at 2001-07-25 07:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444486&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Potential leak in Py_InitModule4()

Initial Comment:
Martin Sjіgren discovered that Py_InitModule4() doesn't
DECREF v when either of the PyDict_SetItemString()
calls fails.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 20:11

Message:
Logged In: YES 
user_id=3066

Fixed in Python/modsupport.c revision 2.57.

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

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


From noreply@sourceforge.net  Sat Aug  4 04:39:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 20:39:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-433234 ] Problems building under HP-UX 11.0
Message-ID: <E15SsHF-0002N3-00@usw-sf-web1.sourceforge.net>

Bugs item #433234, was opened at 2001-06-14 13:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433234&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Munoz (imbunche)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Problems building under HP-UX 11.0

Initial Comment:
My system:
HP-UX dev1 B.11.00 A 9000/782 2015744842 two-user
license

I'm using gcc, gcc version 2.95.2 19991024 (release)


Trying to compile Python 2.1 I ran into a number of
problems.

After the customary configure; make I get the following
error while making the modules

ld: DP relative code in file
build/temp.hp-ux-B.11.00-9000/782-2.1/_weakref.o -
shared library must be position
independent.  Use +z or +Z to recompile.
WARNING: building of extension "_weakref" failed:
command 'ld' failed with exit status 1

The error message is the same for all extensions.

I fixed it by defining in the Makefile
CFLAGSFORSHARED=-fpic

tried again ... better but:

gcc  -Wl,-E -Wl,+s
-Wl,+b/home/imunoz/local/hp/lib/python2.1/lib-dynload
-o python \
                Modules/python.o \
                libpython2.1.a -lnsl -ldld  -lpthread  
-lm  
/usr/bin/ld: Data Linkage Table (+z) overflow in file
libpython2.1.a(exceptions.o) - use +Z option to
recompile
collect2: ld returned 1 exit status
make: *** [python] Error 1

Then I changed -fpic by -fPIC and voila! (tip found
thanx to a google search).

still problems when generating the module's shared
libraries. Fixed by:
Makefile:301
# Build the shared modules
sharedmods: $(PYTHON)
PY_CFLAGS=	$(CFLAGS) $(CFLAGSFORSHARED) -fPIC
	PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py build

This last step I don't understand but Python won't make
the modules without it.


Finally got Python 2.1 in HP-UX 11. Does anyone knows a
better way?


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

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


From noreply@sourceforge.net  Sat Aug  4 04:54:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 03 Aug 2001 20:54:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E15SsWU-0002ZU-00@usw-sf-web1.sourceforge.net>

Bugs item #414316, was opened at 2001-04-06 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414316&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 20:54

Message:
Logged In: YES 
user_id=3066

Assigned to me, since Paul has asked me about this and I
don't want to keep that mail in my inbox forever.

Paul, please tell me exactly what you're seeing:  what
permissions are set on the file in the source directory,
what's the umask you're using, and what are the final
permissions of the installed file.  The only thing that the
install_scripts command appears to be doing is ensuring that
the executable bit is set.

Is the "group-sticky" bit set in the destination directory?
 How do the identities of the installer relate to the
owner/group of the destination directory?

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-07 13:04

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward.

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

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


From noreply@sourceforge.net  Sat Aug  4 09:17:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 01:17:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-445928 ] UnboundLocalError in httplib.py
Message-ID: <E15Swck-0004Bj-00@usw-sf-web1.sourceforge.net>

Bugs item #445928, was opened at 2001-07-30 05:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445928&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Martin v. Lіwis (loewis)
Summary: UnboundLocalError in httplib.py

Initial Comment:
Python 2.2a0 (#1, 07/30/01, 13:21:09) 
[GCC Apple DevKit-based CPP 6.0alpha] on darwin1
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import urllib
>>> f = urllib.urlopen("http://www.letterror.com/")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/urllib.py", line 71, in 
urlopen
    return _urlopener.open(url)
  File "/usr/local/lib/python2.2/urllib.py", line 176, 
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 283, 
in open_http
    h.putrequest('GET', selector)
  File "/usr/local/lib/python2.2/httplib.py", line 449, 
in putrequest
    self.send(str)
  File "/usr/local/lib/python2.2/httplib.py", line 391, 
in send
    self.connect()
  File "/usr/local/lib/python2.2/httplib.py", line 375, 
in connect
    raise socket.error, msg
UnboundLocalError: local variable 'msg' referenced 
before assignment
>>>


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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-04 01:17

Message:
Logged In: YES 
user_id=21627

The getaddrinfo bug was fixed in socketmodule.c 1.160.
The unbound local bug was fixed in httplib 1.38


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 19:00

Message:
Logged In: YES 
user_id=6380

IMO it's still ugly to have code that relies on a variable
set in an except clause in a for loop. Any decent
compile-time checker would flag this as a potential error.
No matter how getaddrinfo() is fixed, I think httplib.py
should be made more robust as well.


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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-30 15:40

Message:
Logged In: YES 
user_id=21627

I believe getaddrinfo must never return an empty list. If 
lookup fails, it shall raise an exception. From the 
Solaris manpage
<man>
For getaddrinfo(), if the query is successful, a pointer to
a  linked  list  of  one  or  more addrinfo structures
is returned by the fourth argument and the function
returns 0. If the query fails, a non-zero error code will
be returned.
</man>

So returning a 0 result and an empty list is an 
implementation bug in getaddrinfo (or an incorrect call to 
it). If we want to protect us against buggy 
implementations, we should do BadInternalCall or similar 
in the C code, instead of dealing with the impossible case 
in Python.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 10:39

Message:
Logged In: YES 
user_id=6380

But even if getaddrinfo() returns an empty list, this error
should not occur.  You may have to initialize msg to
something and do something differently at the end when msg
is still None.

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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-30 08:42

Message:
Logged In: YES 
user_id=21627

It appears that Darwin does provide getaddrinfo. I'm not
sure why it doesn't work.

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

Comment By: Just van Rossum (jvr)
Date: 2001-07-30 07:43

Message:
Logged In: YES 
user_id=92689

socketmodule.c: 1.157
getaddrinfo.c: 1.6

socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREA
M) indeed returns an empty list.

I can try to give you access, but I'll have to fiddle with
permissions.


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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-30 07:16

Message:
Logged In: YES 
user_id=21627

Can you please indicate what version of socketmodule.c and
getaddrinfo.c was used for this build?

Please report the result of
import socket
socket.getaddrinfo('www.letterror.com',80,0,socket.SOCK_STREAM)

It should be something like
[(2, 2, 0, '', ('216.218.226.21', 80))]

If it is an empty list (as it appears from the error
message), can you please try step through 
PySocket_getaddrinfo with a debugger and analyse why it
doesn't find out the IP address? If not, is there a chance
to get access to such a machine to debug it myself remotely?


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

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


From noreply@sourceforge.net  Sat Aug  4 09:21:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 01:21:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-445986 ] test_locale fails on IRIX 6.5
Message-ID: <E15SwgG-0004Eo-00@usw-sf-web1.sourceforge.net>

Bugs item #445986, was opened at 2001-07-30 08:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445986&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Greg Ward (gward)
Summary: test_locale fails on IRIX 6.5

Initial Comment:
Built Python 2.2a1 on a 64-bit SGI box running IRIX
6.5.  test_locale fails as follows:

$ ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '     -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200      ' != '4,200     '


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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-04 01:21

Message:
Logged In: YES 
user_id=21627

This is a bug in the system C library, which fails to 
report proper separators in the en_US locale. Please 
complain to your operating system vendor; I propose to 
close this as "Won't fix".


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

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


From noreply@sourceforge.net  Sat Aug  4 12:17:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 04:17:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-447918 ] strange results from dir()
Message-ID: <E15SzQj-0006Jt-00@usw-sf-web2.sourceforge.net>

Bugs item #447918, was opened at 2001-08-04 04:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447918&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Uwe Zessin (zessin_5)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange results from dir()

Initial Comment:
The code is from the CVS, friday.

Output from V2.1.1:
>>> dir()
['__builtins__', '__doc__', '__name__', 'sys']
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', 
'__name__', '__stderr__',
...
That looks OK to me.

Output from V2.2-cvs from friday:
>>> dir()
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> dir(sys)
[__displayhook____displayhook__, __doc____doc__, 
__excepthook____excepthook__,
...
>>> a=dir()
>>> a
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> b=a[0]
>>> b
__builtins____builtins__
>>> type(b)
<type 'str'>
>>> print b
__builtins__
>>> repr(b)
'__builtins__'"'__builtins__'"
>>> len(b)
12
>>>

That does not look right to me.

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

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


From noreply@sourceforge.net  Sat Aug  4 16:02:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 08:02:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-447945 ] time.time() is not non-decreasing
Message-ID: <E15T2x5-0001pM-00@usw-sf-web3.sourceforge.net>

Bugs item #447945, was opened at 2001-08-04 08:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.time() is not non-decreasing

Initial Comment:
<p>After spending many hours tracking down weird race
conditions in <a href="http://mojonation.net/">Mojo
Nation</a>, I've finally realized that the problem is
that we assumed that <cite>time.time()</cite> would
return non-decreasing answers.  In fact, successive
calls to <cite>time.time()</cite> can return a
<em>smaller</em> number than previous calls, as
demonstrated by this test (Python 2.0 on debian
woody):</p>
<pre>
import time

x = 0
while 1:
    ox = x
    x = time.time()
    if x < ox:
        print "this is WRONG: ox: %s, x: %s\n" % (ox,
x,)
    else:
        print ".",
</pre>
<p>In order to get the race conditions out of Mojo
Nation, I'm writing a
<cite>non_decreasing_time()</cite>, which does what we
thought <cite>time()</cite> would do.  In fact, I might
just make it <cite>increasing_time()</cite>.  In any
case, the <cite>time.time()</cite> in the standard
library should either be fixed (my preference) to be
non-decreasing, or the documentation should be updated
to warn about the surprise.</p>
<p>Regards,</p>
<p><b><i>Zooko</i></b></p>

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

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


From noreply@sourceforge.net  Sat Aug  4 16:12:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 08:12:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15T36A-0006Nc-00@usw-sf-web2.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sat Aug  4 17:01:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 09:01:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-446049 ] file type is callable but crashes
Message-ID: <E15T3sC-00041g-00@usw-sf-web3.sourceforge.net>

Bugs item #446049, was opened at 2001-07-30 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446049&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: file type is callable but crashes

Initial Comment:
Calling the type of a file object results
in a crash.  More details to follow.


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

>Comment By: Gregory H. Ball (greg_ball)
Date: 2001-08-04 09:01

Message:
Logged In: YES 
user_id=11365

I played around a bit with the featureless objects, and they
are cute but hardly necessary, surely?  How would they be
documented?
(I see that they can be dictionary keys, which vaguely
suggests some kind
of application as tokens...?)

I like that you can inherit from object in python though. 
Do you have to be able to instantiate object to be able to
instantiate python-derived subclasses of object in the
current design?  If not I could certainly lose the
featureless objects.  It does seem like a reasonable goal to
avoid making objects which violate their invariants.

BTW, the file object is now (CVS) broken in respect of its 
closed attribute, which seems to be always 2, file open or
closed.
(This is on linux2.2)

Also,  is the fact that dir() turns up nothing on file
objects (which have four attributes) and on instances of
classes inheriting from object (and using __slots__ ) a bug
or just the way dir() is going to work now?

Cheers.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 08:02

Message:
Logged In: YES 
user_id=6380

The direct cause is that the tp_new slot inherited from
'object' creates a file object that is initialized to all
zeros, and the file object's tp_repr slot doesn't anticipate
that.

I can fix the file object in a number of ways (make it work
for uninitialized objects, or add a tp_new slot that
initializes it properly). But I expect that file is not the
only type that is vulnerable to this kind of attack,
especially 3rd party types that adopt
PyObject_GenericGetAttr() but don't define their own tp_new
are vulnerable.

The alternative would be to remove the default tp_new
implementation from 'object', and add one to dynamically
created types. That would mean you couldn't call object() to
get a featureless object, which is currently supported and
even tested in test_descr.py.

Any preferences?

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:57

Message:
Logged In: YES 
user_id=11365

Python 2.2a1 (#2, Jul 26 2001, 11:50:01) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> f = open('README')
>>> type(f)()
Segmentation fault (core dumped)

Seems to me that it would be nice if FileType
worked like the 'open' builtin.
You could have a 'file' builtin and alias it to open.
Wild speculation: I guess open could be eventually
deprecated.  At which point you could safely do 
from os import *  ;-)


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

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


From noreply@sourceforge.net  Sat Aug  4 18:07:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 10:07:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-445984 ] test___all__ fails when _socket absent
Message-ID: <E15T4tn-0001Sx-00@usw-sf-web2.sourceforge.net>

Bugs item #445984, was opened at 2001-07-30 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445984&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Greg Ward (gward)
Summary: test___all__ fails when _socket absent

Initial Comment:
If the _socket extension couldn't be built (see bug
#445980), test___all__ fails somewhat mysteriously:

$ ./python Lib/test/test___all__.py
Traceback (most recent call last):
  File "Lib/test/test___all__.py", line 42, in ?
    check_all("CGIHTTPServer")
  File "Lib/test/test___all__.py", line 10, in check_all
    exec "import %s" % modname in names
  File "<string>", line 1, in ?
  File "/tmp/Python-2.2a1/Lib/CGIHTTPServer.py", line
27, in ?
    import BaseHTTPServer
  File "/tmp/Python-2.2a1/Lib/BaseHTTPServer.py", line
72, in ?
    import SocketServer
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
273, in ?
    class TCPServer(BaseServer):
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
316, in TCPServer
    address_family = socket.AF_INET
AttributeError: 'module' object has no attribute 'AF_INET'



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

>Comment By: Greg Ward (gward)
Date: 2001-08-04 10:07

Message:
Logged In: YES 
user_id=14422

Guido's "fix" is close -- you actually have to
"import _socket" (trigger an ImportError) before
check_all("CGIHTTPServer"), because it imports socket.

With that "fix" made, the test result is:

  test test___all__ skipped --  No module named _socket

Should I check this in (one "import _socket" line added to test___all__.py)?  Or is this too arcane, ie. you're toast if _socket doesn't build, so don't bother trying to workaround it?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 08:50

Message:
Logged In: YES 
user_id=6380

This can be "fixed" by inserting "import _socket" in front
of the check_all("socket") line.

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

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


From noreply@sourceforge.net  Sat Aug  4 18:43:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 10:43:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-445984 ] test___all__ fails when _socket absent
Message-ID: <E15T5Sv-0008DQ-00@usw-sf-web3.sourceforge.net>

Bugs item #445984, was opened at 2001-07-30 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445984&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Greg Ward (gward)
Summary: test___all__ fails when _socket absent

Initial Comment:
If the _socket extension couldn't be built (see bug
#445980), test___all__ fails somewhat mysteriously:

$ ./python Lib/test/test___all__.py
Traceback (most recent call last):
  File "Lib/test/test___all__.py", line 42, in ?
    check_all("CGIHTTPServer")
  File "Lib/test/test___all__.py", line 10, in check_all
    exec "import %s" % modname in names
  File "<string>", line 1, in ?
  File "/tmp/Python-2.2a1/Lib/CGIHTTPServer.py", line
27, in ?
    import BaseHTTPServer
  File "/tmp/Python-2.2a1/Lib/BaseHTTPServer.py", line
72, in ?
    import SocketServer
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
273, in ?
    class TCPServer(BaseServer):
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
316, in TCPServer
    address_family = socket.AF_INET
AttributeError: 'module' object has no attribute 'AF_INET'



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 10:43

Message:
Logged In: YES 
user_id=6380

Sounds good to me.

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

Comment By: Greg Ward (gward)
Date: 2001-08-04 10:07

Message:
Logged In: YES 
user_id=14422

Guido's "fix" is close -- you actually have to
"import _socket" (trigger an ImportError) before
check_all("CGIHTTPServer"), because it imports socket.

With that "fix" made, the test result is:

  test test___all__ skipped --  No module named _socket

Should I check this in (one "import _socket" line added to test___all__.py)?  Or is this too arcane, ie. you're toast if _socket doesn't build, so don't bother trying to workaround it?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 08:50

Message:
Logged In: YES 
user_id=6380

This can be "fixed" by inserting "import _socket" in front
of the check_all("socket") line.

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

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


From noreply@sourceforge.net  Sat Aug  4 18:50:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 10:50:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-446049 ] file type is callable but crashes
Message-ID: <E15T5Ys-0003Q6-00@usw-sf-web2.sourceforge.net>

Bugs item #446049, was opened at 2001-07-30 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446049&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: file type is callable but crashes

Initial Comment:
Calling the type of a file object results
in a crash.  More details to follow.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 10:50

Message:
Logged In: YES 
user_id=6380

OK, I think I'll remove the object-instantiability then.

I'll also look at why file.closed is always 2 -- probably
because I misdefined the attribute descriptor and there's no
test suite for this.

And yes, this is how dir() is going to work (I think -- it
makes sense since this is how it works for classes too).

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-08-04 09:01

Message:
Logged In: YES 
user_id=11365

I played around a bit with the featureless objects, and they
are cute but hardly necessary, surely?  How would they be
documented?
(I see that they can be dictionary keys, which vaguely
suggests some kind
of application as tokens...?)

I like that you can inherit from object in python though. 
Do you have to be able to instantiate object to be able to
instantiate python-derived subclasses of object in the
current design?  If not I could certainly lose the
featureless objects.  It does seem like a reasonable goal to
avoid making objects which violate their invariants.

BTW, the file object is now (CVS) broken in respect of its 
closed attribute, which seems to be always 2, file open or
closed.
(This is on linux2.2)

Also,  is the fact that dir() turns up nothing on file
objects (which have four attributes) and on instances of
classes inheriting from object (and using __slots__ ) a bug
or just the way dir() is going to work now?

Cheers.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 08:02

Message:
Logged In: YES 
user_id=6380

The direct cause is that the tp_new slot inherited from
'object' creates a file object that is initialized to all
zeros, and the file object's tp_repr slot doesn't anticipate
that.

I can fix the file object in a number of ways (make it work
for uninitialized objects, or add a tp_new slot that
initializes it properly). But I expect that file is not the
only type that is vulnerable to this kind of attack,
especially 3rd party types that adopt
PyObject_GenericGetAttr() but don't define their own tp_new
are vulnerable.

The alternative would be to remove the default tp_new
implementation from 'object', and add one to dynamically
created types. That would mean you couldn't call object() to
get a featureless object, which is currently supported and
even tested in test_descr.py.

Any preferences?

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:57

Message:
Logged In: YES 
user_id=11365

Python 2.2a1 (#2, Jul 26 2001, 11:50:01) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> f = open('README')
>>> type(f)()
Segmentation fault (core dumped)

Seems to me that it would be nice if FileType
worked like the 'open' builtin.
You could have a 'file' builtin and alias it to open.
Wild speculation: I guess open could be eventually
deprecated.  At which point you could safely do 
from os import *  ;-)


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

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


From noreply@sourceforge.net  Sat Aug  4 19:03:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 11:03:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-447945 ] time.time() is not non-decreasing
Message-ID: <E15T5lz-0001TQ-00@usw-sf-web1.sourceforge.net>

Bugs item #447945, was opened at 2001-08-04 08:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.time() is not non-decreasing

Initial Comment:
<p>After spending many hours tracking down weird race
conditions in <a href="http://mojonation.net/">Mojo
Nation</a>, I've finally realized that the problem is
that we assumed that <cite>time.time()</cite> would
return non-decreasing answers.  In fact, successive
calls to <cite>time.time()</cite> can return a
<em>smaller</em> number than previous calls, as
demonstrated by this test (Python 2.0 on debian
woody):</p>
<pre>
import time

x = 0
while 1:
    ox = x
    x = time.time()
    if x < ox:
        print "this is WRONG: ox: %s, x: %s\n" % (ox,
x,)
    else:
        print ".",
</pre>
<p>In order to get the race conditions out of Mojo
Nation, I'm writing a
<cite>non_decreasing_time()</cite>, which does what we
thought <cite>time()</cite> would do.  In fact, I might
just make it <cite>increasing_time()</cite>.  In any
case, the <cite>time.time()</cite> in the standard
library should either be fixed (my preference) to be
non-decreasing, or the documentation should be updated
to warn about the surprise.</p>
<p>Regards,</p>
<p><b><i>Zooko</i></b></p>

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:03

Message:
Logged In: YES 
user_id=6380

I don't understand why this can happen. time.time() is a
simple wrapper around either gettimeofday(), ftime(), or
time(). So you should be able to reproduce this in C as
well, and it should be a kernel bug, unless somehow the
conversion to float is busted. Can you investigate?

Of course, if the super-user resets the system clock,
time.time() may also return non-monononous values -- I
assume that that's not what you're seeing -- but that's a
reason why Python can't guarantee a monotonously increasing
time.

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

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


From noreply@sourceforge.net  Sat Aug  4 19:26:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 11:26:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-447982 ] inconsistent availablility on modules
Message-ID: <E15T67f-00011l-00@usw-sf-web3.sourceforge.net>

Bugs item #447982, was opened at 2001-08-04 11:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447982&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent availablility on modules 

Initial Comment:
My last python 2.0 rpm has syslog module. I have just
downloaded the python-2.0.1.tgz from one of the python
mirror sites. That release has syslog module commented
out in Modules/Setup file.

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

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


From noreply@sourceforge.net  Sat Aug  4 19:36:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 11:36:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-447918 ] strange results from dir()
Message-ID: <E15T6I0-0004jz-00@usw-sf-web2.sourceforge.net>

Bugs item #447918, was opened at 2001-08-04 04:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447918&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Uwe Zessin (zessin_5)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange results from dir()

Initial Comment:
The code is from the CVS, friday.

Output from V2.1.1:
>>> dir()
['__builtins__', '__doc__', '__name__', 'sys']
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', 
'__name__', '__stderr__',
...
That looks OK to me.

Output from V2.2-cvs from friday:
>>> dir()
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> dir(sys)
[__displayhook____displayhook__, __doc____doc__, 
__excepthook____excepthook__,
...
>>> a=dir()
>>> a
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> b=a[0]
>>> b
__builtins____builtins__
>>> type(b)
<type 'str'>
>>> print b
__builtins__
>>> repr(b)
'__builtins__'"'__builtins__'"
>>> len(b)
12
>>>

That does not look right to me.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:36

Message:
Logged In: YES 
user_id=6380

I can't reproduce this, and I believe that if it was
reproducible, the test suite would break catastrophically.

Did you hack the string repr code yourself, or do you have a
busted sys.displayhook installed?

Does repr() of all strings behave weirdly?

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

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


From noreply@sourceforge.net  Sat Aug  4 19:42:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 11:42:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-447982 ] inconsistent availablility on modules
Message-ID: <E15T6NP-00038B-00@usw-sf-web1.sourceforge.net>

Bugs item #447982, was opened at 2001-08-04 11:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447982&group_id=5470

Category: Installation
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: inconsistent availablility on modules 

Initial Comment:
My last python 2.0 rpm has syslog module. I have just
downloaded the python-2.0.1.tgz from one of the python
mirror sites. That release has syslog module commented
out in Modules/Setup file.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:42

Message:
Logged In: YES 
user_id=6380

The source distribution has many modules commented out,
because they don't always build on all platforms. The RPM
builder uncomments modules that should go into the RPM. You
can uncomment it and see if it builds.

If you can upgrade to 2.1.1, this problem is gone: as of
2.1, all extensions are built automatically by the setup.py
script, assuming they can be built at all.


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

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


From noreply@sourceforge.net  Sat Aug  4 21:01:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 13:01:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-447945 ] time.time() is not non-decreasing
Message-ID: <E15T7bv-0007uz-00@usw-sf-web2.sourceforge.net>

Bugs item #447945, was opened at 2001-08-04 08:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470

>Category: Documentation
>Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko Ozoko (zooko)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time.time() is not non-decreasing

Initial Comment:
<p>After spending many hours tracking down weird race
conditions in <a href="http://mojonation.net/">Mojo
Nation</a>, I've finally realized that the problem is
that we assumed that <cite>time.time()</cite> would
return non-decreasing answers.  In fact, successive
calls to <cite>time.time()</cite> can return a
<em>smaller</em> number than previous calls, as
demonstrated by this test (Python 2.0 on debian
woody):</p>
<pre>
import time

x = 0
while 1:
    ox = x
    x = time.time()
    if x < ox:
        print "this is WRONG: ox: %s, x: %s\n" % (ox,
x,)
    else:
        print ".",
</pre>
<p>In order to get the race conditions out of Mojo
Nation, I'm writing a
<cite>non_decreasing_time()</cite>, which does what we
thought <cite>time()</cite> would do.  In fact, I might
just make it <cite>increasing_time()</cite>.  In any
case, the <cite>time.time()</cite> in the standard
library should either be fixed (my preference) to be
non-decreasing, or the documentation should be updated
to warn about the surprise.</p>
<p>Regards,</p>
<p><b><i>Zooko</i></b></p>

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 13:01

Message:
Logged In: YES 
user_id=6380

Zooko writes:

"""
It turns out that it *is* because my system clock is getting
reset, to adjust
for clock skew.

I'm testing my new `increasing_time()' function which I can
rely on to always
return higher values.  I'll post about it to python-list.

Sorry for the bug report which was really just a problem
with a frequently
misunderstood semantics.  Perhaps the time.time() docs
should warn you about
the possibility of getting different results.
"""

Assigning to Fred for doco update.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:03

Message:
Logged In: YES 
user_id=6380

I don't understand why this can happen. time.time() is a
simple wrapper around either gettimeofday(), ftime(), or
time(). So you should be able to reproduce this in C as
well, and it should be a kernel bug, unless somehow the
conversion to float is busted. Can you investigate?

Of course, if the super-user resets the system clock,
time.time() may also return non-monononous values -- I
assume that that's not what you're seeing -- but that's a
reason why Python can't guarantee a monotonously increasing
time.

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

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


From noreply@sourceforge.net  Sat Aug  4 23:23:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 15:23:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-445984 ] test___all__ fails when _socket absent
Message-ID: <E15T9pW-0001Ji-00@usw-sf-web3.sourceforge.net>

Bugs item #445984, was opened at 2001-07-30 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445984&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Ward (gward)
Assigned to: Greg Ward (gward)
Summary: test___all__ fails when _socket absent

Initial Comment:
If the _socket extension couldn't be built (see bug
#445980), test___all__ fails somewhat mysteriously:

$ ./python Lib/test/test___all__.py
Traceback (most recent call last):
  File "Lib/test/test___all__.py", line 42, in ?
    check_all("CGIHTTPServer")
  File "Lib/test/test___all__.py", line 10, in check_all
    exec "import %s" % modname in names
  File "<string>", line 1, in ?
  File "/tmp/Python-2.2a1/Lib/CGIHTTPServer.py", line
27, in ?
    import BaseHTTPServer
  File "/tmp/Python-2.2a1/Lib/BaseHTTPServer.py", line
72, in ?
    import SocketServer
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
273, in ?
    class TCPServer(BaseServer):
  File "/tmp/Python-2.2a1/Lib/SocketServer.py", line
316, in TCPServer
    address_family = socket.AF_INET
AttributeError: 'module' object has no attribute 'AF_INET'



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

>Comment By: Greg Ward (gward)
Date: 2001-08-04 15:23

Message:
Logged In: YES 
user_id=14422

OK, bug worked around in rev 1.18 of Lib/test/test___all__.py.




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

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

Message:
Logged In: YES 
user_id=6380

Sounds good to me.

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

Comment By: Greg Ward (gward)
Date: 2001-08-04 10:07

Message:
Logged In: YES 
user_id=14422

Guido's "fix" is close -- you actually have to
"import _socket" (trigger an ImportError) before
check_all("CGIHTTPServer"), because it imports socket.

With that "fix" made, the test result is:

  test test___all__ skipped --  No module named _socket

Should I check this in (one "import _socket" line added to test___all__.py)?  Or is this too arcane, ie. you're toast if _socket doesn't build, so don't bother trying to workaround it?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-30 08:50

Message:
Logged In: YES 
user_id=6380

This can be "fixed" by inserting "import _socket" in front
of the check_all("socket") line.

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

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


From noreply@sourceforge.net  Sat Aug  4 23:59:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 15:59:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15TAOT-0005qu-00@usw-sf-web2.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sun Aug  5 00:05:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 16:05:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-448025 ] Fix for #404535 not in Python 2.0x
Message-ID: <E15TATx-0004m5-00@usw-sf-web1.sourceforge.net>

Bugs item #448025, was opened at 2001-08-04 16:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448025&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for #404535 not in Python 2.0x

Initial Comment:
The fix is not in Python 2.0 or Python 2.0.1. However,
according to the fix date, this fix is quite before the
release of Python 2.0.
I personally think this fix is needed to put in 2.0 or
later because the ConfigParser.remove_option is purely
not working and raise exception.

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

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


From noreply@sourceforge.net  Sun Aug  5 01:02:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 17:02:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15TBN9-0006zE-00@usw-sf-web1.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-04 17:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sun Aug  5 03:42:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 19:42:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15TDsI-0002YU-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 19:42

Message:
Logged In: YES 
user_id=44345

   I don't know anything about the history, present, or 
   prospects for bsddb -- like, is there a more recent 
   unencumbered version we could use?

Ya got me.  I've been using lib db 2 for quite awhile.  They
recently released lib db 3 (again, with file format incom-
patibilities).  I don't know the details of their license.
It just comes with whatever version of Linux I happen to be
running.

Saw this on the Sleepycat website:

   The Berkeley DB 3.0 source code is available for download
   at no charge from Sleepycat Software's Web site, at
   www.sleepycat.com. It runs on all common versions of
   UNIX, and on Windows 95, Windows 98 and Windows NT.
   Berkeley DB is an Open Source product, and may be
   redistributed without charge in many circumstances.
   Licensing and pricing information are available from
   the company. 

My guess would be that you can distribute lib db 3 with 
the binary version of Python.  I am, as they say, "not
a lawyer", so YMMV.  For a definitive answer I think
you'll have to ask Sleepycat.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 17:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sun Aug  5 03:59:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 19:59:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15TE8N-0002jp-00@usw-sf-web3.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-04 19:59

Message:
Logged In: YES 
user_id=12800

if you can live with the licensing for sleepycat's db3, do 
yourself a huge favor and go to pybsddb.sf.net.  robin 
dunn's got a very excellent, stable, new python binding, 
which i would like to integrate into the standard distro 
for the py2.2 release.  it claims to support db1.85, 
although i've only tried it with a very recent v3.9.x.

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

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

Message:
Logged In: YES 
user_id=44345

   I don't know anything about the history, present, or 
   prospects for bsddb -- like, is there a more recent 
   unencumbered version we could use?

Ya got me.  I've been using lib db 2 for quite awhile.  They
recently released lib db 3 (again, with file format incom-
patibilities).  I don't know the details of their license.
It just comes with whatever version of Linux I happen to be
running.

Saw this on the Sleepycat website:

   The Berkeley DB 3.0 source code is available for download
   at no charge from Sleepycat Software's Web site, at
   www.sleepycat.com. It runs on all common versions of
   UNIX, and on Windows 95, Windows 98 and Windows NT.
   Berkeley DB is an Open Source product, and may be
   redistributed without charge in many circumstances.
   Licensing and pricing information are available from
   the company. 

My guess would be that you can distribute lib db 3 with 
the binary version of Python.  I am, as they say, "not
a lawyer", so YMMV.  For a definitive answer I think
you'll have to ask Sleepycat.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 17:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sun Aug  5 04:35:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 04 Aug 2001 20:35:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-445862 ] bsddb fails for larger amount of data
Message-ID: <E15TEgv-0006ym-00@usw-sf-web2.sourceforge.net>

Bugs item #445862, was opened at 2001-07-30 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445862&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: bsddb fails for larger amount of data

Initial Comment:
The attached script fails after approx. 72500 insert 
operations. If you vary the size of the keys and/or 
the values, the bug occurs earlier or later, but even 
with a value size of 1 the bug will occur. Probably, 
this explains also bug #408271 ("crash in shelve 
module").

Platform: W2K



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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-04 20:35

Message:
Logged In: YES 
user_id=31435

Barry apparently forgot to assign this to himself; repaired 
his bug <wink>.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-04 19:59

Message:
Logged In: YES 
user_id=12800

if you can live with the licensing for sleepycat's db3, do 
yourself a huge favor and go to pybsddb.sf.net.  robin 
dunn's got a very excellent, stable, new python binding, 
which i would like to integrate into the standard distro 
for the py2.2 release.  it claims to support db1.85, 
although i've only tried it with a very recent v3.9.x.

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

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

Message:
Logged In: YES 
user_id=44345

   I don't know anything about the history, present, or 
   prospects for bsddb -- like, is there a more recent 
   unencumbered version we could use?

Ya got me.  I've been using lib db 2 for quite awhile.  They
recently released lib db 3 (again, with file format incom-
patibilities).  I don't know the details of their license.
It just comes with whatever version of Linux I happen to be
running.

Saw this on the Sleepycat website:

   The Berkeley DB 3.0 source code is available for download
   at no charge from Sleepycat Software's Web site, at
   www.sleepycat.com. It runs on all common versions of
   UNIX, and on Windows 95, Windows 98 and Windows NT.
   Berkeley DB is an Open Source product, and may be
   redistributed without charge in many circumstances.
   Licensing and pricing information are available from
   the company. 

My guess would be that you can distribute lib db 3 with 
the binary version of Python.  I am, as they say, "not
a lawyer", so YMMV.  For a definitive answer I think
you'll have to ask Sleepycat.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-04 17:02

Message:
Logged In: YES 
user_id=31435

Skip, I reran the test after changing the open line to

db = bsddb.btopen("test.dbm", "n")

I killed it by hand at this point:

Last i: 326577, last key:abcdef4387101.63608

because Win98SE gets mondo unstable when it starts 
thrashing madly to disk, and it became impossible to get 
any work done while this was running.

I don't know anything about the history, present, or 
prospects for bsddb -- like, is there a more recent 
unencumbered version we could use?  It looks like Sam's 
1.85 Windows port is over 5 years old.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-04 15:59

Message:
Logged In: NO 

According to www.sleepycat.com/historic.html, 
talking about bsd db:
"we recommend that you avoid the following operations when 
using versions 1.85 and 1.86: 

o Btree cursor (seq and put using a cursor) operations. 
o Large numbers of btree duplicates (specifically, avoid 
migrating duplicate keys to internal pages). 
o Large numbers of btree deletes (you should periodically 
dump and rebuild the database if you delete large numbers 
of records). 
o Overwriting or deleting overflow hash key/data pairs 
(pairs with items larger than the page size). 
o Intermixing hash cursor operations with deletes. "


My problem arises, I think, because I have been doing the 
fourth of these operations - i.e. overwriting long items in 
a hash. The problems others are experiencing perhaps have a 
similar cause, though the original problem summary 
says "even with a value size of 1 the bug will occur", so 
perhaps not.

I'm now using a workaround which involves writing several 
shorter items, each containing a slice of the data formerly 
held in the one long item. For keys I use my old key with a 
subscript number appended. It isn't nice, but it seems to 
be working.

Martin Gradwell.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-04 08:12

Message:
Logged In: YES 
user_id=44345

Based upon the traceback Tim reported, my guess is that 
the exception is being raised near the end of bsddb_ass_sub.
Tim, can you give it a try changing anydbm.open to
bsddb.btopen?  As I recall, the significant bug(s) in libdb
were in the hash file implementation.  It's unfortunate
that anydbm has used the hash file all these years, but
it's a bit late to spring that change on unsuspecting
users now without going through a significant transition
period.

Skip


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-03 14:40

Message:
Logged In: YES 
user_id=31435

Thanks for taking a look, Skip!  On Win98SE it dies for me 
like so:

...
70000
71000
72000
Last i: 72758, last key:abcdef1691515.8934
Traceback (most recent call last):
  File "ka.py", line 15, in ?
    db[key] = val
bsddb.error: (0, 'Error')

test.dbm is 37,778,944 bytes at the end.  I assume 
Anonymous has the same problem (if not, he/she should say 
so).

On Windows we use the ancient db.1.85.win32.zip, from 
the "bsd db" (not "bsddb"!) link at

http://www.nightmare.com/software.html

I doubt Sam has done any maintenance on that in years; and 
afraid I don't know anything else about this.

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

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-03 13:25

Message:
Logged In: YES 
user_id=44345

What version of libdb are you using?  I'm running your
script on Linux at the moment.  I had to change it slightly
because the only machine I have available with the spare 
cojones to run that script is running 1.5.2 (so I call
random.uniform instead of using a Random instance).  On that
machine I'm sort of ashamed to say I'm still running the
known buggy libdb 1.85.  So far I'm up to 680,000 keys with
a db file of over 166MB with no problem.  On my laptop
running 2.1 and libdb3 (and a much more modestly performing
disk drive) I gave up after about 287,000 keys.
I then changed the db open call to bsddb.btopen and watched
it march (slowly) up to 183,000 keys and a 32MB file on
disk before I killed it.  Aside from the grief it gives my
disk drives, I don't see anything particularly bad
happening.

You didn't include a traceback with your bug report.  What
was printed?  Perhaps it's something simple like running
out of disk space.  In any case, I think trying to create a
libdb database of 1,000,000 sort of random keys is going to
strain that package and most disk drives in any case, bugs
or no bugs.

My guess is that if there's a bug it's in libdb, not the
bsddb module.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-03 00:50

Message:
Logged In: NO 

Here it is:

import anydbm
import bsddb
import random

MAX = 1000000
r = random.Random(42)
r.seed(1017)
db = anydbm.open("test.dbm", "n")
#db = bsddb.hashopen("test.dbm", "n")
try:
    for i in xrange(0, MAX):
        if i % 1000 == 0: print i
        key = "abcdef" + str(r.uniform(0, 10 * MAX))
        val = "a" * 80 + str(i)
        db[key] = val
finally:
    db.close()
    print "Last i: %s, last key:%s" % (i,key) 

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-02 12:41

Message:
Logged In: YES 
user_id=31435

Alas, there's no script attached -- please attach one, so 
we have something concrete to investigate.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-02 03:08

Message:
Logged In: NO 

I was getting crashes in shelve module, Using NT4 (Python 
2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on 
win32). I've changed my program to re-read previously 
written keys fairly frequently, and I get keyerrors for 
keys that have definitely been written, and that gave no 
error a little earlier in the same program. The program 
doesn't contain any delete statements.

The same program works when using dumbdbm instead of bsddb 
(but produces huge indexes), so there definitely appears to 
be a problem with bsddbm on windows NT.




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

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


From noreply@sourceforge.net  Sun Aug  5 08:14:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 00:14:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-448100 ] imaplib.py test code does not work with
Message-ID: <E15TI6t-0003or-00@usw-sf-web3.sourceforge.net>

Bugs item #448100, was opened at 2001-08-05 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448100&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 1
Submitted By: Piers Lauder (pierslauder)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib.py test code does not work with 

Initial Comment:
The test code at the end of the imaplib module 
contains a test message that uses NL as line 
terminators, instead of the IMAP4-mandated CRNL
standard. As a result, the test code will not work 
with input sensitive IMAP4 servers, such as `NTmail'.

This bug was reported by: Hung Jung Lu 
<hungjunglu@yahoo.com>


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

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


From noreply@sourceforge.net  Sun Aug  5 08:14:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 00:14:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-447918 ] strange results from dir()
Message-ID: <E15TI7a-0006ho-00@usw-sf-web2.sourceforge.net>

Bugs item #447918, was opened at 2001-08-04 04:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447918&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Uwe Zessin (zessin_5)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange results from dir()

Initial Comment:
The code is from the CVS, friday.

Output from V2.1.1:
>>> dir()
['__builtins__', '__doc__', '__name__', 'sys']
>>> dir(sys)
['__displayhook__', '__doc__', '__excepthook__', 
'__name__', '__stderr__',
...
That looks OK to me.

Output from V2.2-cvs from friday:
>>> dir()
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> dir(sys)
[__displayhook____displayhook__, __doc____doc__, 
__excepthook____excepthook__,
...
>>> a=dir()
>>> a
[__builtins____builtins__, __doc____doc__, 
__name____name__, syssys]
>>> b=a[0]
>>> b
__builtins____builtins__
>>> type(b)
<type 'str'>
>>> print b
__builtins__
>>> repr(b)
'__builtins__'"'__builtins__'"
>>> len(b)
12
>>>

That does not look right to me.

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

>Comment By: Uwe Zessin (zessin_5)
Date: 2001-08-05 00:14

Message:
Logged In: YES 
user_id=155755

Guido,

I have received a small 'performance' optimization
for string_print() from someone else some time ago.
It looks like this:
  if (flags & Py_PRINT_RAW) {
    if (op->ob_size) fwrite(op->ob_sval, (int) op->ob_size, 
1, fp);
    return 0;


Until now everything was fine. However, I have changed
to a different version of DIFF/PATCH on my system and
it looks like that combination does not work reliable.

Thanks for you suggestions what to check! I was rather
stunned that such a 'simple' thing suddenly failed.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:36

Message:
Logged In: YES 
user_id=6380

I can't reproduce this, and I believe that if it was
reproducible, the test suite would break catastrophically.

Did you hack the string repr code yourself, or do you have a
busted sys.displayhook installed?

Does repr() of all strings behave weirdly?

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

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


From noreply@sourceforge.net  Sun Aug  5 11:53:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 03:53:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-448100 ] imaplib.py test code does not work with
Message-ID: <E15TLXT-00033j-00@usw-sf-web3.sourceforge.net>

Bugs item #448100, was opened at 2001-08-05 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448100&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Piers Lauder (pierslauder)
Assigned to: Piers Lauder (pierslauder)
Summary: imaplib.py test code does not work with 

Initial Comment:
The test code at the end of the imaplib module 
contains a test message that uses NL as line 
terminators, instead of the IMAP4-mandated CRNL
standard. As a result, the test code will not work 
with input sensitive IMAP4 servers, such as `NTmail'.

This bug was reported by: Hung Jung Lu 
<hungjunglu@yahoo.com>


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

>Comment By: Piers Lauder (pierslauder)
Date: 2001-08-05 03:53

Message:
Logged In: YES 
user_id=196212

The test code has been modified to use CRLF.



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

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


From noreply@sourceforge.net  Sun Aug  5 13:43:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 05:43:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-448144 ] incompatible change of string type name
Message-ID: <E15TNFW-0001MF-00@usw-sf-web2.sourceforge.net>

Bugs item #448144, was opened at 2001-08-05 05:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448144&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: incompatible change of string type name

Initial Comment:
In Python 2.1 and earlier, type("").__name__ was 
"string". In 2.2a1, it is "str". This change breaks 
the xml.marshal package of PyXML, which uses the type 
name to generate a method m_string. Since there is no 
m_str method implemented, running the marshaller 
under 2.2 fails.


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

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


From noreply@sourceforge.net  Sun Aug  5 14:27:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 06:27:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-448153 ] Dictionary iterators break old code
Message-ID: <E15TNvz-0002e1-00@usw-sf-web2.sourceforge.net>

Bugs item #448153, was opened at 2001-08-05 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448153&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Dictionary iterators break old code

Initial Comment:
With the introduction of dictionary iterators, 
iteration over UserDict specializations may silently 
break existing code. The attached code is a 
simplification of the xml.dom.NamedNodeMap class, 
which provides iteration over the values using a 
well-defined order, which is implemented in 
__getitem__. In Python 2.2a1, __getitem__ is not 
called anymore, thus the code breaks.


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

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


From noreply@sourceforge.net  Sun Aug  5 16:44:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 08:44:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-447945 ] time.time() is not non-decreasing
Message-ID: <E15TQ4Y-0006dS-00@usw-sf-web3.sourceforge.net>

Bugs item #447945, was opened at 2001-08-04 08:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447945&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Zooko Ozoko (zooko)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: time.time() is not non-decreasing

Initial Comment:
<p>After spending many hours tracking down weird race
conditions in <a href="http://mojonation.net/">Mojo
Nation</a>, I've finally realized that the problem is
that we assumed that <cite>time.time()</cite> would
return non-decreasing answers.  In fact, successive
calls to <cite>time.time()</cite> can return a
<em>smaller</em> number than previous calls, as
demonstrated by this test (Python 2.0 on debian
woody):</p>
<pre>
import time

x = 0
while 1:
    ox = x
    x = time.time()
    if x < ox:
        print "this is WRONG: ox: %s, x: %s\n" % (ox,
x,)
    else:
        print ".",
</pre>
<p>In order to get the race conditions out of Mojo
Nation, I'm writing a
<cite>non_decreasing_time()</cite>, which does what we
thought <cite>time()</cite> would do.  In fact, I might
just make it <cite>increasing_time()</cite>.  In any
case, the <cite>time.time()</cite> in the standard
library should either be fixed (my preference) to be
non-decreasing, or the documentation should be updated
to warn about the surprise.</p>
<p>Regards,</p>
<p><b><i>Zooko</i></b></p>

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-05 08:44

Message:
Logged In: YES 
user_id=3066

Added a note about time() being non-decreasing except when the system clock is set back; see Doc/lib/libtime.tex revision 1.43.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 13:01

Message:
Logged In: YES 
user_id=6380

Zooko writes:

"""
It turns out that it *is* because my system clock is getting
reset, to adjust
for clock skew.

I'm testing my new `increasing_time()' function which I can
rely on to always
return higher values.  I'll post about it to python-list.

Sorry for the bug report which was really just a problem
with a frequently
misunderstood semantics.  Perhaps the time.time() docs
should warn you about
the possibility of getting different results.
"""

Assigning to Fred for doco update.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-04 11:03

Message:
Logged In: YES 
user_id=6380

I don't understand why this can happen. time.time() is a
simple wrapper around either gettimeofday(), ftime(), or
time(). So you should be able to reproduce this in C as
well, and it should be a kernel bug, unless somehow the
conversion to float is busted. Can you investigate?

Of course, if the super-user resets the system clock,
time.time() may also return non-monononous values -- I
assume that that's not what you're seeing -- but that's a
reason why Python can't guarantee a monotonously increasing
time.

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

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


From noreply@sourceforge.net  Sun Aug  5 18:32:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 10:32:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E15TRl5-0005v9-00@usw-sf-web1.sourceforge.net>

Bugs item #414316, was opened at 2001-04-06 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414316&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

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

>Comment By: Paul F. Dubois (dubois)
Date: 2001-08-05 10:32

Message:
Logged In: YES 
user_id=5550

Attached is a file with the details on the report.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 20:54

Message:
Logged In: YES 
user_id=3066

Assigned to me, since Paul has asked me about this and I
don't want to keep that mail in my inbox forever.

Paul, please tell me exactly what you're seeing:  what
permissions are set on the file in the source directory,
what's the umask you're using, and what are the final
permissions of the installed file.  The only thing that the
install_scripts command appears to be doing is ensuring that
the executable bit is set.

Is the "group-sticky" bit set in the destination directory?
 How do the identities of the installer relate to the
owner/group of the destination directory?

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-07 13:04

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward.

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

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


From noreply@sourceforge.net  Sun Aug  5 18:58:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 10:58:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E15TSAO-0004xV-00@usw-sf-web2.sourceforge.net>

Bugs item #414316, was opened at 2001-04-06 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414316&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-05 10:58

Message:
Logged In: YES 
user_id=3066

Paul,

I think I see what's happening.  In distutils/command/build_scripts.py, at the end of the copy_scripts() method, there is a call to self.copy_file().  You should be able to add a keyword parameter preserve_mode=0 to that to fix this.  If that is not sufficient, please let me know.  (The existing build and installation of your package will need to have the write bit enabled before this will work, unfortunately, but this should take care of future installations.)

Please report your results, and I'll get this checked in if it is sufficient.  Thanks!

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

Comment By: Paul F. Dubois (dubois)
Date: 2001-08-05 10:32

Message:
Logged In: YES 
user_id=5550

Attached is a file with the details on the report.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 20:54

Message:
Logged In: YES 
user_id=3066

Assigned to me, since Paul has asked me about this and I
don't want to keep that mail in my inbox forever.

Paul, please tell me exactly what you're seeing:  what
permissions are set on the file in the source directory,
what's the umask you're using, and what are the final
permissions of the installed file.  The only thing that the
install_scripts command appears to be doing is ensuring that
the executable bit is set.

Is the "group-sticky" bit set in the destination directory?
 How do the identities of the installer relate to the
owner/group of the destination directory?

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

Comment By: Tim Peters (tim_one)
Date: 2001-04-07 13:04

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward.

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

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


From noreply@sourceforge.net  Sun Aug  5 19:55:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 05 Aug 2001 11:55:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-448025 ] Fix for #404535 not in Python 2.0x
Message-ID: <E15TT3r-0000Wm-00@usw-sf-web1.sourceforge.net>

Bugs item #448025, was opened at 2001-08-04 16:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448025&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for #404535 not in Python 2.0x

Initial Comment:
The fix is not in Python 2.0 or Python 2.0.1. However,
according to the fix date, this fix is quite before the
release of Python 2.0.
I personally think this fix is needed to put in 2.0 or
later because the ConfigParser.remove_option is purely
not working and raise exception.

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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-05 11:55

Message:
Logged In: YES 
user_id=21627

#404535 was closed not because it was fixed, but because 
it is a duplicate of #404536.

The bug reported for remove_option was fixed in revision 
1.24 of ConfigParser.py, which was a response to bug 
report #124324.

Both Python 2.0 and 2.0.1 have shipped with version 1.23 
of ConfigParser.py. Since they are already released, the 
contents of these releases cannot be changed anymore.

Both Python 2.1 and 2.1.1 do include the fix, as they 
include revisions 1.32 and 1.32.4.1 of that file, 
respectively, so the bug is fixed in "2.0 or later". I 
believe it is highly unlikely that a release 2.0.2 of 
Python will be made.

If you are not satisfied with this response, please 
explain in more detail what it is that you are requesting. 
Otherwise, I suggest to close this report as "Works for 
me".


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

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


From noreply@sourceforge.net  Mon Aug  6 09:23:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 01:23:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15TffV-0006ac-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

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


From noreply@sourceforge.net  Mon Aug  6 09:27:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 01:27:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-448352 ] returning stack frames scrambles globals
Message-ID: <E15TfjQ-0000xT-00@usw-sf-web3.sourceforge.net>

Bugs item #448352, was opened at 2001-08-06 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448352&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Just (andijust)
Assigned to: Nobody/Anonymous (nobody)
Summary: returning stack frames scrambles globals

Initial Comment:
When function return references to stack frame objects, various data in global or local namespaces 
are scrambled.

I'm adding an example, where returning a stack frame prevents a classes "__del__" method from 
being called. In addition, when assigning the returned stack frame lists to a global variable, I've got 
the list of imported modules destroyed.

I'm aware, that this might not be a real bug - maybe it's a case of "this has to be this way", as 
those objects are changed same time when they are used as return values. If it is, just drop this 
bug.

Andreas

-------------------------------------------------
Program example:
(This short script will prevent the "__del__" method from being called, when stack() returns 
references to the original frame objects and will work fine, when returning just some copies.)

#!/usr/bin/env python
import sys
import os

class FrameObjectCopy :
        """empty class for use in member function Logging.stack()"""

def stack(create_error) :
        frame = sys._getframe().f_back

        if create_error :
                # returning the frame runs into error
                return frame
        else :
                #
                # returning a copy will work fine
                frame_copy = FrameObjectCopy()
                for attrname in dir(frame) :
                        setattr(frame_copy,attrname,getattr(frame,attrname))
                return frame_copy




class test :
        def __init__(self,create_error) :
                print "***** init() *****"
                s = stack(create_error)
        def __del__(self) :
                print "***** del() *****"


print
print "Running correctly - __init__() and __del__() methods are called"
a=test(0)
del a

print
print "Running into error - only __init__() is called"
a=test(1)
del a


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

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


From noreply@sourceforge.net  Mon Aug  6 09:31:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 01:31:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15TfnM-00075m-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 01:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Mon Aug  6 11:52:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 03:52:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15Ti0E-000464-00@usw-sf-web1.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Mon Aug  6 13:36:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 05:36:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15Tjcm-0008Nd-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 01:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Mon Aug  6 13:41:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 05:41:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-448352 ] returning stack frames scrambles globals
Message-ID: <E15TjhT-0002YV-00@usw-sf-web3.sourceforge.net>

Bugs item #448352, was opened at 2001-08-06 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448352&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Just (andijust)
Assigned to: Nobody/Anonymous (nobody)
Summary: returning stack frames scrambles globals

Initial Comment:
When function return references to stack frame objects, various data in global or local namespaces 
are scrambled.

I'm adding an example, where returning a stack frame prevents a classes "__del__" method from 
being called. In addition, when assigning the returned stack frame lists to a global variable, I've got 
the list of imported modules destroyed.

I'm aware, that this might not be a real bug - maybe it's a case of "this has to be this way", as 
those objects are changed same time when they are used as return values. If it is, just drop this 
bug.

Andreas

-------------------------------------------------
Program example:
(This short script will prevent the "__del__" method from being called, when stack() returns 
references to the original frame objects and will work fine, when returning just some copies.)

#!/usr/bin/env python
import sys
import os

class FrameObjectCopy :
        """empty class for use in member function Logging.stack()"""

def stack(create_error) :
        frame = sys._getframe().f_back

        if create_error :
                # returning the frame runs into error
                return frame
        else :
                #
                # returning a copy will work fine
                frame_copy = FrameObjectCopy()
                for attrname in dir(frame) :
                        setattr(frame_copy,attrname,getattr(frame,attrname))
                return frame_copy




class test :
        def __init__(self,create_error) :
                print "***** init() *****"
                s = stack(create_error)
        def __del__(self) :
                print "***** del() *****"


print
print "Running correctly - __init__() and __del__() methods are called"
a=test(0)
del a

print
print "Running into error - only __init__() is called"
a=test(1)
del a


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:41

Message:
Logged In: YES 
user_id=6380

The first problem you mention is indeed "that's how it
works". The frame keeps references to the local variables;
if you make the frame a local variable of itself, you create
a circular reference. I don't believe frames are currently
garbage-collected; they will be in 2.2 I believe.

I don't understand the second problem you are describing;
you have probably managed to confused yourself, but if not,
please post a code fragment that reproduces the problem here
(and describe it better -- I'm not quite sure what you are
observing).

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

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


From noreply@sourceforge.net  Mon Aug  6 13:51:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 05:51:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15TjrC-0000Y4-00@usw-sf-web1.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



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

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

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

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


From noreply@sourceforge.net  Mon Aug  6 14:08:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 06:08:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-448403 ] libpython2.2.a missing -- Make Failure
Message-ID: <E15Tk7e-0001a2-00@usw-sf-web1.sourceforge.net>

Bugs item #448403, was opened at 2001-08-06 06:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448403&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: libpython2.2.a missing -- Make Failure

Initial Comment:
Hi,

In trying to install Python for the first time on a Sun
Ultrasparc 10, I followed recommended procedure and
obtained the following error (whilst runing "make"):

gcc   -o python \
                Modules/python.o \
                libpython2.2.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
gcc: libpython2.2.a: No such file or directory
make: *** [python] Error 1

Any assistance would be greatly appreciated.

All the best,

Lars


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

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


From noreply@sourceforge.net  Mon Aug  6 17:50:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 09:50:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-444229 ] 5 .__new__(list, '42') == 42
Message-ID: <E15Tnac-00050l-00@usw-sf-web2.sourceforge.net>

Bugs item #444229, was opened at 2001-07-24 12:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444229&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 5 .__new__(list, '42') == 42

Initial Comment:
This expression should raise an exception, since list
is not a subclass of int.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 09:50

Message:
Logged In: YES 
user_id=6380

Fixed in typeobject.c:2.20.

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

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


From noreply@sourceforge.net  Mon Aug  6 17:51:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 09:51:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-444229 ] 5 .__new__(list, '42') == 42
Message-ID: <E15Tnau-00051K-00@usw-sf-web2.sourceforge.net>

Bugs item #444229, was opened at 2001-07-24 12:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444229&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 5 .__new__(list, '42') == 42

Initial Comment:
This expression should raise an exception, since list
is not a subclass of int.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 09:50

Message:
Logged In: YES 
user_id=6380

Fixed in typeobject.c:2.20.

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

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


From noreply@sourceforge.net  Mon Aug  6 19:35:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 11:35:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-448481 ] Missing .h files and compiler warnings
Message-ID: <E15TpEF-0007qj-00@usw-sf-web3.sourceforge.net>

Bugs item #448481, was opened at 2001-08-06 11:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: Missing .h files and compiler warnings

Initial Comment:
Attempted to build 2.2a1 on Mac OS X 10.0.4. Got a 
LOT of compiler warnings (mostly "function 
declaration not a prototype"), but make specifically 
stopped when trying the following:
Python/dynload_next.c:30: header file 'mach-o/
rld.h' not found
Python/dynload_next.c:51: undefined type, found 
`NXStream'
cpp-precomp: warning: errors during smart 
preprocessing, retrying in basic mode
make: *** [Python/dynload_next.o] Error 1

I can redirect all warnings and errors to a .txt file 
and e-mail it to anyone who might want to have a 
look.

-John Buell

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

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


From noreply@sourceforge.net  Mon Aug  6 19:36:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 11:36:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-448482 ] python 2.1.1: sgmllib, decl. subset
Message-ID: <E15TpEW-0006Ic-00@usw-sf-web1.sourceforge.net>

Bugs item #448482, was opened at 2001-08-06 11:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448482&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: python 2.1.1: sgmllib, decl. subset

Initial Comment:
sgmllib.SGMLParser is unable to parse a document type 
declaration subset and reports a false error. The 
attached patch fixes this.


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

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


From noreply@sourceforge.net  Mon Aug  6 19:47:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 11:47:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-448144 ] incompatible change of string type name
Message-ID: <E15TpPQ-0008NZ-00@usw-sf-web3.sourceforge.net>

Bugs item #448144, was opened at 2001-08-05 05:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448144&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: incompatible change of string type name

Initial Comment:
In Python 2.1 and earlier, type("").__name__ was 
"string". In 2.2a1, it is "str". This change breaks 
the xml.marshal package of PyXML, which uses the type 
name to generate a method m_string. Since there is no 
m_str method implemented, running the marshaller 
under 2.2 fails.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 11:47

Message:
Logged In: YES 
user_id=6380

Hm. If I change the type's name back to 'string', the
built-in name for it has to be 'string' (otherwise some part
of marshal or pickle won't work). But I had hoped to use the
'string' built-in name for the base class of str and
unicode.

Is it terribly inconvenient to have to rename the m_string
function to m_str?


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

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


From noreply@sourceforge.net  Mon Aug  6 20:47:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 12:47:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-445474 ] warn about import * inside functions
Message-ID: <E15TqLE-0002AR-00@usw-sf-web3.sourceforge.net>

Bugs item #445474, was opened at 2001-07-28 06:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=445474&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Jeremy Hylton (jhylton)
Summary: warn about import * inside functions

Initial Comment:
According to the reference manual, import * is now only
allowed at the module level. This is not enforced. We
should add a warning for this.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 12:47

Message:
Logged In: YES 
user_id=31392

Fixed in rev. 2.209 of compile.c; based on earlier, reverted
fix in rev 2.155.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:56

Message:
Logged In: YES 
user_id=6380

Yes, let's get this over with.

If I really hate it I'll rip it out myself, but more likely
I'll fix my code. :-)

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 13:53

Message:
Logged In: YES 
user_id=31392

Do you really want to get a warning about this?  Last time
it came up, we discovered that you were the most common user
of this feature in Python.  Fredrik also said he used it a
lot, not surprising since the most common idiom is:

def test():
    from Tkinter import *



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

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


From noreply@sourceforge.net  Mon Aug  6 20:48:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 12:48:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-210683 ] can't compile with SSL support on WinNT (PR#403)
Message-ID: <E15TqMg-0003Jg-00@usw-sf-web2.sourceforge.net>

Bugs item #210683, was opened at 2000-07-31 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210683&group_id=5470

Category: Windows
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: can't compile with SSL support on WinNT (PR#403)

Initial Comment:
Jitterbug-Id: 403
Submitted-By: falk.lehmann@gmx.net
Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT)
Version: 1.6a2
OS: WinNT 4.0


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



====================================================================
Audit trail:
Tue Jul 25 07:25:55 2000	guido	changed notes
Tue Jul 25 07:25:55 2000	guido	moved from incoming to open

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 12:48

Message:
Logged In: NO 

Now that Python 2.1 is out, it sure would be nice
to run Python URL-grabbers on Win systems! The list
o' messages for this item suggests that you'be
been waiting since September 2000 for a volunteer
to fix PR #403, and if I could I would but I can't.

Do the Lords of SourceForge have a guess at the odds
that this will make it into a version of the Win
distribution for Python anytime "soon" (eg, by, say,
Halloween 2001)?

Thanks!

    Peter

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

Comment By: Tim Peters (tim_one)
Date: 2000-09-15 19:07

Message:
Moved to PEP42, awaiting a volunteer can do this.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-07 15:08

Message:
As we've discussed, this is not an issue for 2.0.  Assigned to Tim for resurrection when appropriate since this is Windows-specific. 

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-08-30 12:01

Message:
Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-08-23 10:35

Message:
This is a bug.  Standard extensions modules should compile, even on obscure platforms like Windows NT.  Need a Windows user with time to install OpenSSL to fix this.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
Windows compile fails when using openSSL.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 14:00:20 -0500

> 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/)



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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
From: Falk Lehmann <Falk.Lehmann@gmx.net>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 13:46:45 -0500

[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/)
> 



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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:01

Message:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 11:35:24 -0500

> 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/)



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

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


From noreply@sourceforge.net  Mon Aug  6 21:35:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:35:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-418898 ] __debug__ assignment via setattr
Message-ID: <E15Tr6Q-0003rH-00@usw-sf-web3.sourceforge.net>

Bugs item #418898, was opened at 2001-04-25 11:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418898&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: __debug__ assignment via setattr

Initial Comment:
assignment to __debug__ via setattr does not raise a
warning:

Python 2.1 (#1, Apr 17 2001, 17:26:34)
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2
Type "copyright", "credits" or "license" for more
information
>>> import __builtin__
>>> __debug__
1
>>> setattr(__builtin__, '__debug__', 0)
>>> __debug__
0
>>> __debug__ = 1
<stdin>:0: SyntaxWarning: can not assign to __debug__
>>> 

As long as this behavior is going in, it ought to go in
wholesale.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:35

Message:
Logged In: YES 
user_id=31392

It's too much trouble to try to prevent this obscure case.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:36:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:36:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-413320 ] sys.argv should always be a sequence
Message-ID: <E15Tr6k-0003re-00@usw-sf-web3.sourceforge.net>

Bugs item #413320, was opened at 2001-04-02 21:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413320&group_id=5470

Category: None
>Group: Irreproducible
>Status: Closed
Resolution: Works For Me
Priority: 2
Submitted By: Stephen McInerney (smcinerney)
Assigned to: Jeremy Hylton (jhylton)
Summary: sys.argv should always be a sequence

Initial Comment:
Hi,

It seems that sys.argv is not a sequence if there are
no args passed. Hence references to len() or
non-existent element sys.argv[1] cause a TypeError
which we have to kludge around with a try...except
TypeError. sys.argv should always be a sequence.

Python 1.6 (#4, Sep 13 2000, 17:24:07)  [GCC
egcs-2.91.66 19990314 (egcs-1.1.2 release)] on sunos5
(Solaris 8)

Best regards,
Stephen

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-04 11:04

Message:
Logged In: YES 
user_id=31392

Can you provide an example of how you invoke Python with no
args and what value sys.argv[] has?  I can't reproduce.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:43:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:43:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-448482 ] python 2.1.1: sgmllib, decl. subset
Message-ID: <E15TrDq-0005X8-00@usw-sf-web2.sourceforge.net>

Bugs item #448482, was opened at 2001-08-06 11:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448482&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: python 2.1.1: sgmllib, decl. subset

Initial Comment:
sgmllib.SGMLParser is unable to parse a document type 
declaration subset and reports a false error. The 
attached patch fixes this.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:44:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:44:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-448352 ] returning stack frames scrambles globals
Message-ID: <E15TrF1-00030S-00@usw-sf-web1.sourceforge.net>

Bugs item #448352, was opened at 2001-08-06 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448352&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Just (andijust)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: returning stack frames scrambles globals

Initial Comment:
When function return references to stack frame objects, various data in global or local namespaces 
are scrambled.

I'm adding an example, where returning a stack frame prevents a classes "__del__" method from 
being called. In addition, when assigning the returned stack frame lists to a global variable, I've got 
the list of imported modules destroyed.

I'm aware, that this might not be a real bug - maybe it's a case of "this has to be this way", as 
those objects are changed same time when they are used as return values. If it is, just drop this 
bug.

Andreas

-------------------------------------------------
Program example:
(This short script will prevent the "__del__" method from being called, when stack() returns 
references to the original frame objects and will work fine, when returning just some copies.)

#!/usr/bin/env python
import sys
import os

class FrameObjectCopy :
        """empty class for use in member function Logging.stack()"""

def stack(create_error) :
        frame = sys._getframe().f_back

        if create_error :
                # returning the frame runs into error
                return frame
        else :
                #
                # returning a copy will work fine
                frame_copy = FrameObjectCopy()
                for attrname in dir(frame) :
                        setattr(frame_copy,attrname,getattr(frame,attrname))
                return frame_copy




class test :
        def __init__(self,create_error) :
                print "***** init() *****"
                s = stack(create_error)
        def __del__(self) :
                print "***** del() *****"


print
print "Running correctly - __init__() and __del__() methods are called"
a=test(0)
del a

print
print "Running into error - only __init__() is called"
a=test(1)
del a


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:41

Message:
Logged In: YES 
user_id=6380

The first problem you mention is indeed "that's how it
works". The frame keeps references to the local variables;
if you make the frame a local variable of itself, you create
a circular reference. I don't believe frames are currently
garbage-collected; they will be in 2.2 I believe.

I don't understand the second problem you are describing;
you have probably managed to confused yourself, but if not,
please post a code fragment that reproduces the problem here
(and describe it better -- I'm not quite sure what you are
observing).

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

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


From noreply@sourceforge.net  Mon Aug  6 21:46:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:46:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-448153 ] Dictionary iterators break old code
Message-ID: <E15TrGe-000330-00@usw-sf-web1.sourceforge.net>

Bugs item #448153, was opened at 2001-08-05 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448153&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Martin v. Lіwis (loewis)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Dictionary iterators break old code

Initial Comment:
With the introduction of dictionary iterators, 
iteration over UserDict specializations may silently 
break existing code. The attached code is a 
simplification of the xml.dom.NamedNodeMap class, 
which provides iteration over the values using a 
well-defined order, which is implemented in 
__getitem__. In Python 2.2a1, __getitem__ is not 
called anymore, thus the code breaks.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:47:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:47:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-448025 ] Fix for #404535 not in Python 2.0x
Message-ID: <E15TrHp-00033j-00@usw-sf-web1.sourceforge.net>

Bugs item #448025, was opened at 2001-08-04 16:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448025&group_id=5470

>Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fix for #404535 not in Python 2.0x

Initial Comment:
The fix is not in Python 2.0 or Python 2.0.1. However,
according to the fix date, this fix is quite before the
release of Python 2.0.
I personally think this fix is needed to put in 2.0 or
later because the ConfigParser.remove_option is purely
not working and raise exception.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:47

Message:
Logged In: YES 
user_id=31392

I'm closing this bug report because it was fixed in 2.1.


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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-05 11:55

Message:
Logged In: YES 
user_id=21627

#404535 was closed not because it was fixed, but because 
it is a duplicate of #404536.

The bug reported for remove_option was fixed in revision 
1.24 of ConfigParser.py, which was a response to bug 
report #124324.

Both Python 2.0 and 2.0.1 have shipped with version 1.23 
of ConfigParser.py. Since they are already released, the 
contents of these releases cannot be changed anymore.

Both Python 2.1 and 2.1.1 do include the fix, as they 
include revisions 1.32 and 1.32.4.1 of that file, 
respectively, so the bug is fixed in "2.0 or later". I 
believe it is highly unlikely that a release 2.0.2 of 
Python will be made.

If you are not satisfied with this response, please 
explain in more detail what it is that you are requesting. 
Otherwise, I suggest to close this report as "Works for 
me".


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

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


From noreply@sourceforge.net  Mon Aug  6 21:47:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:47:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-444512 ] pydoc: Mozilla does not use localhost
Message-ID: <E15TrI4-00033q-00@usw-sf-web1.sourceforge.net>

Bugs item #444512, was opened at 2001-07-25 09:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444512&group_id=5470

Category: demos and tools
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Ka-Ping Yee (ping)
Summary: pydoc: Mozilla does not use localhost

Initial Comment:
pydoc gives the browser the argument
"http://localhost:7464/". However, Mozilla does not
support localhost browsing yet (bug 86449 in Bugzilla),
so this does not work. Here is how to fix it:

replace line 1591 in pydoc.py

    host = (sys.platform == 'mac') and '127.0.0.1' or
'localhost'
by

    if (sys.platform == 'mac'):
        host = '127.0.0.1'
    else:
        if (sys.platform == 'linux2'):
            from socket import gethostname
            host = gethostname()
        else:
            host = 'localhost'

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

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


From noreply@sourceforge.net  Mon Aug  6 21:48:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:48:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-448403 ] libpython2.2.a missing -- Make Failure
Message-ID: <E15TrIa-0004OE-00@usw-sf-web3.sourceforge.net>

Bugs item #448403, was opened at 2001-08-06 06:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448403&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin v. Lіwis (loewis)
Summary: libpython2.2.a missing -- Make Failure

Initial Comment:
Hi,

In trying to install Python for the first time on a Sun
Ultrasparc 10, I followed recommended procedure and
obtained the following error (whilst runing "make"):

gcc   -o python \
                Modules/python.o \
                libpython2.2.a -lpthread -lsocket -lnsl
-ldl  -lthread   -lm  
gcc: libpython2.2.a: No such file or directory
make: *** [python] Error 1

Any assistance would be greatly appreciated.

All the best,

Lars


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

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


From noreply@sourceforge.net  Mon Aug  6 21:48:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:48:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-448546 ] rexec:make_re() should not use pre?
Message-ID: <E15TrIl-0005bc-00@usw-sf-web2.sourceforge.net>

Bugs item #448546, was opened at 2001-08-06 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448546&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: rexec:make_re() should not use pre?

Initial Comment:
The rexec module contains a mysterious make_re()
function that seems to hard-code the 're' module as
using 'pre'.  Why is this?  Why can't the standard
'sre' module be used, and why does this module have to
be pre-initialized?

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

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


From noreply@sourceforge.net  Mon Aug  6 21:50:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:50:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-440178 ] Build not finding libtk on Solaris 2.6
Message-ID: <E15TrKs-0005di-00@usw-sf-web2.sourceforge.net>

Bugs item #440178, was opened at 2001-07-10 12:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440178&group_id=5470

Category: Build
>Group: Not a Bug
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build not finding libtk on Solaris 2.6

Initial Comment:
Using gcc 2.95.3 for Solaris 2.6 I was able to build a version
of Python 2.1 without additional modules apparently without 
problem albeit with a fair number of compiler warnings .

But when I tried to rebuild it with Tk after doing a
make clobber, the library build could not find libtk.

I downloaded version 8.3 of tcl and Tk from the sunfreeware
site; the pkgadd loaded them into /usr/local/lib.
libtk8.3.s0
libtcl8.3.so

_tkinter and tkappinit apparently compiled OK but the
library build failed (also with a copy of  libtk  in the local
directory (/opt2/GNU/Python2.1) where I had unpacked
Python2.1 .

The edited portion of Setup was as follows :


# *** Always uncomment this (leave the leading underscore in!):
_tkinter _tkinter.c tkappinit.c -DWITH_APPINIT \
# *** Uncomment and edit to reflect where your Tcl/Tk libraries are:
	-L/usr/local/lib \
# *** Uncomment and edit to reflect where your Tcl/Tk headers are:
	-I/usr/local/include \
# *** Uncomment and edit to reflect where your X11 header files are:
#	-I/usr/X11R6/include \
# *** Or uncomment this for Solaris:
	-I/usr/openwin/include \
# *** Uncomment and edit for Tix extension only:
#	-DWITH_TIX -ltix8.1.8.2 \
# *** Uncomment and edit for BLT extension only:
#	-DWITH_BLT -I/usr/local/blt/blt8.0-unoff/include -lBLT8.0 \
# *** Uncomment and edit for PIL (TkImaging) extension only:
#     (See http://www.pythonware.com/products/pil/ for more info)
#	-DWITH_PIL -I../Extensions/Imaging/libImaging  tkImaging.c \
# *** Uncomment and edit for TOGL extension only:
#	-DWITH_TOGL togl.c \
# *** Uncomment and edit to reflect your Tcl/Tk versions:
	-ltk8.3 -ltcl8.3 \
# *** Uncomment and edit to reflect where your X11 libraries are:
#	-L/usr/X11R6/lib \
# *** Or uncomment this for Solaris:
	-L/usr/openwin/lib \
# *** Uncomment these for TOGL extension only:
#	-lGL -lGLU -lXext -lXmu \
# *** Uncomment for AIX:
#	-lld \
# *** Always uncomment this; X11 libraries to link with:
	-lX11


An edited portion of the make output follows :

gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   -DWITH_APPINIT 
-I/usr/local/include -I/usr/openwin/include -c ./Modules/_tkinter.c -o Modules/_tkinter.o
In file included from /usr/local/include/tk.h:83,
                 from ./Modules/_tkinter.c:45:
/usr/openwin/include/X11/Xlib.h:149: warning: function declaration isn't a prototype
                 (several more such)
/usr/openwin/include/X11/Xlib.h:2063: warning: type defaults to `int' in declaration of 
`XSetTransientForHint'
                   (Many more such)
/usr/openwin/include/X11/Xlib.h:4162: warning: type defaults to `int' in declaration of 
`XWindowEvent'
gcc -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H   -DWITH_APPINIT 
-I/usr/local/include -I/usr/openwin/include -c ./Modules/tkappinit.c -o Modules/tkappinit.o
In file included from /usr/local/include/tk.h:83,
                 from ./Modules/tkappinit.c:16:
/usr/openwin/include/X11/Xlib.h:149: warning: function declaration isn't a prototype
                 (ditto)
/usr/openwin/include/X11/Xlib.h:2063: warning: type defaults to `int' in declaration of 
`XSetTransientForHint'
                     (ditto)
/usr/openwin/include/X11/Xlib.h:4162: warning: type defaults to `int' in declaration of 
`XWindowEvent'
if test -f buildno; then \
        expr `cat buildno` + 1 >buildno1; \
        mv -f buildno1 buildno; \
else echo 1 >buildno; fi
gcc -c -g -O2 -Wall -Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -DBUILD=`cat buildno` 
-o Modules/getbuildinfo.o ./Modules/getbuildinfo.c
rm -f libpython2.1.a
ar cr libpython2.1.a Modules/getbuildinfo.o
ar cr libpython2.1.a Parser/acceler.o  Parser/grammar1.o  Parser/listnode.o  Parser/node.o  
Parser/parser.o  Parser/parsetok.o  Parser/tokenizer.o  Parser/bitset.o  Parser/metagrammar.o 
Parser/myreadline.o
ar cr libpython2.1.a Objects/abstract.o  Objects/bufferobject.o  Objects/cellobject.o  
Objects/classobject.o  Objects/cobject.o  Objects/complexobject.o  Objects/fileobject.o  
Objects/floatobject.o  Objects/frameobject.o  Objects/funcobject.o  Objects/intobject.o  
Objects/listobject.o  Objects/longobject.o  Objects/dictobject.o  Objects/methodobject.o  
Objects/moduleobject.o  Objects/object.o  Objects/rangeobject.o  Objects/sliceobject.o  
Objects/stringobject.o  Objects/tupleobject.o  Objects/typeobject.o  Objects/unicodeobject.o  
Objects/unicodectype.o
ar cr libpython2.1.a Python/bltinmodule.o  Python/exceptions.o  Python/ceval.o  Python/compile.o  
Python/codecs.o  Python/errors.o  Python/frozen.o  Python/frozenmain.o  Python/future.o  
Python/getargs.o  Python/getcompiler.o  Python/getcopyright.o  Python/getmtime.o  
Python/getplatform.o  Python/getversion.o  Python/graminit.o  Python/import.o  Python/importdl.o  
Python/marshal.o  Python/modsupport.o  Python/mystrtoul.o  Python/pyfpe.o  Python/pystate.o  
Python/pythonrun.o  Python/structmember.o  Python/symtable.o  Python/sysmodule.o  
Python/traceback.o  Python/getopt.o  Python/dynload_shlib.o  Python/thread.o Python/thread.o
ar cr libpython2.1.a Modules/config.o  Modules/getpath.o  Modules/main.o 
ar cr libpython2.1.a Modules/gcmodule.o  Modules/threadmodule.o  Modules/signalmodule.o  
Modules/posixmodule.o  Modules/_sre.o  Modules/_tkinter.o Modules/tkappinit.o
: libpython2.1.a
gcc   -o python \
                Modules/python.o \
                libpython2.1.a -lpthread -lsocket -lnsl -ldl  -lthread -L/usr/local/lib -ltk8.3 -ltcl8.3 
-L/usr/openwin/lib -lX11  -lm  
PYTHONPATH= ./python ./setup.py build
ld.so.1: ./python: fatal: libtk8.3.so: open failed: No such file or directory
*** Error code 137
make: Fatal error: Command failed for target `sharedmods'


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:50

Message:
Logged In: YES 
user_id=31392

It looks like the problem here is that the libtk8.3.so can't
be found at load time.  The user probably needs to set
LD_LIBRARY_PATH, but the user in question is anonymous so
her or she will probably never know.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:52:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:52:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15TrM5-00038C-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-06 13:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 01:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Mon Aug  6 21:57:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:57:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-443600 ] overload of the slicing operator
Message-ID: <E15TrRd-0004VC-00@usw-sf-web3.sourceforge.net>

Bugs item #443600, was opened at 2001-07-22 13:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Daniel (spacy73)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: overload of the slicing operator

Initial Comment:
It's impossible to overload the slicing operator
to take two float-values.


PythonWin 2.1 (#15, Apr 23 2001, 18:00:35) [MSC 32 bit 
(Intel)] on win32.
>>> class a:
... 	def __getitem__(self, index):
... 		print repr(index)
... 
>>> 
>>> aa=a()
>>> 
>>> aa[1.5]
1.5
>>> 
>>> aa[1.5:2.5]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: slice indices must be integers
>>>
>>> aa[1.5:2.5:3.5]
slice(1.5, 2.5, 3.5)
>>> 

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:57

Message:
Logged In: YES 
user_id=31392

No idea what the right thing to do here.  BDFL?

You can do aa[slice(1.5, 2.5)], so I don't see why you
shouldn't be able to do aa[1.5:2.5].


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

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


From noreply@sourceforge.net  Mon Aug  6 21:58:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:58:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-443464 ] Import Numeric RandomArray on 2.1.1
Message-ID: <E15TrSX-0003ak-00@usw-sf-web1.sourceforge.net>

Bugs item #443464, was opened at 2001-07-21 18:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443464&group_id=5470

Category: None
>Group: 3rd Party
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Import Numeric RandomArray on 2.1.1

Initial Comment:
Mandrake 7.2 system, python2.1.1 builds okay, but when
I import RandomArray I get the following:

>>> import RandomArray
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/usr/lib/python2.1/site-packages/Numeric/RandomArray.py",
line 3, in ?
    import LinearAlgebra
  File
"/usr/lib/python2.1/site-packages/Numeric/LinearAlgebra.py",
line 8, in ?
    import lapack_lite
ImportError:
/usr/lib/python2.1/site-packages/Numeric/lapack_lite.so:
undefined symbol: dgesvd_ 

I've notified the Numeric team as well. In relation to
another bug mentioned here, I have no trouble importing
Numeric-20 on my system.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:58

Message:
Logged In: YES 
user_id=31392

It doesn't look like there is a Python problem here.


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

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


From noreply@sourceforge.net  Mon Aug  6 21:59:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:59:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-448153 ] Dictionary iterators break old code
Message-ID: <E15TrSn-0005jt-00@usw-sf-web2.sourceforge.net>

Bugs item #448153, was opened at 2001-08-05 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448153&group_id=5470

>Category: Python Library
>Group: Python 2.2
Status: Open
Resolution: None
>Priority: 5
Submitted By: Martin v. Lіwis (loewis)
>Assigned to: Martin v. Lіwis (loewis)
Summary: Dictionary iterators break old code

Initial Comment:
With the introduction of dictionary iterators, 
iteration over UserDict specializations may silently 
break existing code. The attached code is a 
simplification of the xml.dom.NamedNodeMap class, 
which provides iteration over the values using a 
well-defined order, which is implemented in 
__getitem__. In Python 2.2a1, __getitem__ is not 
called anymore, thus the code breaks.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 13:59

Message:
Logged In: YES 
user_id=6380

Aaaaaaargh!!!!!!!

You mean somebody wrote a subclass of UserDict that attempts
to behave like a sequence by checking the type of the
__getitem__ argument??????????

Yuck!!!!!!!!!!!!!!!

You XML weenies are sickos. :-)

Now that I've got that out of the way :-),

Short of totally dropping dictionary iterators, the only
solution I can see it to remove the __iter__ method of
UserDict. That is backwards compatible, but it removes the
ability to iterate over UserDict instances (except for the
sick ones :-), thus making UserDict less like a dictionary.

But since UserDict is likely to become deprecated anyway in
favor of subclassing from the 'dictionary' built-in type,
this solution seems acceptable -- but only if this trick is
also in use outside the XML code.  I would prefer to see the
XML code fixed, since it can now properly define __iter__ to
iterate over whatever it wants to in any sequence it would
like. :-)


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

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


From noreply@sourceforge.net  Mon Aug  6 21:59:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 13:59:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-442903 ] import Numeric fails on Linux
Message-ID: <E15TrTA-0003bJ-00@usw-sf-web1.sourceforge.net>

Bugs item #442903, was opened at 2001-07-19 14:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442903&group_id=5470

Category: Extension Modules
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: import Numeric fails on Linux

Initial Comment:
\h* python
Python 2.1.1c1 (#1, Jul 19 2001, 14:43:40) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import Numeric
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 62:
elf_get_dynamic_info: Assertion `! "bad dynamic tag"'
failed!
\h* ^D


Python was compiled on a Debian Linux system,
with 2.4.5 kernel.  It runs there, but creates the
above
error when the same code is run on a Red Hat system
with a 2.4.0 kernel.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:59

Message:
Logged In: YES 
user_id=31392

Have you tried contacting the Numeric team?  This doesn't
look like it was anything to do with Python.


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

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


From noreply@sourceforge.net  Mon Aug  6 22:00:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 14:00:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught
Message-ID: <E15TrUI-0004XI-00@usw-sf-web3.sourceforge.net>

Bugs item #439992, was opened at 2001-07-10 02:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mark Hammond (mhammond)
Summary: [win32] KeyboardInterrupt Not Caught

Initial Comment:
The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2
with the command line:  python test.py

In both cases, running python 2.1.

The program works as expected under unix and IDLE on Windows 2000, but it
does *not* catch the interrupt in the command line version of Win32 python...
i.e., The traceback message appears rather than my "Leaving Dodge..." message.


while 1:
    try:
        x = raw_input().upper()
        print x
    except KeyboardInterrupt:
        print "Leaving Dodge...\n"
        break

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

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


From noreply@sourceforge.net  Mon Aug  6 22:12:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 14:12:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-437984 ] package name truncation to 50 chars.
Message-ID: <E15TrgI-0005Ql-00@usw-sf-web3.sourceforge.net>

Bugs item #437984, was opened at 2001-07-02 11:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: chris tignor (ctignor)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: package name truncation to 50 chars.

Initial Comment:
Truncation of package names to 50 characters once
represented as strings becomes extremely confusing for
development purposes, even more so when as it exists as
an undocumented event. I request full package names be
represented.  Thank-you.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:12

Message:
Logged In: YES 
user_id=31392

The code that prints these repr() has a constant size
buffer.  What constant would make you happy?


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

Comment By: chris tignor (ctignor)
Date: 2001-07-06 14:36

Message:
Logged In: YES 
user_id=255620

here is an exmaple:

from com.ezways.data_mining.form_tools import
TransitFormInputElement
transitForm =
TransitFormInputElement.TransitFormInputElement()
print transitForm

# below is what prints, no such thing (module/package/class)
as TransitFormInput anywhere on the system
<com.ezways.data_mining.form_tools.TransitFormInput.TransitFormInputElement
instance at 0x81e2e44>

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:05

Message:
Logged In: YES 
user_id=31392

Can you include a more specific description of the problem 
you are having?  An example would go a long way.


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

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


From noreply@sourceforge.net  Mon Aug  6 22:16:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 14:16:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E15TrjF-0005St-00@usw-sf-web3.sourceforge.net>

Bugs item #429084, was opened at 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:16

Message:
Logged In: YES 
user_id=31392

Itamar-- any interest in figuring out which of these is
really a problem?

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

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


From noreply@sourceforge.net  Mon Aug  6 22:17:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 14:17:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-448144 ] incompatible change of string type name
Message-ID: <E15TrkL-0004Fx-00@usw-sf-web1.sourceforge.net>

Bugs item #448144, was opened at 2001-08-05 05:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448144&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: incompatible change of string type name

Initial Comment:
In Python 2.1 and earlier, type("").__name__ was 
"string". In 2.2a1, it is "str". This change breaks 
the xml.marshal package of PyXML, which uses the type 
name to generate a method m_string. Since there is no 
m_str method implemented, running the marshaller 
under 2.2 fails.


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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-06 14:17

Message:
Logged In: YES 
user_id=31435

Note that the name "long int" also changed to "long".  The 
std repr.py was affected by this (and by string->str) too.

It was no bother to change it in repr.py, I expect the 
point is more (a) possibly silent breakage (repr.py didn't 
know it was broken), and (b) writing code that works under 
all versions of Python.

WRT the latter, I bet Martin would be done if he just adds a

    m_str = m_string

line to the affected class(es).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 11:47

Message:
Logged In: YES 
user_id=6380

Hm. If I change the type's name back to 'string', the
built-in name for it has to be 'string' (otherwise some part
of marshal or pickle won't work). But I had hoped to use the
'string' built-in name for the base class of str and
unicode.

Is it terribly inconvenient to have to rename the m_string
function to m_str?


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

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


From noreply@sourceforge.net  Mon Aug  6 22:23:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 14:23:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-210683 ] can't compile with SSL support on WinNT (PR#403)
Message-ID: <E15Trqv-0004LV-00@usw-sf-web1.sourceforge.net>

Bugs item #210683, was opened at 2000-07-31 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210683&group_id=5470

Category: Windows
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Moshe Zadka (moshez)
Summary: can't compile with SSL support on WinNT (PR#403)

Initial Comment:
Jitterbug-Id: 403
Submitted-By: falk.lehmann@gmx.net
Date: Mon, 17 Jul 2000 21:59:56 -0400 (EDT)
Version: 1.6a2
OS: WinNT 4.0


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



====================================================================
Audit trail:
Tue Jul 25 07:25:55 2000	guido	changed notes
Tue Jul 25 07:25:55 2000	guido	moved from incoming to open

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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-06 14:23

Message:
Logged In: YES 
user_id=31435

Reassigned to Moshe, cuz he's the last person I recall 
making any kind of serious noise about cleaning up the SLL 
mess.

Peter, you don't need SSL support to grab URLs on Windows!  
It sounds like you're waiting for something you don't 
need.  socketmodule.c works fine on Windows Python, and has 
for years; it's only the SSL *extension* nobody has ported 
to Windows.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 12:48

Message:
Logged In: NO 

Now that Python 2.1 is out, it sure would be nice
to run Python URL-grabbers on Win systems! The list
o' messages for this item suggests that you'be
been waiting since September 2000 for a volunteer
to fix PR #403, and if I could I would but I can't.

Do the Lords of SourceForge have a guess at the odds
that this will make it into a version of the Win
distribution for Python anytime "soon" (eg, by, say,
Halloween 2001)?

Thanks!

    Peter

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

Comment By: Tim Peters (tim_one)
Date: 2000-09-15 19:07

Message:
Moved to PEP42, awaiting a volunteer can do this.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-07 15:08

Message:
As we've discussed, this is not an issue for 2.0.  Assigned to Tim for resurrection when appropriate since this is Windows-specific. 

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-08-30 12:01

Message:
Let's not worry about this for 2.0. While the OpenSSL support is part of the socket module, we don't have the resources right now to port that support to Windows.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-08-23 10:35

Message:
This is a bug.  Standard extensions modules should compile, even on obscure platforms like Windows NT.  Need a Windows user with time to install OpenSSL to fix this.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
Windows compile fails when using openSSL.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 14:00:20 -0500

> 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/)



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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:02

Message:
From: Falk Lehmann <Falk.Lehmann@gmx.net>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 13:46:45 -0500

[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/)
> 



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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:01

Message:
From: Guido van Rossum <guido@beopen.com>
Subject: Re: [Python-bugs-list] compiling on WinNT (PR#403)
Date: Mon, 24 Jul 2000 11:35:24 -0500

> 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/)



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

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


From noreply@sourceforge.net  Mon Aug  6 23:00:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 15:00:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-421878 ] File in a directory with a special chara
Message-ID: <E15TsQf-0006tw-00@usw-sf-web3.sourceforge.net>

Bugs item #421878, was opened at 2001-05-06 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421878&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gсbor BORGULYA (borgulya)
>Assigned to: Martin v. Lіwis (loewis)
Summary: File in a directory with a special chara

Initial Comment:
Using IDLE I tryed to save my work in the directory

C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt

but it failed:

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\program files\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 145, in save_a_copy
    self.writefile(filename)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 152, in writefile
    f = open(filename, "w")
UnicodeError: ASCII encoding error: ordinal not in range(128)

After a log of tries I have renamed the directory: (sajat instead of sajсt)

C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt

and the file was finally saved.

I use WIN2000P.

I hope you can fix it.

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

Comment By: Gсbor BORGULYA (borgulya)
Date: 2001-05-09 10:31

Message:
Logged In: YES 
user_id=131307

Summary:
IDLE couldn't save into the directory
  C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt
but when it was renamed to
  C:\Documents and Settings\tdk.000\Dokumentumok\python\sajat
(without the accent above the last "a") it suceeded.

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

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


From noreply@sourceforge.net  Tue Aug  7 03:41:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 19:41:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-443600 ] overload of the slicing operator
Message-ID: <E15TwoJ-0001A9-00@usw-sf-web3.sourceforge.net>

Bugs item #443600, was opened at 2001-07-22 13:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Daniel (spacy73)
Assigned to: Guido van Rossum (gvanrossum)
Summary: overload of the slicing operator

Initial Comment:
It's impossible to overload the slicing operator
to take two float-values.


PythonWin 2.1 (#15, Apr 23 2001, 18:00:35) [MSC 32 bit 
(Intel)] on win32.
>>> class a:
... 	def __getitem__(self, index):
... 		print repr(index)
... 
>>> 
>>> aa=a()
>>> 
>>> aa[1.5]
1.5
>>> 
>>> aa[1.5:2.5]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: slice indices must be integers
>>>
>>> aa[1.5:2.5:3.5]
slice(1.5, 2.5, 3.5)
>>> 

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 19:41

Message:
Logged In: YES 
user_id=6380

It's complicated because the internal APIs are all busted, and "fixing" them might cause
backwards compatibilities, i.e. break existing 3rd party extensions.

This has been broken for a long time.  I agree that it ought to be fixed,
but not at the cost of backwards incompatibility, and I don't give it high priority.

Maybe we can define completely new C APIs that do this right
and then define the old ones just as b/w compatibility APIs.

But part of it is that we can't change the specs for calls into extension types,
because we don't know that the types would support the new rules.
This can be fixed by asking the types to specify some flag bit in their tp_flags field,
but it all gets very complicated -- for little gain, IMO.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:57

Message:
Logged In: YES 
user_id=31392

No idea what the right thing to do here.  BDFL?

You can do aa[slice(1.5, 2.5)], so I don't see why you
shouldn't be able to do aa[1.5:2.5].


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

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


From noreply@sourceforge.net  Tue Aug  7 07:10:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 23:10:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-448144 ] incompatible change of string type name
Message-ID: <E15U04E-00009n-00@usw-sf-web1.sourceforge.net>

Bugs item #448144, was opened at 2001-08-05 05:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448144&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: incompatible change of string type name

Initial Comment:
In Python 2.1 and earlier, type("").__name__ was 
"string". In 2.2a1, it is "str". This change breaks 
the xml.marshal package of PyXML, which uses the type 
name to generate a method m_string. Since there is no 
m_str method implemented, running the marshaller 
under 2.2 fails.


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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-06 23:10

Message:
Logged In: YES 
user_id=21627

Assigning m_str from m_string is indeed what I did for 
PyXML 0.6.6. Yet, I was displeased that it broke in the 
first place.
I'd accept if you close this report with "Won't fix" - 
I just wanted to report the problem, and perhaps ask for 
somebody to produce a list of incompatible changes in 2.2.


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 14:17

Message:
Logged In: YES 
user_id=31435

Note that the name "long int" also changed to "long".  The 
std repr.py was affected by this (and by string->str) too.

It was no bother to change it in repr.py, I expect the 
point is more (a) possibly silent breakage (repr.py didn't 
know it was broken), and (b) writing code that works under 
all versions of Python.

WRT the latter, I bet Martin would be done if he just adds a

    m_str = m_string

line to the affected class(es).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 11:47

Message:
Logged In: YES 
user_id=6380

Hm. If I change the type's name back to 'string', the
built-in name for it has to be 'string' (otherwise some part
of marshal or pickle won't work). But I had hoped to use the
'string' built-in name for the base class of str and
unicode.

Is it terribly inconvenient to have to rename the m_string
function to m_str?


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

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


From noreply@sourceforge.net  Tue Aug  7 07:16:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 23:16:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-448153 ] Dictionary iterators break old code
Message-ID: <E15U0Al-0000ah-00@usw-sf-web3.sourceforge.net>

Bugs item #448153, was opened at 2001-08-05 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448153&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Martin v. Lіwis (loewis)
Summary: Dictionary iterators break old code

Initial Comment:
With the introduction of dictionary iterators, 
iteration over UserDict specializations may silently 
break existing code. The attached code is a 
simplification of the xml.dom.NamedNodeMap class, 
which provides iteration over the values using a 
well-defined order, which is implemented in 
__getitem__. In Python 2.2a1, __getitem__ is not 
called anymore, thus the code breaks.


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

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-06 23:16

Message:
Logged In: YES 
user_id=21627

I've already fixed it in PyXML, although the only way I 
could find to fix it was to add an __iter__; I cannot take 
away the __getitem__ since the code has to work in older 
Python versions.

The solution I would prefer to see is that UserDict offers 
a second class, say IterableUserDict, which would be for 
educational purposes only; anybody who really wants a 
dictionary that you can iterate over should inherit from 
dictionary.

That also raises the question whether UserDict 
applications in the standard library should be changed to 
inherit from dictionary. The major incompatibility I can 
see with doing so is that the .data member goes away.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 13:59

Message:
Logged In: YES 
user_id=6380

Aaaaaaargh!!!!!!!

You mean somebody wrote a subclass of UserDict that attempts
to behave like a sequence by checking the type of the
__getitem__ argument??????????

Yuck!!!!!!!!!!!!!!!

You XML weenies are sickos. :-)

Now that I've got that out of the way :-),

Short of totally dropping dictionary iterators, the only
solution I can see it to remove the __iter__ method of
UserDict. That is backwards compatible, but it removes the
ability to iterate over UserDict instances (except for the
sick ones :-), thus making UserDict less like a dictionary.

But since UserDict is likely to become deprecated anyway in
favor of subclassing from the 'dictionary' built-in type,
this solution seems acceptable -- but only if this trick is
also in use outside the XML code.  I would prefer to see the
XML code fixed, since it can now properly define __iter__ to
iterate over whatever it wants to in any sequence it would
like. :-)


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

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


From noreply@sourceforge.net  Tue Aug  7 07:55:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 06 Aug 2001 23:55:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-448679 ] Left to right
Message-ID: <E15U0m0-0001Yc-00@usw-sf-web1.sourceforge.net>

Bugs item #448679, was opened at 2001-08-06 23:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448679&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Left to right

Initial Comment:
The Ref Man doesn't explicitly say anything about 
Python's left-to-right evaluation order.  Strict left-
to-right was Guido's intent, though, and it comes up a 
few times per year on c.l.py (indeed, I was just 
replying to a msg asking about it).

The docs should get fleshed out.

There's also a bug:

>>> counter = 0
>>> def i():
...     global counter
...     counter += 1
...     return counter
...
>>> {i(): i()}
{2: 1}
>>> {i(): i(), i(): i()}
{4: 3, 6: 5}
>>>

That is, key:value *pairs* are evaluated left to 
right, but within a single key:value pair, the value 
gets evaluated first.  When I asked Guido about that 
some years ago, he agreed it was a bug.


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

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


From noreply@sourceforge.net  Tue Aug  7 08:27:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 00:27:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E15U1Gg-0002mr-00@usw-sf-web1.sourceforge.net>

Bugs item #429084, was opened at 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

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

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 00:27

Message:
Logged In: YES 
user_id=32065

My knowledge of C is rather lacking. However, some cases are
pretty easy to check. For example, here's what my Debian man
pages say about some of the above functions, under the Bugs
subheading:

tempnam: Never use this function. Use tmpfile(3) instead.
tmpnam: Never use this function. Use tmpfile(3) instead.

And it also says tmpfile is part of the POSIX standard, so
using it shouldn't be a problem.

The strcat in getpath.c seems fine since the previous line
checks that the length is less than the allowable max and it
only appends one character.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:16

Message:
Logged In: YES 
user_id=31392

Itamar-- any interest in figuring out which of these is
really a problem?

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

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


From noreply@sourceforge.net  Tue Aug  7 08:46:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 00:46:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-414032 ] clib option is broken
Message-ID: <E15U1Yv-0003zx-00@usw-sf-web3.sourceforge.net>

Bugs item #414032, was opened at 2001-04-05 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414032&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: A.M. Kuchling (akuchling)
Summary: clib option is broken

Initial Comment:
You cannot build a source distribution when the setup script contains libraries.

Here is the traceback:

C:\sf\py2exe>setup sdist
running sdist
Traceback (most recent call last):
  File "C:\sf\py2exe\setup.py", line 317, in ?
    package_dir={'py2exe.tools': "tools" + sys.version[:3]},
  File "c:\python20\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\python20\distutils\dist.py", line 903, in run_commands
    self.run_command(cmd)
  File "c:\python20\distutils\dist.py", line 923, in run_command
    cmd_obj.run()
  File "C:\Python20\distutils\command\sdist.py", line 142, in run
    self.get_file_list()
  File "C:\Python20\distutils\command\sdist.py", line 241, in get_file_list
    self.add_defaults()
  File "C:\Python20\distutils\command\sdist.py", line 318, in add_defaults
    self.filelist.extend(build_clib.get_source_files())
  File "c:\python20\distutils\cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: get_source_files

C:\sf\py2exe>

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:46

Message:
Logged In: YES 
user_id=28463

The problem is the missing get_source_files method in 
distutils/command/build_clib.py.

I think someone has already solved the problem, it doesn't
seem too hard.

Adding a method similar to build_ext.py should
the problem.

See the attached file for a suggestion. (It is not tested by
me.)

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

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


From noreply@sourceforge.net  Tue Aug  7 08:50:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 00:50:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-414032 ] clib option is broken
Message-ID: <E15U1dC-00043L-00@usw-sf-web3.sourceforge.net>

Bugs item #414032, was opened at 2001-04-05 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414032&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: A.M. Kuchling (akuchling)
Summary: clib option is broken

Initial Comment:
You cannot build a source distribution when the setup script contains libraries.

Here is the traceback:

C:\sf\py2exe>setup sdist
running sdist
Traceback (most recent call last):
  File "C:\sf\py2exe\setup.py", line 317, in ?
    package_dir={'py2exe.tools': "tools" + sys.version[:3]},
  File "c:\python20\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\python20\distutils\dist.py", line 903, in run_commands
    self.run_command(cmd)
  File "c:\python20\distutils\dist.py", line 923, in run_command
    cmd_obj.run()
  File "C:\Python20\distutils\command\sdist.py", line 142, in run
    self.get_file_list()
  File "C:\Python20\distutils\command\sdist.py", line 241, in get_file_list
    self.add_defaults()
  File "C:\Python20\distutils\command\sdist.py", line 318, in add_defaults
    self.filelist.extend(build_clib.get_source_files())
  File "c:\python20\distutils\cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: get_source_files

C:\sf\py2exe>

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:50

Message:
Logged In: YES 
user_id=28463

(How can I attach files?)

    def get_source_files (self):
        filenames = []
        for (lib_name, build_info) in self.libraries:
            sources = build_info.get('sources')
            if sources is None or type(sources) not in \
                       (ListType, TupleType):
                raise DistutilsSetupError, \
                ("in 'libraries' option (library '%s'), "+ \
                "'sources' must be present and must be "+ \
                "a list of source filenames") % lib_name
            filenames.extend(sources)

        self.check_extensions_list(self.extensions)

        return filenames


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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:46

Message:
Logged In: YES 
user_id=28463

The problem is the missing get_source_files method in 
distutils/command/build_clib.py.

I think someone has already solved the problem, it doesn't
seem too hard.

Adding a method similar to build_ext.py should
the problem.

See the attached file for a suggestion. (It is not tested by
me.)

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

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


From noreply@sourceforge.net  Tue Aug  7 09:01:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 01:01:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-414032 ] clib option is broken
Message-ID: <E15U1oN-0004Qz-00@usw-sf-web1.sourceforge.net>

Bugs item #414032, was opened at 2001-04-05 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414032&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: A.M. Kuchling (akuchling)
Summary: clib option is broken

Initial Comment:
You cannot build a source distribution when the setup script contains libraries.

Here is the traceback:

C:\sf\py2exe>setup sdist
running sdist
Traceback (most recent call last):
  File "C:\sf\py2exe\setup.py", line 317, in ?
    package_dir={'py2exe.tools': "tools" + sys.version[:3]},
  File "c:\python20\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\python20\distutils\dist.py", line 903, in run_commands
    self.run_command(cmd)
  File "c:\python20\distutils\dist.py", line 923, in run_command
    cmd_obj.run()
  File "C:\Python20\distutils\command\sdist.py", line 142, in run
    self.get_file_list()
  File "C:\Python20\distutils\command\sdist.py", line 241, in get_file_list
    self.add_defaults()
  File "C:\Python20\distutils\command\sdist.py", line 318, in add_defaults
    self.filelist.extend(build_clib.get_source_files())
  File "c:\python20\distutils\cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: get_source_files

C:\sf\py2exe>

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 01:01

Message:
Logged In: YES 
user_id=28463

remove the line

        self.check_extensions_list(self.extensions)

in the previous comment  (it doesn't belong there,
it was accidently pasted in.)

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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:50

Message:
Logged In: YES 
user_id=28463

(How can I attach files?)

    def get_source_files (self):
        filenames = []
        for (lib_name, build_info) in self.libraries:
            sources = build_info.get('sources')
            if sources is None or type(sources) not in \
                       (ListType, TupleType):
                raise DistutilsSetupError, \
                ("in 'libraries' option (library '%s'), "+ \
                "'sources' must be present and must be "+ \
                "a list of source filenames") % lib_name
            filenames.extend(sources)

        self.check_extensions_list(self.extensions)

        return filenames


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

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:46

Message:
Logged In: YES 
user_id=28463

The problem is the missing get_source_files method in 
distutils/command/build_clib.py.

I think someone has already solved the problem, it doesn't
seem too hard.

Adding a method similar to build_ext.py should
the problem.

See the attached file for a suggestion. (It is not tested by
me.)

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

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


From noreply@sourceforge.net  Tue Aug  7 14:43:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 06:43:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E15U78n-0001K6-00@usw-sf-web2.sourceforge.net>

Bugs item #429084, was opened at 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 06:43

Message:
Logged In: YES 
user_id=6380

I don't know how useful these results are.

Python itself doesn't use tmpnam or tempnam, but it makes
them available to Python code that wants to use them.
Whether or not that's a security problem or race condition
depends on the use context of that Python code. 

If we removed these functions, we would break Python code
that uses them. Also note that where applicable, tmpnam_r is
called.

I propose to close this bug report, unless you can point to
*specific* cases where your program found an *actual* bug in
the code.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 00:27

Message:
Logged In: YES 
user_id=32065

My knowledge of C is rather lacking. However, some cases are
pretty easy to check. For example, here's what my Debian man
pages say about some of the above functions, under the Bugs
subheading:

tempnam: Never use this function. Use tmpfile(3) instead.
tmpnam: Never use this function. Use tmpfile(3) instead.

And it also says tmpfile is part of the POSIX standard, so
using it shouldn't be a problem.

The strcat in getpath.c seems fine since the previous line
checks that the length is less than the allowable max and it
only appends one character.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:16

Message:
Logged In: YES 
user_id=31392

Itamar-- any interest in figuring out which of these is
really a problem?

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

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


From noreply@sourceforge.net  Tue Aug  7 14:47:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 06:47:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-448144 ] incompatible change of string type name
Message-ID: <E15U7D1-0001UA-00@usw-sf-web1.sourceforge.net>

Bugs item #448144, was opened at 2001-08-05 05:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448144&group_id=5470

>Category: type/class unification
>Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: incompatible change of string type name

Initial Comment:
In Python 2.1 and earlier, type("").__name__ was 
"string". In 2.2a1, it is "str". This change breaks 
the xml.marshal package of PyXML, which uses the type 
name to generate a method m_string. Since there is no 
m_str method implemented, running the marshaller 
under 2.2 fails.


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

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

Message:
Logged In: YES 
user_id=21627

Assigning m_str from m_string is indeed what I did for 
PyXML 0.6.6. Yet, I was displeased that it broke in the 
first place.
I'd accept if you close this report with "Won't fix" - 
I just wanted to report the problem, and perhaps ask for 
somebody to produce a list of incompatible changes in 2.2.


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

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 14:17

Message:
Logged In: YES 
user_id=31435

Note that the name "long int" also changed to "long".  The 
std repr.py was affected by this (and by string->str) too.

It was no bother to change it in repr.py, I expect the 
point is more (a) possibly silent breakage (repr.py didn't 
know it was broken), and (b) writing code that works under 
all versions of Python.

WRT the latter, I bet Martin would be done if he just adds a

    m_str = m_string

line to the affected class(es).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 11:47

Message:
Logged In: YES 
user_id=6380

Hm. If I change the type's name back to 'string', the
built-in name for it has to be 'string' (otherwise some part
of marshal or pickle won't work). But I had hoped to use the
'string' built-in name for the base class of str and
unicode.

Is it terribly inconvenient to have to rename the m_string
function to m_str?


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

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


From noreply@sourceforge.net  Tue Aug  7 14:59:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 06:59:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught
Message-ID: <E15U7OC-0001Y0-00@usw-sf-web2.sourceforge.net>

Bugs item #439992, was opened at 2001-07-10 02:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] KeyboardInterrupt Not Caught

Initial Comment:
The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2
with the command line:  python test.py

In both cases, running python 2.1.

The program works as expected under unix and IDLE on Windows 2000, but it
does *not* catch the interrupt in the command line version of Win32 python...
i.e., The traceback message appears rather than my "Leaving Dodge..." message.


while 1:
    try:
        x = raw_input().upper()
        print x
    except KeyboardInterrupt:
        print "Leaving Dodge...\n"
        break

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 06:59

Message:
Logged In: YES 
user_id=6380

Yes, I'm afraid signal handling doesn't always work on
Windows.
I don't know Windows enough to understand how to fix this.

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

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


From noreply@sourceforge.net  Tue Aug  7 15:05:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 07:05:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-448352 ] returning stack frames scrambles globals
Message-ID: <E15U7U8-0002AA-00@usw-sf-web1.sourceforge.net>

Bugs item #448352, was opened at 2001-08-06 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448352&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Andreas Just (andijust)
Assigned to: Guido van Rossum (gvanrossum)
Summary: returning stack frames scrambles globals

Initial Comment:
When function return references to stack frame objects, various data in global or local namespaces 
are scrambled.

I'm adding an example, where returning a stack frame prevents a classes "__del__" method from 
being called. In addition, when assigning the returned stack frame lists to a global variable, I've got 
the list of imported modules destroyed.

I'm aware, that this might not be a real bug - maybe it's a case of "this has to be this way", as 
those objects are changed same time when they are used as return values. If it is, just drop this 
bug.

Andreas

-------------------------------------------------
Program example:
(This short script will prevent the "__del__" method from being called, when stack() returns 
references to the original frame objects and will work fine, when returning just some copies.)

#!/usr/bin/env python
import sys
import os

class FrameObjectCopy :
        """empty class for use in member function Logging.stack()"""

def stack(create_error) :
        frame = sys._getframe().f_back

        if create_error :
                # returning the frame runs into error
                return frame
        else :
                #
                # returning a copy will work fine
                frame_copy = FrameObjectCopy()
                for attrname in dir(frame) :
                        setattr(frame_copy,attrname,getattr(frame,attrname))
                return frame_copy




class test :
        def __init__(self,create_error) :
                print "***** init() *****"
                s = stack(create_error)
        def __del__(self) :
                print "***** del() *****"


print
print "Running correctly - __init__() and __del__() methods are called"
a=test(0)
del a

print
print "Running into error - only __init__() is called"
a=test(1)
del a


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 07:05

Message:
Logged In: YES 
user_id=6380

Closing this. Feel free to submit more information and then
we will reopen the report.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:41

Message:
Logged In: YES 
user_id=6380

The first problem you mention is indeed "that's how it
works". The frame keeps references to the local variables;
if you make the frame a local variable of itself, you create
a circular reference. I don't believe frames are currently
garbage-collected; they will be in 2.2 I believe.

I don't understand the second problem you are describing;
you have probably managed to confused yourself, but if not,
please post a code fragment that reproduces the problem here
(and describe it better -- I'm not quite sure what you are
observing).

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

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


From noreply@sourceforge.net  Tue Aug  7 15:12:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 07:12:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E15U7ac-0002TG-00@usw-sf-web2.sourceforge.net>

Bugs item #429084, was opened at 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

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

>Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 07:12

Message:
Logged In: YES 
user_id=32065

Well, as I said I don't know enough C in most cases to say
if they are bugs or not. However, I thought I should bring
it to the attention of those who do.

So if you say "assume that we knew what we were doing when
we wrote that code" I can't very well argue with that - so
sure, remove it :)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 06:43

Message:
Logged In: YES 
user_id=6380

I don't know how useful these results are.

Python itself doesn't use tmpnam or tempnam, but it makes
them available to Python code that wants to use them.
Whether or not that's a security problem or race condition
depends on the use context of that Python code. 

If we removed these functions, we would break Python code
that uses them. Also note that where applicable, tmpnam_r is
called.

I propose to close this bug report, unless you can point to
*specific* cases where your program found an *actual* bug in
the code.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 00:27

Message:
Logged In: YES 
user_id=32065

My knowledge of C is rather lacking. However, some cases are
pretty easy to check. For example, here's what my Debian man
pages say about some of the above functions, under the Bugs
subheading:

tempnam: Never use this function. Use tmpfile(3) instead.
tmpnam: Never use this function. Use tmpfile(3) instead.

And it also says tmpfile is part of the POSIX standard, so
using it shouldn't be a problem.

The strcat in getpath.c seems fine since the previous line
checks that the length is less than the allowable max and it
only appends one character.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:16

Message:
Logged In: YES 
user_id=31392

Itamar-- any interest in figuring out which of these is
really a problem?

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

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


From noreply@sourceforge.net  Tue Aug  7 15:21:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 07:21:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-429084 ] Results of running Flawfinder
Message-ID: <E15U7jN-0002nz-00@usw-sf-web1.sourceforge.net>

Bugs item #429084, was opened at 2001-05-31 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429084&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: None
Priority: 2
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Results of running Flawfinder

Initial Comment:
I tried running Flawfinder
(http://www.dwheeler.com/flawfinder/) on the Python
source code. SInce I'm not nasty I won't paste *all* of
the errors found, but here some:

/usr/src/python-cvs/Modules/flmodule.c:373 [2] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. Risk is low because the source
has a constant maximum length
/usr/src/python-cvs/Modules/posixmodule.c:4191 [3]
(tmpfile) tempnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/posixmodule.c:4237 [3]
(tmpfile) tmpnam: temporary file race condition. . 
/usr/src/python-cvs/Modules/_weakref.c:141 [4] (buffer)
sprintf: does not check for buffer overflows. Use
snprintf or vsnprintf. 
/usr/src/python-cvs/Modules/almodule.c:51 [4] (format)
vsprintf: Potential format string problem. Make Format
string constant. 
/usr/src/python-cvs/Modules/getpath.c:169 [4] (buffer)
strcat: does not check for buffer overflows. Consider
using strncat or strlcat. 

There were lots more - try it and see.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 07:12

Message:
Logged In: YES 
user_id=32065

Well, as I said I don't know enough C in most cases to say
if they are bugs or not. However, I thought I should bring
it to the attention of those who do.

So if you say "assume that we knew what we were doing when
we wrote that code" I can't very well argue with that - so
sure, remove it :)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 06:43

Message:
Logged In: YES 
user_id=6380

I don't know how useful these results are.

Python itself doesn't use tmpnam or tempnam, but it makes
them available to Python code that wants to use them.
Whether or not that's a security problem or race condition
depends on the use context of that Python code. 

If we removed these functions, we would break Python code
that uses them. Also note that where applicable, tmpnam_r is
called.

I propose to close this bug report, unless you can point to
*specific* cases where your program found an *actual* bug in
the code.

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

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-08-07 00:27

Message:
Logged In: YES 
user_id=32065

My knowledge of C is rather lacking. However, some cases are
pretty easy to check. For example, here's what my Debian man
pages say about some of the above functions, under the Bugs
subheading:

tempnam: Never use this function. Use tmpfile(3) instead.
tmpnam: Never use this function. Use tmpfile(3) instead.

And it also says tmpfile is part of the POSIX standard, so
using it shouldn't be a problem.

The strcat in getpath.c seems fine since the previous line
checks that the length is less than the allowable max and it
only appends one character.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:16

Message:
Logged In: YES 
user_id=31392

Itamar-- any interest in figuring out which of these is
really a problem?

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

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


From noreply@sourceforge.net  Tue Aug  7 16:51:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 08:51:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught
Message-ID: <E15U98X-0006Zn-00@usw-sf-web1.sourceforge.net>

Bugs item #439992, was opened at 2001-07-10 02:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=439992&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: [win32] KeyboardInterrupt Not Caught

Initial Comment:
The following program, run under unix (FreeBSD 4.3) and Windows 2000 SP2
with the command line:  python test.py

In both cases, running python 2.1.

The program works as expected under unix and IDLE on Windows 2000, but it
does *not* catch the interrupt in the command line version of Win32 python...
i.e., The traceback message appears rather than my "Leaving Dodge..." message.


while 1:
    try:
        x = raw_input().upper()
        print x
    except KeyboardInterrupt:
        print "Leaving Dodge...\n"
        break

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

>Comment By: Tim Peters (tim_one)
Date: 2001-08-07 08:51

Message:
Logged In: YES 
user_id=31435

For posterity, a delightfully confused section of 
MS's "signal" docs:

"""
Note SIGINT is not supported for any Win32 application 
including Windows NT and Windows 95. When a CTRL+C 
interrupt occurs, Win32 operating systems generate a new 
thread to specifically handle that interrupt. This can 
cause a single-thread application such as UNIX, to become 
multithreaded, resulting in unexpected behavior. 
"""

I kid you not.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 06:59

Message:
Logged In: YES 
user_id=6380

Yes, I'm afraid signal handling doesn't always work on
Windows.
I don't know Windows enough to understand how to fix this.

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

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


From noreply@sourceforge.net  Tue Aug  7 17:52:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 09:52:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-448835 ] Python 2.2a1 Under Idle - Generator
Message-ID: <E15UA5n-0000bT-00@usw-sf-web1.sourceforge.net>

Bugs item #448835, was opened at 2001-08-07 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448835&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python 2.2a1 Under Idle - Generator

Initial Comment:
The following program, run under Idle, gives the message below:

        def fib():
            a, b = 0, 1
            while 1:
                yield b
                a, b = b, a+b

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "G:\PYTHON22\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "G:\PYTHON22\Tools\idle\ScriptBinding.py", line 64, in check_module_event
    if not self.tabnanny(filename):
  File "G:\PYTHON22\Tools\idle\ScriptBinding.py", line 72, in tabnanny
    tabnanny.reset_globals()
AttributeError: 'module' object has no attribute 'reset_globals'



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

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


From noreply@sourceforge.net  Tue Aug  7 17:55:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 09:55:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-446049 ] file type is callable but crashes
Message-ID: <E15UA8y-0000eu-00@usw-sf-web1.sourceforge.net>

Bugs item #446049, was opened at 2001-07-30 11:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446049&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: file type is callable but crashes

Initial Comment:
Calling the type of a file object results
in a crash.  More details to follow.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 09:55

Message:
Logged In: YES 
user_id=6380

All fixed in CVS.

typeobject.c:2.22 fixes the object-instantiability (it was
harder than I thought).

fileobject.c:2.116 fixes the 'closed' attribute.

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

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

Message:
Logged In: YES 
user_id=6380

OK, I think I'll remove the object-instantiability then.

I'll also look at why file.closed is always 2 -- probably
because I misdefined the attribute descriptor and there's no
test suite for this.

And yes, this is how dir() is going to work (I think -- it
makes sense since this is how it works for classes too).

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-08-04 09:01

Message:
Logged In: YES 
user_id=11365

I played around a bit with the featureless objects, and they
are cute but hardly necessary, surely?  How would they be
documented?
(I see that they can be dictionary keys, which vaguely
suggests some kind
of application as tokens...?)

I like that you can inherit from object in python though. 
Do you have to be able to instantiate object to be able to
instantiate python-derived subclasses of object in the
current design?  If not I could certainly lose the
featureless objects.  It does seem like a reasonable goal to
avoid making objects which violate their invariants.

BTW, the file object is now (CVS) broken in respect of its 
closed attribute, which seems to be always 2, file open or
closed.
(This is on linux2.2)

Also,  is the fact that dir() turns up nothing on file
objects (which have four attributes) and on instances of
classes inheriting from object (and using __slots__ ) a bug
or just the way dir() is going to work now?

Cheers.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 08:02

Message:
Logged In: YES 
user_id=6380

The direct cause is that the tp_new slot inherited from
'object' creates a file object that is initialized to all
zeros, and the file object's tp_repr slot doesn't anticipate
that.

I can fix the file object in a number of ways (make it work
for uninitialized objects, or add a tp_new slot that
initializes it properly). But I expect that file is not the
only type that is vulnerable to this kind of attack,
especially 3rd party types that adopt
PyObject_GenericGetAttr() but don't define their own tp_new
are vulnerable.

The alternative would be to remove the default tp_new
implementation from 'object', and add one to dynamically
created types. That would mean you couldn't call object() to
get a featureless object, which is currently supported and
even tested in test_descr.py.

Any preferences?

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

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:57

Message:
Logged In: YES 
user_id=11365

Python 2.2a1 (#2, Jul 26 2001, 11:50:01) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> f = open('README')
>>> type(f)()
Segmentation fault (core dumped)

Seems to me that it would be nice if FileType
worked like the 'open' builtin.
You could have a 'file' builtin and alias it to open.
Wild speculation: I guess open could be eventually
deprecated.  At which point you could safely do 
from os import *  ;-)


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

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


From noreply@sourceforge.net  Tue Aug  7 18:20:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:20:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-448835 ] Python 2.2a1 Under Idle - Generator
Message-ID: <E15UAWy-0001Pf-00@usw-sf-web2.sourceforge.net>

Bugs item #448835, was opened at 2001-08-07 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448835&group_id=5470

>Category: Python Library
>Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.2a1 Under Idle - Generator

Initial Comment:
The following program, run under Idle, gives the message below:

        def fib():
            a, b = 0, 1
            while 1:
                yield b
                a, b = b, a+b

>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "G:\PYTHON22\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "G:\PYTHON22\Tools\idle\ScriptBinding.py", line 64, in check_module_event
    if not self.tabnanny(filename):
  File "G:\PYTHON22\Tools\idle\ScriptBinding.py", line 72, in tabnanny
    tabnanny.reset_globals()
AttributeError: 'module' object has no attribute 'reset_globals'



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:20

Message:
Logged In: YES 
user_id=6380

Thanks for reporting this.  Turns out IDLE was using some
internal APIs of tabnanny that were changed by a recent
conversion to use the new  generator-based tokenizer API. 
It's fixed in CVS now!


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

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


From noreply@sourceforge.net  Tue Aug  7 18:20:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:20:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-440351 ] saxutils.escape needs to escape "quotes"
Message-ID: <E15UAX8-0001Q7-00@usw-sf-web2.sourceforge.net>

Bugs item #440351, was opened at 2001-07-11 03:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470

Category: XML
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: saxutils.escape needs to escape "quotes"

Initial Comment:
XML attributes containing a value with a double
quote are not properly escaped.  Consider

from xml.sax import saxutils
gen = saxutils.XMLGenerator()
gen.startDocument()
gen.startElement('spam', {'width': '12"'})

This produces

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="12"">

That second line should more likely be

<spam width="12&quot;">

or perhaps use the hex escape, which I think
is '&#23'.  But I'm not an XML guru so don't
trust me on either one!

                               Andrew Dalke
                               dalke@acm.org


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

>Comment By: Andrew Dalke (dalke)
Date: 2001-08-07 10:20

Message:
Logged In: YES 
user_id=190903

So now there are two related functions in that module,

def escape(data, entities={}):
    """Escape &, <, and > in a string of data.

def quoteattr(data, entities={}):
    """Escape and quote an attribute value.

I'm fine with that.  I even think that's correct, since
I see two types of quotings.  What I'm curious about is why
XMLGenerator.startElement and startElementNS should use
'escape' (that is, remain unchanged) as compared to
using 'quoteattr' (the new function)

Here's is the relevant code in starteElement:

        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, escape
(value)))

Here's what I think it should be:

        for (name, value) in attrs.items():
            self._out.write(' %s=%s' % (name, quoteattr
(value)))

(similar change for startElementNS() - characters() remains
unchanged.)

Consider this test case:

from xml.sax import saxutils 
gen = saxutils.XMLGenerator() 
gen.startDocument() 
gen.startElement('spam', {'width': '5\'3"'}) 

With the saxutil module straight out of CVS I get

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="5'3"">

That is not what I expected.  The second line should be

<spam width="5'3&quot;">

Now how do I get proper output using XMLGenerator?  I can't
quote the " myself, since the call to 'quote' escapes the &

>>> gen.startElement('spam', {'width': '5\'3&quot;'})
<spam width="5'3&amp;quot;">

The only solution is to derive from XMLGenerator to make
it do the right thing.  So why shouldn't the right thing
be in XMLGenerator proper?  Or is there some other way I
can generically convert SAX startElement events to proper
XML?
                    Andrew
                    dalke@dalkescientific.com


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

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

Message:
Logged In: YES 
user_id=3066

Fixed, but not in the way requested.  ;-)

I've added a new function to the saxutils module,
quoteattr().  It prepares an attribute value for inclusion
as part of markup by doing "just enough" escaping of quote
characters, and supplies the proper quote characters for the
escaping it actually did.

The addition was checked in as Lib/xml/sax/saxutils.py
revision 1.15, with corresponding documentation and test
updates.

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

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


From noreply@sourceforge.net  Tue Aug  7 18:32:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:32:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-444201 ] Add Py-compile prefixes for getset
Message-ID: <E15UAim-0001Lr-00@usw-sf-web3.sourceforge.net>

Bugs item #444201, was opened at 2001-07-24 11:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444201&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Add Py-compile prefixes for getset

Initial Comment:
The getset structure should have a Py-prefixed name.
Ditto for structmember.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:32

Message:
Logged In: YES 
user_id=6380

I think fixing this is not important.

The names affected here are structure tags and typedefs;
Python defines lots of those without proper Py prefixes, for
example a whole series of typedefs starting with 'unaryfunc'
in object.h.

If this was a problem we would have heard about it by now.

So I'm closing this with a "won't fix" resolution.

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

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


From noreply@sourceforge.net  Tue Aug  7 18:35:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:35:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-446874 ] 2.2a1: constructors have no docstring
Message-ID: <E15UAlI-0001md-00@usw-sf-web3.sourceforge.net>

Bugs item #446874, was opened at 2001-08-01 10:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446874&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: constructors have no docstring

Initial Comment:
In 2.2a1 the constructors of the builtin types don't 
have docstrings:

>>> list.__init__
<slot wrapper '__init__' of 'list' objects>
>>> list.__init__.__doc__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'wrapper_descriptor' object has no 
attribute '__doc__'

If this can't be fixed, the documentation for the 
constructor arguments should be part of the docstring 
for the type object as it's done for list, but not for 
dictionary:
>>> print list.__doc__
list() -> new list
list(sequence) -> new list initialized from sequence's 
items
>>> print dictionary.__doc__
dictionary type

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:35

Message:
Logged In: YES 
user_id=6380

Closing this, because the main complaint has been fixed.
I'll fix the docstring of dictionary when I fix the
constructor (thjere's a separate bug report open for that
anyway).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-01 13:35

Message:
Logged In: YES 
user_id=6380

Good catch!  Turns out wrapper descriptors do have
docstrings (albeit rather generic ones), but the necessary
things to extract these were omitted.  I've fixed this in
CVS now.

I'll fix the dictionary docstring when I've decided on the
signature.


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

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


From noreply@sourceforge.net  Tue Aug  7 18:37:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:37:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-443762 ] dictionary type ignores argument list
Message-ID: <E15UAn7-0002Rf-00@usw-sf-web1.sourceforge.net>

Bugs item #443762, was opened at 2001-07-23 04:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443762&group_id=5470

Category: type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Guido van Rossum (gvanrossum)
Summary: dictionary type ignores argument list

Initial Comment:
In 2.2a1 the dictionary type object completely ignores 
its argument list when constructing a new dictionary. 
It always returns an empty dictionary no matter what 
arguments are specified.

Either: it should check that it has been called with 
no arguments.

Or: it should take some arguments and do something 
useful with them.

I would suggest that the following arguments would be 
useful:
dictionary() should return a new empty dictionary.
dictionary(d) where d is a dictionary should return a 
copy of the original dictionary.
dictionary(k1=v1, k2=v2, k3=v3, ...) should return a 
dictionary with keys k1, k2, k3, ... and corresponding 
values.
dictionary(kvlist) where kvlist is a list of key, 
value tuples should build a dictionary from the key 
value pairs (effectively this is the inverse of d.items
()).
dictionary(kseq, vseq) should do the same as dictionary
(zip(kseq, vseq)) i.e. create a dictionary initialised 
with corresponding elements from each list as key and 
value.
Any other arguments to dictionary should be rejected.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:37

Message:
Logged In: YES 
user_id=6380

Well, that would be a very generous API -- probably too
generous. I'm tempted to allow only a single argument with a
mapping interface -- that would be more in line with how
tuple() and list() work.  Let this also be a reminder for me
to fix the docstring when I fix the constructor.

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

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


From noreply@sourceforge.net  Tue Aug  7 18:49:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:49:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-442734 ] 2.2a1: New style classes and pydoc
Message-ID: <E15UAzJ-0002cE-00@usw-sf-web2.sourceforge.net>

Bugs item #442734, was opened at 2001-07-19 05:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442734&group_id=5470

>Category: type/class unification
>Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: New style classes and pydoc

Initial Comment:
pydoc (and the new builtin function help) don't
find new style classes in modules:

File test.py:
----
class foo:
   pass

class bar(object):
   pass
----

Interactive session:
>>> import test
>>> help(test)
Help on module test:

NAME
    test

FILE
    /data/home/walter/test.py

CLASSES
    foo
    
    class foo

DATA
    __file__ = 'test.py'
    __name__ = 'test'



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 06:06

Message:
Logged In: YES 
user_id=6380

Yup, inspect needs to be taught a lesson.

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

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


From noreply@sourceforge.net  Tue Aug  7 18:52:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:52:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn
Message-ID: <E15UB23-0002fJ-00@usw-sf-web2.sourceforge.net>

Bugs item #417845, was opened at 2001-04-21 08:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Python 2.1: SocketServer.ThreadingMixIn

Initial Comment:
SocketServer.ThreadingMixIn does not work properly
since it tries to close the socket of a request two
times.

Workaround for using SocketServer.ThreadingMixIn under
Python 2.1:

class MyThreadingHTTPServer(
  SocketServer.ThreadingMixIn,
  MyHTTPServer
):
  def close_request(self, request):
    pass



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:52

Message:
Logged In: YES 
user_id=6380

Note that closing a socket more than once is not a problem
(the problem reported had to do with the socket being closed
too early, not with it being closed twice).

I'm closing this bug report -- I don't want to revisit this
again in 2.2.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-18 06:56

Message:
Logged In: YES 
user_id=6380

You can close a socket more than once, so it's easy to write
code that works under either assumption.

Since calling a different method is a feature change, we
really can't make this change in 2.1.1.

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

Comment By: Stian Soiland (stain)
Date: 2001-07-18 06:36

Message:
Logged In: YES 
user_id=25921

By waiting for 2.2 for this simple patch even more future
code would break. The programmer would need to write 
seperate code for 2.0, 2.1 and 2.2. Why should we want 
that?

It should not take much time reviewing these 6 lines
of change. Anyone else care to comment?

(This message quoted in posting on comp.lang.python)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-17 07:30

Message:
Logged In: YES 
user_id=6380

I have absolutely no time to review this right now.

This won't be fixed in 2.1.x; I'll look into making that
change for 2.2 at some point.

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

Comment By: Stian Soiland (stain)
Date: 2001-07-13 14:51

Message:
Logged In: YES 
user_id=25921

I don't think it's a good idea to let closing the request be
the handler's responsibility. It's better to let the ThreadingMixIn
do it:

stain@zoidberg:~$ diff -u SocketServer-cvs-1.24.2.1.py SocketServer.py
--- SocketServer-cvs-1.24.2.1.py        Fri Jul 13 23:20:26 2001
+++ SocketServer.py     Fri Jul 13 23:34:02 2001
@@ -451,8 +451,10 @@
     def process_request(self, request, client_address):
         """Start a new thread to process the request."""
         import threading
-        t = threading.Thread(target = self.finish_request,
-                             args = (request, client_address))
+        # Call the BaseServers process_request to close the
+        # socket after finally_request.
+        t = threading.Thread(target = BaseServer.process_request,
+                             args = (self, request, client_address))
         t.start()

In my eyes this is the best, making the overriden process_request
behaving like the original process_request. This would make
the difference between Threading-servers and other servers
smaller. 

If it looks bad with BaseServer-references inside 
ThreadingMixIn, what about a method of ThreadingMixIn 
named __process_request with the same code as
BaseServer.process_request?

-- 
Stian Soiland

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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-07-11 14:45

Message:
Logged In: YES 
user_id=7887

Ohh, I'm sorry. I've read comments the other way around. The
last comment seemed to be the one at bottom (as usual), then
it looked like it was not definetly fixed. I'll checkout the
fix from cvs.

Thanks!


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-11 14:22

Message:
Logged In: YES 
user_id=6380

Gustavo, yes it's fixed in CVS (just read on and you;ll see
my announcement).  We're going to release a bugfix update
release for Python 2.1, Python 2.1.1 soon, and it will be in
that release too.

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

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-07-11 14:19

Message:
Logged In: YES 
user_id=7887

Just wondering, is this bug fixed somewhere (cvs, etc)??
Python 2.1 + SOAP.py seem to have this problem, when using
the ThreadingTCPServer.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-10 06:59

Message:
Logged In: YES 
user_id=6380

Yes, the thread is responsible for calling
self.close_request() in self.finish_request(). (Although if
you just rely on reference counting, it should go away all
by itself too.)

I don't read the newsgroup frequently, but you can try email
if you have more problems.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-10 05:47

Message:
Logged In: NO 

I tried the fix and it seems to work. I'm wondering if the
thread is responsible for calling self.close_request() in
self.finish_request?

Note:
Can we discuss it in news:comp.lang.python? I hate that web
interface with Cookies! That's the reason why I was too lazy
to login when submitting this bug report.

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

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

Message:
Logged In: YES 
user_id=6380

I've developed a proper fix for this, I hope.  Check out the
latest SocketServer.py from the CVS tree.

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-07-02 09:05

Message:
Logged In: YES 
user_id=198402

There is still a problem with your solution, Mr glchapman: 
you make a copy to ensure that the server won't close the 
copy of the socket that is used in the child thread. Right. 
But WHO will close this very copy then?

The thread still has to close it if one wants to 
be "clean". So as long as the child thread must close its 
copy in the threading case, why not make it a thumb rule? 
Why should we bother about  closing anything in the main 
thread? I still think the solution that I provide is best: 
make the request handler always responsible for closing the 
socket from which the request comes.

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

Comment By: Greg Chapman (glchapman)
Date: 2001-06-29 08:49

Message:
Logged In: YES 
user_id=86307

Since the request socket object is only a lightweight 
wrapper around the real socket, why not simply pass 
request.dup() to the new thread?  Then the server's call to 
close_request affects only its copy of request, not the 
copy being used in the thread.  For example, the following 
change to ThreadingMixIn fixed this bug for me in a (very 
simple) test program:

    def process_request(self, request, client_address):
        """Start a new thread to process the request."""
        import threading
        t = threading.Thread(target = self.finish_request,
                             args = (request.dup(), 
client_address))
        t.start()



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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-28 05:20

Message:
Logged In: YES 
user_id=198402

I have now started a project here concerning a SOCKS proxy 
written in python (PySocks). It is aimed mostly at people 
who use a windows box to share their internet connection 
and uses the threading server from the SocketServer module.

So it becomes VERY important to me to know of what will be 
done about this bug, in the next release/patch of Python 
library.

Could Mr Guido Vanrossum tell us about it? As for now I am 
forced to provide my patched version of SocketServer.py 
with my releases, what is not quite satisfactory. 
SocketServer is provided in the python distribution, so I'd 
rather tell "there is a patch for python..."

Well... In fact I forgot to put it in my first release, but 
I'll correct this this evening :)

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-20 12:06

Message:
Logged In: YES 
user_id=198402

Well I was wrong. We do need a "try" block to ensure the 
request is always correctly closed:

    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        try:
            self.RequestHandlerClass(request, 
client_address, self)
        finally:
            self.close_request(request)

This works better.

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 09:09

Message:
Logged In: YES 
user_id=198402

I forgot to tell: I can not test if it does not break the 
forking server. I only have a windows platform available 
for now, and forking doesn't work in the python/win32 
environment for now as far as I know.

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-13 08:51

Message:
Logged In: YES 
user_id=198402

What I propose can be applied without any compatibility 
issue.

I have tried something that seems to work, at least under 
windows (but it does need to be more fully tested though). 
Only 2 small modifications are required:

-1- In BaseServer, modification of the last line of 
handle_request:
<PRE>
    def handle_request(self):
        """Handle one request, possibly blocking."""
        #import time
        try:
            request, client_address = self.get_request()
        except socket.error:
            return
        if self.verify_request(request, client_address):
            try:
                print 'handle 1'
                self.process_request(request, 
client_address)
                print 'handle 2'
            except:
                self.handle_error(request, client_address)
                self.close_request(request)

</PRE>
Note that only the indentation of the last has been 
modified so that the close_request is executed only if an 
exception occur.

Still we need to close the request after it had been 
processed, so here comes the second modification:
-2- Still in BaseServer:
<PRE>
    def finish_request(self, request, client_address):
        """Finish one request by instantiating 
RequestHandlerClass."""
        self.RequestHandlerClass(request, client_address, 
self)
        self.close_request(request)
</PRE>

There is already a try/except block in handle_request, so I 
thought it was not mandatory here to ensure the request was 
always closed.

Oh... I don't know how &lt;PRE&gt; tags are supported by 
the bugtracking system of sourceforge, so the samples I 
give may not appear as I want. This is quite a problem with 
python :/

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-12 15:46

Message:
Logged In: YES 
user_id=80200

hi there mr xlagraula,

yes, it would be a lot simpler... _if_ it wasn't
for the fact that this code is likely to already
be quite extensively used.  a possible 'upgrade'
path could be done by providing a... RequestHandler2
class, or some-such.

it would be neater to do this, or similar:
for t in self.thread_list:
    t.join(timeout=0.1)

which would join all threads, or you do if
stopped(), close_request.  i looked into
threads a bit more: join has a timeout,
and there is a stopped-detection function.

easy :)

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

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-05-12 14:18

Message:
Logged In: YES 
user_id=198402

Another solution could be to modify the behaviour of the 
server so that it would be the responsibility of 
the "child" thread/process to close the socket (except for 
the forking/threading error cases). Wouldn't it be simplier 
than child process tracking and thread tracking?

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-04 04:17

Message:
Logged In: YES 
user_id=80200

okay.  the forkingmixin code does a fork, records how many
children there are, and waits for one of them to exit,
before
proceeding - in particular, before proceeding to close
the request, etc.

... so why is not something similar done in ThreadingMixIn?

this kinda- tells me that thread-tracking is really needed,
in a similar way to that in forkingmixin.

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

Comment By: Gregory P. Smith (greg)
Date: 2001-05-03 16:26

Message:
Logged In: YES 
user_id=413

Just a note of another casualty of this bug: I had to add
the mentioned dummy close_request method hack to our own
ThreadingMixIn class in mojo nation (in the sourceforge
mojonation project's evil module, see the
common/MojoNationHTTPServer.py file).  Without it, python
2.1 would always raise an exception in the request handler
as soon as it tried to call self.connection.makefile()
because self.connection had apparently already been closed! 
(its fd was always -1)


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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-05-02 01:41

Message:
Logged In: YES 
user_id=80200

hi there mr jrielh,

thank you very much for the details.  what i am having a
little difficulty with is, what's the difference between
this and python 2.0 SocketServer.py?

more specifically, i'm looking at python 2.0 SocketServer.py
and, whilst i'm not a Threads expert, i see a t.start() but
no t.join().  i've been looking at the Queue example code in
the test method of threads.py, and start() is called on
every thread, followed by join() on every thread.  join
waits for the thread to finish, yes?

so... if that's the case, then python 2.0 SocketServer.py
should suffer from
exactly the same behaviour, yes?  unless python behaves
ever-so-slightly differently (timing issues?) when you have
an extra base class like this,
with the consequence that close_request() is more likely to
be called
before ThreadingMixIn.process_request().

?

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

Comment By: Jon Riehl (jriehl)
Date: 2001-05-01 14:20

Message:
Logged In: YES 
user_id=22448

This is related to bug #419873.
The problem is not specifically in the ThreadingMixin
specifically, but where BaseServer calls close_request()
after calling process_request().  In the threading mixin,
process_request() spins the thread and returns, causing the
request socket to be invalidated while the thread is still
running.  The fix given above will keep the socket valid
while the thread is running, but may cause the socket to not
close properly (my threads generally close the socket when
they are done anyway.)

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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 05:41

Message:
Logged In: YES 
user_id=80200

follow-up.  i took a look at the differences between
SocketServer.py
in 2.0 and 2.1.  there is one small change by guido to the
ThreadingMixIn.process_request() function that calls
self.server_close() instead of explicitly calling
self.socket.close(),
where TCPServer.server_close() calls self.socket.close().

if mr anonymous (hi!) has over-ridden server_close() and
explicitly closes the *request* socket, then of course the
socket will get closed twice.

the rest of the code-mods is a straightforward code-shuffle
moving code from TCPServer into BaseServer: from
examining the diff, i really don't see how bypassing
close_request(), as shown above with the Workaround
in the original bug-report, will help: that will in fact
cause the request _never_ to be closed!

the rest of this report is part of an email exchange with
guido, quoted here:

"the bug-report doesn't state whether python 2.0 worked and
2.1 didn't:
it also doesn't give enough info.

for all we know, he's calling close_request() himself or
request.close()
directly somewhere in his code, and hasn't told anybody,
which
is why he has to over-ride close_request() and tell it to do
nothing.
or he's closing the socket in the HandlerClass, in finish(),
or
something.

we just don't know.

either that, or his HandlerClass creates a socket once and
only
once, with the result that close_request() closes the one
socket, and he's _completely_ stuffed, then :)"



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

Comment By: Luke Kenneth Casson Leighton (lkcl)
Date: 2001-04-26 04:11

Message:
Logged In: YES 
user_id=80200

hi there,

i'm the person who wrote the BaseServer class.  guido
contacted me about it: could you please send me or post here
a working test example that demonstrates the problem.

i assume, but you do not state, that you have tested your
MyHTTPServer with python 2.0, please let us know, here, if
that is a correct assumption.

thanks!

luke

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

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


From noreply@sourceforge.net  Tue Aug  7 18:53:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 10:53:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-448153 ] Dictionary iterators break old code
Message-ID: <E15UB2o-0002gX-00@usw-sf-web2.sourceforge.net>

Bugs item #448153, was opened at 2001-08-05 06:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448153&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin v. Lіwis (loewis)
Assigned to: Martin v. Lіwis (loewis)
Summary: Dictionary iterators break old code

Initial Comment:
With the introduction of dictionary iterators, 
iteration over UserDict specializations may silently 
break existing code. The attached code is a 
simplification of the xml.dom.NamedNodeMap class, 
which provides iteration over the values using a 
well-defined order, which is implemented in 
__getitem__. In Python 2.2a1, __getitem__ is not 
called anymore, thus the code breaks.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 10:53

Message:
Logged In: YES 
user_id=6380

Closed by adding an IterableUserDict to UserDict.py.


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

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-06 23:16

Message:
Logged In: YES 
user_id=21627

I've already fixed it in PyXML, although the only way I 
could find to fix it was to add an __iter__; I cannot take 
away the __getitem__ since the code has to work in older 
Python versions.

The solution I would prefer to see is that UserDict offers 
a second class, say IterableUserDict, which would be for 
educational purposes only; anybody who really wants a 
dictionary that you can iterate over should inherit from 
dictionary.

That also raises the question whether UserDict 
applications in the standard library should be changed to 
inherit from dictionary. The major incompatibility I can 
see with doing so is that the .data member goes away.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 13:59

Message:
Logged In: YES 
user_id=6380

Aaaaaaargh!!!!!!!

You mean somebody wrote a subclass of UserDict that attempts
to behave like a sequence by checking the type of the
__getitem__ argument??????????

Yuck!!!!!!!!!!!!!!!

You XML weenies are sickos. :-)

Now that I've got that out of the way :-),

Short of totally dropping dictionary iterators, the only
solution I can see it to remove the __iter__ method of
UserDict. That is backwards compatible, but it removes the
ability to iterate over UserDict instances (except for the
sick ones :-), thus making UserDict less like a dictionary.

But since UserDict is likely to become deprecated anyway in
favor of subclassing from the 'dictionary' built-in type,
this solution seems acceptable -- but only if this trick is
also in use outside the XML code.  I would prefer to see the
XML code fixed, since it can now properly define __iter__ to
iterate over whatever it wants to in any sequence it would
like. :-)


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

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


From noreply@sourceforge.net  Tue Aug  7 20:19:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:19:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-428555 ] IDLE crashes when running Tkinter code
Message-ID: <E15UCOT-00060P-00@usw-sf-web3.sourceforge.net>

Bugs item #428555, was opened at 2001-05-29 23:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=428555&group_id=5470

>Category: IDLE
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: IDLE crashes when running Tkinter code

Initial Comment:
On Windows 2000 (havent tested other platforms) IDLE 
will crash if i run the following code (ditto for 
PythonWin)

from Tkinter import *

root = Tk()
img = PhotoImage(root,file="somefile.gif")
# the error here is that i used root as the name





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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:19

Message:
Logged In: YES 
user_id=6380

Sorry, it's best not to use IDLE to run Tkinter code.

I'm closing this bug report with a "won't fix". It will
actually eventually be fixed, but the fix is far in the
future.

This is in fact not platform specific.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-31 19:58

Message:
Logged In: NO 

I get the same problem. Idle locks up when I close the 
window created by this application. 

I'm using Python 2.1 on Win98SE with IDLE 0.8 and Tcl 8.3

Happens every time for me. I can't get IDLE back to the >>> 
prompt when I close the window.

HELP!
----
from Tkinter import *

def testwindow(mess):
    root = Tk()

    w = Label(root, text="[ %s ]" % mess)
    w.pack()

    root.mainloop()

testwindow("Hello World")
----

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

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


From noreply@sourceforge.net  Tue Aug  7 20:21:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:21:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-440351 ] saxutils.escape needs to escape "quotes"
Message-ID: <E15UCPg-0006hq-00@usw-sf-web1.sourceforge.net>

Bugs item #440351, was opened at 2001-07-11 03:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470

Category: XML
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: saxutils.escape needs to escape "quotes"

Initial Comment:
XML attributes containing a value with a double
quote are not properly escaped.  Consider

from xml.sax import saxutils
gen = saxutils.XMLGenerator()
gen.startDocument()
gen.startElement('spam', {'width': '12"'})

This produces

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="12"">

That second line should more likely be

<spam width="12&quot;">

or perhaps use the hex escape, which I think
is '&#23'.  But I'm not an XML guru so don't
trust me on either one!

                               Andrew Dalke
                               dalke@acm.org


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-07 12:21

Message:
Logged In: YES 
user_id=3066

Andrew, it should do the write thing.  I'll check that in
now... Lib/xml/sax/saxutils.py revision 1.16 should do the
trick.

Ok, I think that covers the bases.  I've added a similar
test case, so we should be OK with regard to regression.

Thanks!

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

Comment By: Andrew Dalke (dalke)
Date: 2001-08-07 10:20

Message:
Logged In: YES 
user_id=190903

So now there are two related functions in that module,

def escape(data, entities={}):
    """Escape &, <, and > in a string of data.

def quoteattr(data, entities={}):
    """Escape and quote an attribute value.

I'm fine with that.  I even think that's correct, since
I see two types of quotings.  What I'm curious about is why
XMLGenerator.startElement and startElementNS should use
'escape' (that is, remain unchanged) as compared to
using 'quoteattr' (the new function)

Here's is the relevant code in starteElement:

        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, escape
(value)))

Here's what I think it should be:

        for (name, value) in attrs.items():
            self._out.write(' %s=%s' % (name, quoteattr
(value)))

(similar change for startElementNS() - characters() remains
unchanged.)

Consider this test case:

from xml.sax import saxutils 
gen = saxutils.XMLGenerator() 
gen.startDocument() 
gen.startElement('spam', {'width': '5\'3"'}) 

With the saxutil module straight out of CVS I get

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="5'3"">

That is not what I expected.  The second line should be

<spam width="5'3&quot;">

Now how do I get proper output using XMLGenerator?  I can't
quote the " myself, since the call to 'quote' escapes the &

>>> gen.startElement('spam', {'width': '5\'3&quot;'})
<spam width="5'3&amp;quot;">

The only solution is to derive from XMLGenerator to make
it do the right thing.  So why shouldn't the right thing
be in XMLGenerator proper?  Or is there some other way I
can generically convert SAX startElement events to proper
XML?
                    Andrew
                    dalke@dalkescientific.com


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

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

Message:
Logged In: YES 
user_id=3066

Fixed, but not in the way requested.  ;-)

I've added a new function to the saxutils module,
quoteattr().  It prepares an attribute value for inclusion
as part of markup by doing "just enough" escaping of quote
characters, and supplies the proper quote characters for the
escaping it actually did.

The addition was checked in as Lib/xml/sax/saxutils.py
revision 1.15, with corresponding documentation and test
updates.

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

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


From noreply@sourceforge.net  Tue Aug  7 20:23:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:23:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-442998 ] 2.2a1: compiler warnings
Message-ID: <E15UCRt-000635-00@usw-sf-web3.sourceforge.net>

Bugs item #442998, was opened at 2001-07-20 01:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442998&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: compiler warnings

Initial Comment:
I've done a port to OpenVMS. Here are some compiler
warnings:

-----
};
^
%CC-I-TRAILCOMMA, Trailing comma found in enumerator
list. at line number 482 in file CEVAL.C

-----
There are lots of warnings in TYPEOBJECT.C like:

RICHCMP_WRAPPER(lt, Py_LT);
..........................^
%CC-I-EXTRASEMI, Extraneous semicolon.
at line number 1707 in file TYPEOBJECT.C

RICHCMP_WRAPPER(le, Py_LE);
..........................^
%CC-I-EXTRASEMI, Extraneous semicolon.
at line number 1708 in file TYPEOBJECT.C

and:

SLOT1(sq_concat, add, PyObject *, O);
....................................^
%CC-I-EXTRASEMI, Extraneous semicolon.
at line number 1956 in file TYPEOBJECT.C

SLOT1(sq_repeat, mul, int, i);
.............................^
%CC-I-EXTRASEMI, Extraneous semicolon.
at line number 1957 in file TYPEOBJECT.C

and:
		ADD(sq->sq_length, tab_len);
................^
%CC-W-PTRMISMATCH, In this statement, the referenced
type of the pointer value "sq->sq_length" is "function
(pointer to struct _object) returning int", which is
not compatible with "void".
at line number 1842 in file TYPEOBJECT.C

		ADD(sq->sq_concat, tab_add);
................^
%CC-W-PTRMISMATCH, In this statement, the referenced
type of the pointer value "sq->sq_concat" is "function
(pointer to struct _object, pointer to struct _object)
returning pointer to struct _object", which is not
compatible with "void".
at line number 1843 in file TYPEOBJECT.C

		add_staticmethodwrappers(type, tab_new, 
type->tp_new);
.......................................................
.^
%CC-W-PTRMISMATCH, In this statement, the referenced
type of the pointer value "type->tp_new" is "function
(pointer to struct _typeobject, pointer to struct
_object, pointer to struct _object) returning pointer
to struct _object",which is not compatible with "void".
at line number 1917 in file TYPEOBJECT.C

There are 100+ warnings which I don't include all, OK?

-----
4 times messages like this in UNICODEOBJECT.C:

            *p++ = hexdigit[(ch >> 28) & 0xf];
.............................^
%CC-I-RIGHTSHIFTOVR, In this statement, the right shift
count "28" is greater than or equal to the size of the
unpromoted operand "ch".
at line number 1448 in file UNICODEOBJECT.C

-----
If you need specific values from my CONFIG.H, please
let me know.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:23

Message:
Logged In: YES 
user_id=6380

The ones I promised to fix have all been addressed.
Closing this report to make room for new ones.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-20 09:32

Message:
Logged In: YES 
user_id=6380

I'm sorry, but I don't want to fix most of these.

Trailing commas in lists are legal C, and esthetics and easy
extensibility tell me that it's better to keep them.

The extraneous semicolons after RICHCMP_WRAPPER() are also
legal in C, and I need them so the Emacs auto-indent mode
doesn't screw up.

I will add (void *) casts to the function arguments in the
ADD() macro and the add_staticmethodwrappers() call.

I think I can add an #ifdef to the Unicode fragment.


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

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


From noreply@sourceforge.net  Tue Aug  7 20:26:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:26:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E15UCUY-00065W-00@usw-sf-web3.sourceforge.net>

Bugs item #210665, was opened at 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Closed
>Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:26

Message:
Logged In: YES 
user_id=6380

Closing this for lack of progress.

If someone figures out what to do with threads on HPUX-11,
please submit a fresh *patch*.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 10:31

Message:
Logged In: YES 
user_id=6380

Alas, not.  Those binaries don't have threads enabled.

HP doesn't know how to do it either.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:37

Message:
Logged In: YES 
user_id=6380

For all of those in search for an easy solution:

HP makes binaries available.  See

http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/

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

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-19 03:07

Message:
Logged In: YES 
user_id=200117

I have now applied the new patch file 'python-2.1.patch' 
available at: ftp://ftp.thewrittenword.com/outgoing/pub

I can now successfully build Python 2.1 with threads 
enabled, on HP-UX 11. 



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

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-14 01:20

Message:
Logged In: YES 
user_id=200117

I applied the patch from thewrittenword's site, but when I 
ran autoconf it generated a corrupt configure script.

There problem occurs around lines 3895-3906:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1
fi
 LDLAST=-threads;;
	    esac
	fi
    fi
fi

The case statement has been trashed by the extra 'fi' 
token. I tried manually editing it like this:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1) LDLAST=-threads;;
	    esac
	fi
    fi
fi

But it still fails with an 'else' not matched at line 3422.
I can't see where the extra 'fi' should go.




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

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

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

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 20:27:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:27:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-230010 ] Nasty case for comparison performance
Message-ID: <E15UCVu-00066U-00@usw-sf-web3.sourceforge.net>

Bugs item #230010, was opened at 2001-01-24 21:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230010&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Nasty case for comparison performance

Initial Comment:
Test case:

def timeeq(x, y):
    from time import clock
    import sys
    assert len(x) == len(y)
    print "comparing dicts of len", len(x), "...",
    sys.stdout.flush()
    s = clock()
    result = x == y
    f = clock()
    print round(f-s, 1), "seconds"
    sys.stdout.flush()

d = {}
e = {}
timeeq(d, e)
d[0] = d
e[0] = e
timeeq(d, e)
d[1] = d
e[1] = e
timeeq(d, e)
d[2] = d
e[2] = e
timeeq(d, e)

Under current CVS, output is:

comparing dicts of len 0 ... 0.0 seconds
comparing dicts of len 1 ... 0.0 seconds
comparing dicts of len 2 ... 6.5 seconds
comparing dicts of len 3 ...

There's no sign that the 3-element dict compare will ever terminate (killed it after 15 minutes on a quiet machine).

This is actually a huge improvement over Python 2.0, though!  There it spins (seemingly) forever comparing the 2-element dicts.

Note that I put this at priority 1 (lowest).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:27

Message:
Logged In: YES 
user_id=6380

Closing this with a won't fix resolution.
There's nothing I can do.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-01-28 04:16

Message:
It is really good give me one send to leebinhao@hotmail.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230010&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 20:28:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:28:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-230029 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E15UCWU-00067K-00@usw-sf-web3.sourceforge.net>

Bugs item #230029, was opened at 2001-01-25 02:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230029&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Closed
>Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: [HP-UX] Python chokes on pthread_mutex_init

Initial Comment:
On an HPUX 11.00:  During "make intstall":

./install-sh -c -m 644 ./Lib/curses/__init__.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/ascii.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/has_key.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/textpad.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/curses/wrapper.py /opt/tmp/Python/lib/python2.0/curses
./install-sh -c -m 644 ./Lib/plat-hp-uxB/core /opt/tmp/Python/lib/python2.0/plat-hp-uxB
./install-sh -c -m 755 ./Lib/plat-hp-uxB/regen /opt/tmp/Python/lib/python2.0/plat-hp-uxB
        ./install-sh -c -m 644 ./LICENSE /opt/tmp/Python/lib/python2.0/LICENSE.txt
        PYTHONPATH=/opt/tmp/Python/lib/python2.0 \
                        ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
sh: 6074 Memory fault(coredump)

----------------------------------------------------------
This fault can be reproduced:

export PYTHONPATH=/opt/tmp/Python/lib/python2.0

/opt/stephie/Python-2.0 > ./python -tt /opt/tmp/Python/lib/python2.0/compileall.py /opt/tmp/Python/lib/python2.0
pthread_mutex_init: Invalid argument
Memory fault(coredump)



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:28

Message:
Logged In: YES 
user_id=6380

Closing this out of desperation.
There's been no movement for this in ages.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-04 13:07

Message:
Logged In: YES 
user_id=31435

Harri, there are always HP-UX thread bug reports open, and 
against every release of Python.  A few HP-UX users submit 
patches, other HP-UX users argue about them, Guido takes 
his best guess and checks one or more of the patches in.  
It never solves anything, though -- come the next release, 
we get a fresh batch of HP-UX thread complaints.

It appears that no Python developer uses HP-UX, so we're 
never going to solve this.  If you think you can, please 
submit a patch.  Note that 2.1 final is scheduled for 
release a week from Friday (13-Apr-2001), so there isn't 
much time for this.

----------------------------------------------------------------------

Comment By: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:16

Message:
Logged In: YES 
user_id=77088

This bug has been present a long time, I've reported it
myself sometime last year (maybe for Python 2.0 beta, and
for Python 1.6).  

Basically, autoconf gets wrong the required threading
library. For HP-UX 10.20 -lcma is the correct one I believe.

For HP-UX 11.x -lpthread should be used.

#210665 has a fairly long thread on this.  This item
(#230029) are just the symptoms the bug shows when present.

Well, as I have access both to HP-UX 11.00 and HP-UX 10.20
machines, I could help to put this problem to rest for
Python 2.1.

-Harri

PS. As I'm currently logged in I presume you'll get my
coordinates automatically?  Just in case, harri dot pasanen
at trema dot com.









----------------------------------------------------------------------

Comment By: Todd Whiteman (toddw)
Date: 2001-02-26 20:13

Message:
Logged In: YES 
user_id=149041

This works for me on HPUX-11:

Open the Modules/Makefile and change the following line:
LIBS= -lnsl -ldld -lcma
to the following
LIBS= -lnsl -ldld -lpthread -lcl

rm Modules/threadmodule.o
make


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:29

Message:
Assigned to our resident HP-UX fan <wink>.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-01 12:10

Message:
This may be the same bug as #110650 (already closed, but not clear that this was ever actually fixed).

Too bad this was an anonymous report; we can't ask for more information without an email address.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=230029&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 20:40:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:40:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-440351 ] saxutils.escape needs to escape "quotes"
Message-ID: <E15UCiD-0007lZ-00@usw-sf-web1.sourceforge.net>

Bugs item #440351, was opened at 2001-07-11 03:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470

Category: XML
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: saxutils.escape needs to escape "quotes"

Initial Comment:
XML attributes containing a value with a double
quote are not properly escaped.  Consider

from xml.sax import saxutils
gen = saxutils.XMLGenerator()
gen.startDocument()
gen.startElement('spam', {'width': '12"'})

This produces

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="12"">

That second line should more likely be

<spam width="12&quot;">

or perhaps use the hex escape, which I think
is '&#23'.  But I'm not an XML guru so don't
trust me on either one!

                               Andrew Dalke
                               dalke@acm.org


----------------------------------------------------------------------

>Comment By: Andrew Dalke (dalke)
Date: 2001-08-07 12:40

Message:
Logged In: YES 
user_id=190903

I verified the fix and that the regressions
properly test for my expectations.

                    Andrew
                    dalke@dalkescientific.com


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-07 12:21

Message:
Logged In: YES 
user_id=3066

Andrew, it should do the write thing.  I'll check that in
now... Lib/xml/sax/saxutils.py revision 1.16 should do the
trick.

Ok, I think that covers the bases.  I've added a similar
test case, so we should be OK with regard to regression.

Thanks!

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2001-08-07 10:20

Message:
Logged In: YES 
user_id=190903

So now there are two related functions in that module,

def escape(data, entities={}):
    """Escape &, <, and > in a string of data.

def quoteattr(data, entities={}):
    """Escape and quote an attribute value.

I'm fine with that.  I even think that's correct, since
I see two types of quotings.  What I'm curious about is why
XMLGenerator.startElement and startElementNS should use
'escape' (that is, remain unchanged) as compared to
using 'quoteattr' (the new function)

Here's is the relevant code in starteElement:

        for (name, value) in attrs.items():
            self._out.write(' %s="%s"' % (name, escape
(value)))

Here's what I think it should be:

        for (name, value) in attrs.items():
            self._out.write(' %s=%s' % (name, quoteattr
(value)))

(similar change for startElementNS() - characters() remains
unchanged.)

Consider this test case:

from xml.sax import saxutils 
gen = saxutils.XMLGenerator() 
gen.startDocument() 
gen.startElement('spam', {'width': '5\'3"'}) 

With the saxutil module straight out of CVS I get

<?xml version="1.0" encoding="iso-8859-1"?>
<spam width="5'3"">

That is not what I expected.  The second line should be

<spam width="5'3&quot;">

Now how do I get proper output using XMLGenerator?  I can't
quote the " myself, since the call to 'quote' escapes the &

>>> gen.startElement('spam', {'width': '5\'3&quot;'})
<spam width="5'3&amp;quot;">

The only solution is to derive from XMLGenerator to make
it do the right thing.  So why shouldn't the right thing
be in XMLGenerator proper?  Or is there some other way I
can generically convert SAX startElement events to proper
XML?
                    Andrew
                    dalke@dalkescientific.com


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-19 09:11

Message:
Logged In: YES 
user_id=3066

Fixed, but not in the way requested.  ;-)

I've added a new function to the saxutils module,
quoteattr().  It prepares an attribute value for inclusion
as part of markup by doing "just enough" escaping of quote
characters, and supplies the proper quote characters for the
escaping it actually did.

The addition was checked in as Lib/xml/sax/saxutils.py
revision 1.15, with corresponding documentation and test
updates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440351&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 20:49:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:49:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-448546 ] rexec:make_re() should not use pre?
Message-ID: <E15UCrJ-0007Ki-00@usw-sf-web2.sourceforge.net>

Bugs item #448546, was opened at 2001-08-06 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448546&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: rexec:make_re() should not use pre?

Initial Comment:
The rexec module contains a mysterious make_re()
function that seems to hard-code the 're' module as
using 'pre'.  Why is this?  Why can't the standard
'sre' module be used, and why does this module have to
be pre-initialized?

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-07 12:49

Message:
Logged In: YES 
user_id=3066

This is no longer needed (appearantly something magic was
needed earlier, and this may not have been the best
solution).  It is not needed any more, so I've removed it in
revision 1.31.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448546&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 20:59:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 12:59:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E15UD0Z-0007T4-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 21:59:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 13:59:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-448911 ] Empty list as default argument problem
Message-ID: <E15UDwq-0001M5-00@usw-sf-web2.sourceforge.net>

Bugs item #448911, was opened at 2001-08-07 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Empty list as default argument problem

Initial Comment:
To begin, a test case (hopefully mozilla will preserve
the formatting..):

class node:
    def __init__(self, attrs = []):
        self.attrs = attrs

a = node()
b = node()
a.attrs.append("foo")
print b.attrs
This prints ["foo"], where one would expect it to print
[]. Rewriting node.__init__ as follows does the right
thing:

    def __init__(self, attrs = []):
        if not attrs:
            self.attrs = []
        else:
            self.attrs = attrs

It appears that Python allocates the default empty list
argument once and reuses it across multiple
instantiations of the object, so that a and b share
the attrs variable. This is unexpected.

I've tested this on multiple platforms (Linux and IRIX)
and multiple versions of Python (1.5.2 and 2.1.1).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 22:07:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 14:07:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-448911 ] Empty list as default argument problem
Message-ID: <E15UE4j-0001TY-00@usw-sf-web2.sourceforge.net>

Bugs item #448911, was opened at 2001-08-07 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470

>Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Empty list as default argument problem

Initial Comment:
To begin, a test case (hopefully mozilla will preserve
the formatting..):

class node:
    def __init__(self, attrs = []):
        self.attrs = attrs

a = node()
b = node()
a.attrs.append("foo")
print b.attrs
This prints ["foo"], where one would expect it to print
[]. Rewriting node.__init__ as follows does the right
thing:

    def __init__(self, attrs = []):
        if not attrs:
            self.attrs = []
        else:
            self.attrs = attrs

It appears that Python allocates the default empty list
argument once and reuses it across multiple
instantiations of the object, so that a and b share
the attrs variable. This is unexpected.

I've tested this on multiple platforms (Linux and IRIX)
and multiple versions of Python (1.5.2 and 2.1.1).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-07 14:07

Message:
Logged In: YES 
user_id=31435

Not a bug, functioning as designed.

See the FAQ entry

<http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.025.htp>

for pointers to more discussion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 22:13:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 14:13:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-447370 ] typo in urllib2.py
Message-ID: <E15UEAL-00039z-00@usw-sf-web1.sourceforge.net>

Bugs item #447370, was opened at 2001-08-02 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447370&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: typo in urllib2.py

Initial Comment:
in line 662 of urllib2.py the 'o' and 'w' are 
transposed:

passwd = HTTPPassowrdMgr()



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-07 14:13

Message:
Logged In: YES 
user_id=31392

Fixed the typos and one other bug caught by pychecker.  I
wish pychecker was better at reporting only bugs.  The false
positive rate for this module was 96% -- only 3 of 78
warnings were actual bugs.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 18:22

Message:
Logged In: YES 
user_id=6380

Assigned to Jeremy.  There are more typos, e.g. OpenerDirectory instead of OpenerDirector.  Should I paste 
the pychecker output here?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=447370&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 22:14:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 14:14:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-416824 ] Python 2.1 installer freezes on Win 2000
Message-ID: <E15UEAu-0002Jp-00@usw-sf-web2.sourceforge.net>

Bugs item #416824, was opened at 2001-04-17 13:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 installer freezes on Win 2000

Initial Comment:
My aim is to install Python 2.1 on a Windows 2000 
Professionnal (French) workstation.

The windows intaller works well until it show the 
screen where one can choose which parts of the product 
one wants to install (third window).

If one hit the "next" button without touching anything 
else, the installer will definitively freeze. Trying 
to stop it using the pop-up menu in the task bar will 
result in a few seconds pause, followed by an error 
window telling that the 16-bit subsystem has not 
answered in time to the stop request. The possibility 
is then given to kill it, eventually leaving the 16 
bit subsystem unstable.

I tried to download the installer from both the main 
site and sourceforge, to check if it came from a 
corrupted file. Same result.

The workaround is simple: just uncheck at least one of 
the check boxes, click "next", it won't freeze. Now 
click "back", re-check the check boxe, click "next" 
and... tada! It won't freeze neither. Now you can go 
on installing the whole package. Haven't thoroughly 
tested it yet, but seems to be working fine.

This problem is not really serious as one can easily 
bypass it, and as it doesn't involve the langage or 
the interpreter themselves. Nevertheless, it IS a 
bug...

Regards,
  Xavier


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-07 14:14

Message:
Logged In: YES 
user_id=31435

Closed via "Won't Fix" -- there's really nothing we can do 
about Wise 5.0a-generated installers.

Starting with 2.2a2, we're using Wise 8.14 to produce the 
Windows installer.  In my limited testing so far, it works 
much better on Win2K than the old installer (which was 
produced by a version of Wise that came out when Win95 was 
brand new -- seems a miracle it ever worked at all under 
Win2K!).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-30 09:08

Message:
Logged In: NO 

This also happens on Windows ME

----------------------------------------------------------------------

Comment By: Eike Hanus (luckyarts)
Date: 2001-04-26 15:27

Message:
Logged In: YES 
user_id=205479

I was having the same problem on my W2K laptop (Dell 
Latitude LS 128 MB RAM) several times. The workaround 
didn't work for me either. Something else strangely 
happened. When I rebooted the machine and tried once more I 
slipped on the touchpad invoking a double click on the next 
button effectively skipping the critical page and directly 
going to the screen asking where to put the icons. I have 
no idea how that worked but maybe the error also only 
happenes after having the page open for a minimum time.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-25 07:57

Message:
Logged In: YES 
user_id=198402

Well, it is not a bugfix, but a solution is to use the 
ActivePython distribution instead, as suggested by tim_one
(cf. #418156). Even after managing to work around the 
problem of the first distribution (as I've said), I tried 
to install it on my win2k workstation (sheer curiosity) and 
it worked without problem.

It comes as a .msi file, the new standard. You may need to 
download the installer on microsoft.com. Everything is 
explained on the ActiveState web site:
http://www.activestate.com/ASPN/Downloads/ActivePython/

I'll soon have a look at the availability of this msi 
format: if the old version of the Wise Solution installer 
starts to make problems, we might as well start to look for 
a replacement.

--
Xavier

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-04-18 15:30

Message:
Logged In: NO 

In case it helps, I've got a win2k pro workstation, 128MB 
ram, and it also hangs on the same page during the 
installation.  Oh, and the workaround you mentioned did not 
work for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 11:41

Message:
Logged In: YES 
user_id=31435

It's fine that you were logged in as an Administrator.  
Indeed, things probably have the *best* chance of working 
then.

Please note that we didn't write the installer code:  the 
Wise installer is a commercial product, which they kindly 
let Python use for free:

http://www.wisesolutions.com/

We have no access to the source code, either.  So if you 
*do*, for example, find evidence of an uninitialized 
variable, there's nothing we can do about it.  Alas, I 
doubt Wise will do anything about it either, as the version 
of the product we're using is over 5 years old (and looks 
like they stopped supporting it a few years ago).

OTOH, the Windows installer is used many thousands of 
times, and this is the only freeze report we've seen.  If 
we don't see another, the presumption still has to favor 
that there's something flaky about your particular machine.

BTW, I've never tried it on a machine w/ 512Mb of RAM, so 
perhaps that is relevant.  Have tried it on machines w/ 
256Mb.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-18 05:31

Message:
Logged In: YES 
user_id=198402

To answer your question: I was logged using the 
Administrator account ("Administrateur", in fact, on a 
french box). Like most of the time, because many software 
which are not specifically written for NT won't run 
correctly without it. I know this is bad but what else can 
I do?

Anyway I don't have access to another french win2k box. All 
I can do is give you spщcific information about my computer:
- PII 400 - 512Mo of PC133 SDRAM
- Asus MB - P3 BF
- Video: GeForce 256 DDR (Hercules) / Hauppauge WinTV
- Sound: SB Live Player!
- Network: 2 SN3200 (PCI, ethernet 10Mbps, ne2000 
compatible)
- SCSI: Diamond Fireport 40 / CDROM x32 (plextor) / CD 
burner (ricoh MP6200s)
- Win2k french SP1 + IE 5.5
- mysql: latest stable version + MyODBC drivers
- apache: latest stable version + PHP
- naviscope (web proxy/dns cache)
- net vampire: v4.0 beta
- ICQ 2000b
- all drivers were up to date 3 weeks ago.

Still, I believe that those symptoms look either like a 
uninitialized variable or a faulty pointer, such bugs that 
can remain hidden except under very specific "context-
specific" circumstances. (Un)checking one of the check 
boxes, by forcing a value in the variable or by allocating 
a memory block would correct the problem and allow the user 
to go on with the installation.

If I can reproduce the bug this evening, I'll try to see if 
the installer eats all CPU while freezed. Could give a clue 
about what's really happenning. I may also try removing 
256Mo of RAM to verify my "pointer hypothesis" (if it makes 
the bug impossible to reproduce, then it has something to 
do with memory allocation. Crude method but quite useful 
sometimes).

Regards,
  Xavier

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-18 02:47

Message:
Logged In: YES 
user_id=31435

This is the only freeze report we've seen for Win2K.

Did you do something bizarre <wink>?  For example, we've 
had one-of-a-kind reports from people in the past who tried 
to install on NT or Win2K while logged in to a Restricted 
User account.  Were you?  Or were you logged in to an 
Administrator account?  Or were you logged in as something 
in between?

Could you try it on another Win2K (French) box?  We have a 
poor track record when it comes to fixing Microsoft's bugs 
for them, and in the absence of more info I have to assume 
it's a bug unique to the specific box you used.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416824&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 22:14:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 14:14:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-448918 ] docs for mmap module unclear/typo
Message-ID: <E15UEBH-0002K0-00@usw-sf-web2.sourceforge.net>

Bugs item #448918, was opened at 2001-08-07 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448918&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: docs for mmap module unclear/typo

Initial Comment:
For the mmap module docs:

Under both the Windows and Unix constructors is the
sentence:

"If you wish to map an existing Python file object, use
its fileno() method to obtain the correct value for the
fileno parameter"

OK, but what id I want to map an unopened file???? The
working implies that I don't have to use an existing
file object, but doesn't say how to do otherwise.

under the Windows constructor:
"""

mmap(fileno, length[, tagname]) (Windows version) Maps
length bytes from the file specified by the file handle
fileno, and returns a mmap object. If length is 0, the
maximum length of the map will be the current size of
the file when mmap() is called.
"""

This is pretty clear, but under the Unix section:

"""
mmap(fileno, size[, flags, prot]) (Unix version) Maps
length bytes from the file specified by the file handle
fileno, and returns a mmap object.
"""

In the prototype, there is a required parameter called
"size" and in the next sentence, the variable "length"
is used. Are these supposed to be the same? can I use a
0 to indicate the whole file, as I can on Windows?


Note that none of this seems to have changed in the
development version of the docs.

-Chris

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448918&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 22:19:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 14:19:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-418156 ] V2.1 installer not working on NT4 SP5
Message-ID: <E15UEFi-0002O3-00@usw-sf-web2.sourceforge.net>

Bugs item #418156, was opened at 2001-04-23 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470

Category: Windows
>Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 1
Submitted By: Xavier Lagraula (xlagraula)
Assigned to: Tim Peters (tim_one)
Summary: V2.1 installer not working on NT4 SP5

Initial Comment:
Hello.

I have a windows NT server (Nec PowerMate VT, 128Mo 
RAM) with quite a lot of products installed. During 
the installation, I always get a "corrupt installation 
detected" pop-up, whereas the files can correctly be 
extracted from the archive by winzip 8 or winrar 
2.80b2.

The products installed are
- Business Bridge V2.3.16 & V3.0.6 servers (SYSTAR)
- MySQL 3.23.32 server (+ODBC driver)
- Naviscope
- I.I.S. 4.0
- Winzip 8 french
- WinRAR 2.80b2
- Cygwin 1.1
- MS SQL/Server 6.5 client (+ODBC driver)
- MouseWare 9.00.99
- Office 97
- Oracle 7.3.4 & 8i clients (+ODBC drivers)
- UltraEdit 8
- TNG Remote Control Option

I'd like to know if there are any incompatibilities 
between the installer and any of these products, and 
I'd like to be given a manual procedure that would 
allow me to install python on my workstation.

Moreover, seeing that:
- I am not the only one having installation problems 
on windows
- I have had problems every time I have tried to 
install Python 2.1 on windows (both NT and 2000)
- The Python windows installer is a 16 bit technology 
that is not supported anymore if I can believe what 
tim_one told me (see request ID 416824)
My conclusion is that we all should consider using 
another windows installer.

Regards,
  Xavier

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-07 14:19

Message:
Logged In: YES 
user_id=31435

Closed via "Won't Fix" -- there's really nothing we can do 
about Wise 5.0a-generated installers.

Starting with 2.2a2, we're using Wise 8.14 to produce the 
Windows installer.  In my limited testing so far, it works 
much better on NT/Win2K than the old installer (which was 
produced by a version of Wise that came out when Win95 was 
brand new -- seems a miracle it ever worked at all under 
Win2K!).

BTW, every time I suggest someone compute the MD5 checksum, 
their reply contains two things:  (a) an outraged assertion 
that they can't do it since they can't install Python; and, 
(b) the news that they managed to compute it anyway.  
Apparently I give users more credit than they give 
themselves <wink>.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 04:59

Message:
Logged In: YES 
user_id=198402

Oops... Another mistake from a french speaking english: I 
said 'sense' but I meant 'meaning' in the last paragraph.

----------------------------------------------------------------------

Comment By: Xavier Lagraula (xlagraula)
Date: 2001-04-23 03:04

Message:
Logged In: YES 
user_id=198402

OK... Here are the news: I have installed ActiveState 
version without problems. I had to: how the hell could I 
compute a MD5 digest of the Python installer with a Python 
script, if I can't have Python installed, hm?

Anyway the digest proved to be perfectly correct. After 
all, I tried downloading the file for 2 different sources, 
and this was not a copy of the file I used on Win2k (see 
request ID 416824). But computing this digest allowed me to 
find the origin of the problem. I realized that I had saved 
the installer on a remote drive (windows shared directory 
on our file server), when I had to type "V:Python-21.exe" :)

My guess is that the SYSTEM account must have the right to 
read the directory containing the installer, and it was not 
the case. Once copied locally, it seems to work (I didn't 
go through the entire process, though, as I already had 
Python installed before).

I don't know if using the msi format is free or not. 
Another way for M$ to make money with a new mandatory 
installation format? If it's free, then it's the obvious 
choice for a future version of the windows installer. I'll 
try to gather some informations about it.

And "as to believing you", I must apologize to you: this 
sentence was a dumb litteral transcription of a french 
idiom which doesn't have exactly the sense it seems to 
have. This was just a way to tell readers that this 
information did came from you, so having a look at what you 
said may be of interest. No harm intended, really.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 01:42

Message:
Logged In: YES 
user_id=31435

We are having more reports of installer problems under 2.1 
than under previous releases, but I can still count the 
total on one hand.  Since we don't have the installer 
source code, and reports are still so rare (notwithstanding 
your particular bad luck) there's not much we can do to 
track them down.

Did you use the MD5 checksum program to verify your binary 
is valid?  Go to http://www.python.org/2.1/, go down to 
the "MD5 checksums" section, and click on the "MD5" part of 
the section heading to get a Python program for computing 
the MD5 digest.

In *almost* all past cases of "corrupt installation 
detected" messages, further investigation has revealed that 
the binary *was* corrupt.  The MD5 digest is a very 
powerful check on that (much stronger than a CRC):  if the 
checksum you get doesn't match the one on the web page 
above, your installer is definitely corrupt.  If it 
matches, the chance that it's corrupt anyway is too small 
to entertain.  So do that.  That you've had *repeated* 
installation failures is unprecedented in Python's history, 
so my top guess has to be you have a flaky binary.

There is only one other cause I've ever heard of for 
a "corrupt installation detected" message under NT:  the 
user was logged in to a Restricted account when they tried 
to install.  In that case, the Wise installer apparently 
can't even get at the system components it needs to compute 
its own internal checksums, and interprets that failure as 
a bad checksum.

So, what were you logged in as?  If the MD5 digest matches, 
and you're logged in to an Administrator account when it 
fails, then you've got a problem never reported before.  Do 
you?

As to using another Windows installer, I'm in favor of 
that, but so are you <wink>:  who's going to do the work?  
I can tell you I don't have time for it.  BTW, have you 
tried ActiveState's Python installer for Windows?  That's 
built with entirely different, and up-to-date, technology.  
Maybe it will work better for you.  But the terms of the 
ActiveState license don't allow us to use it too (fine by 
me -- they paid for it).

As to believing me, you don't have to:  ask Wise 
Solutions.  It's their product, version 5.0a.  You can't 
even find it mentioned on their web site anymore -- it's 
that old!  They're on version 8 now, and even their 
newsgroups only back to version 6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=418156&group_id=5470


From noreply@sourceforge.net  Tue Aug  7 23:42:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 15:42:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-448911 ] Empty list as default argument problem
Message-ID: <E15UFYu-0006kn-00@usw-sf-web1.sourceforge.net>

Bugs item #448911, was opened at 2001-08-07 13:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Empty list as default argument problem

Initial Comment:
To begin, a test case (hopefully mozilla will preserve
the formatting..):

class node:
    def __init__(self, attrs = []):
        self.attrs = attrs

a = node()
b = node()
a.attrs.append("foo")
print b.attrs
This prints ["foo"], where one would expect it to print
[]. Rewriting node.__init__ as follows does the right
thing:

    def __init__(self, attrs = []):
        if not attrs:
            self.attrs = []
        else:
            self.attrs = attrs

It appears that Python allocates the default empty list
argument once and reuses it across multiple
instantiations of the object, so that a and b share
the attrs variable. This is unexpected.

I've tested this on multiple platforms (Linux and IRIX)
and multiple versions of Python (1.5.2 and 2.1.1).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-07 15:42

Message:
Logged In: NO 

ah--right--thanks, Tim! Sorry for the needless bug report.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-07 14:07

Message:
Logged In: YES 
user_id=31435

Not a bug, functioning as designed.

See the FAQ entry

<http://www.python.org/cgi-bin/faqw.py?
req=show&file=faq06.025.htp>

for pointers to more discussion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448911&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 01:19:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 17:19:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-448951 ] Bug in re group handling
Message-ID: <E15UH4D-0000ih-00@usw-sf-web2.sourceforge.net>

Bugs item #448951, was opened at 2001-08-07 17:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug in re group handling

Initial Comment:
#
# read it or run it!
#
import re,sys
print sys.version
#
# Bug in 're' lib in Python 2.1
#
# Consider this regexp : (?:([0-3]):)?0#
# This will match one of
# '0#', '0:0#', '1:0#', '2:0#', '3:0#' 
#
# The matching itself works fine, but group(1) should
# be None for the '0#' case, and 'x' for the 'x:0#' cases.
# For '0#', the optional '([0-3]):' part of the
# r.e. (enclosed in (?: )) does not match anything, and that
# is what contains group 1.
#
# The actual result is, group(1) is '0' for both '0#' and '0:0#'.
# Likely this happens because when '0' is seen, the state machine
# cannot not yet determine whether the ([0-3]): should be matched,
# but has already seen enough of it to know what group(1) is, assuming
# it does match. The match needs to be deleted once the containing 
# ? fails. Indeed, if the group is expanded to include the ':',
# as in '(?:([0-3]:))?0#', or just '([0-3]:)?0#', '0#' produces
# group(1)=None as it should.
#
# Also, this is a good time to point out an error in the
# docs. The docs say that group(n) returns -1 when the
# group is in an unmatched part the of the r.e.; actually
# it returns None, which is more sensible.
#

rexp = '(?:([0-3]):)?0#'
mat1 = re.compile(rexp)

print "Re = ", rexp

for str in [ '2:0#', '0:0#', '0#', '0:#', ':0#']:
	print "\n-----<<", str, ">>-----"
	mat = mat1.match(str)
	if mat:
		print "    group(0) = ", mat.group(0)
		print "    group(1) = ", mat.group(1)
	else:
		print "    no match"
#
# output is below
#
#################################
# Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
# Re =  (?:([0-3]):)?0#
# 
# -----<< 2:0# >>-----
#     group(0) =  2:0#
#     group(1) =  2
# 
# -----<< 0:0# >>-----
#     group(0) =  0:0#
#     group(1) =  0
# 
# -----<< 0# >>-----
#     group(0) =  0#
#     group(1) =  0
# 
# -----<< 0:# >>-----
#     no match
# 
# -----<< :0# >>-----
#     no match
#
############################################

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 05:37:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 21:37:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-449000 ] re.sub(r'\n', ...) broke
Message-ID: <E15UL5p-0003i5-00@usw-sf-web1.sourceforge.net>

Bugs item #449000, was opened at 2001-08-07 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449000&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fredrik Lundh (effbot)
Summary: re.sub(r'\n', ...) broke

Initial Comment:
Fredrik,

I believe the latest changes to re.sub() broke an
endcase in re.sub().

I used to be able to write r'\n' as a pattern and it
would do the same thing as '\n'.
Now this doesn't work any more; '\n' works but r'\n'
doesn't seem to do anything.

I'm guessing this is an endcase handled wrong in the
most recent checkin ("map re.sub() to string.replace(),
when possible" sounds suspicious to me).  I haven't
verified this hypothesis, but it still works in 2.1.1
and is broken in current CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449000&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 06:37:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 22:37:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15UM1r-0003fX-00@usw-sf-web2.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-07 22:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 06:41:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 22:41:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-449009 ] distutils spelling error
Message-ID: <E15UM5t-0004sj-00@usw-sf-web3.sourceforge.net>

Bugs item #449009, was opened at 2001-08-07 22:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470

Category: Distutils
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils spelling error

Initial Comment:
In dist.py, "license" is spelled "licence".  This 
carries through to the setup.py;  if you want to 
specify a "license", it must be under the key 
"licence".

Also, the description mappings are kind of weird:

setup.py => PKG-INFO
-------------------------------
description => summary
long_description => description



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 06:43:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 07 Aug 2001 22:43:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-449009 ] distutils spelling error
Message-ID: <E15UM7Y-0004UX-00@usw-sf-web2.sourceforge.net>

Bugs item #449009, was opened at 2001-08-07 22:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470

Category: Distutils
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils spelling error

Initial Comment:
In dist.py, "license" is spelled "licence".  This 
carries through to the setup.py;  if you want to 
specify a "license", it must be under the key 
"licence".

Also, the description mappings are kind of weird:

setup.py => PKG-INFO
-------------------------------
description => summary
long_description => description



----------------------------------------------------------------------

>Comment By: Bill Bumgarner (bbum)
Date: 2001-08-07 22:43

Message:
Logged In: YES 
user_id=103811

I just realized the licence/license issue is a duplicate of 
#412271.

Maybe this should be retooled as a "make distutils 
meta info keys consistent"?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 13:39:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 05:39:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-449093 ] operator needs // support
Message-ID: <E15UScX-0004Jp-00@usw-sf-web3.sourceforge.net>

Bugs item #449093, was opened at 2001-08-08 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: operator needs // support

Initial Comment:
The operator needs to get new interfaces added in
support of truediv and floordiv.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 13:40:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 05:40:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-449093 ] operator needs // support
Message-ID: <E15USdU-0003WZ-00@usw-sf-web2.sourceforge.net>

Bugs item #449093, was opened at 2001-08-08 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: operator needs // support

Initial Comment:
The operator needs to get new interfaces added in
support of truediv and floordiv.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 05:40

Message:
Logged In: YES 
user_id=6380

Also a reminder for Fred to add more docs for this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 13:44:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 05:44:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E15USgt-0004O4-00@usw-sf-web3.sourceforge.net>

Bugs item #210665, was opened at 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

Category: Threads
Group: Platform-specific
Status: Closed
Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-08-08 05:44

Message:
Logged In: YES 
user_id=200117

On the 19th June I posted a comment here ref the patch 
file: 'python-2.1.patch' 
from ftp://ftp.thewrittenword.com/outgoing/pub

After applying this patch to Python 2.1 source, I 
successfully built a Python interpreter on HP-UX 11.0 with 
threads enabled. (I have tested it with several examples 
from Mark Lutz's book using the thread and threading 
modules and it works fine).

Is there some reason why you do not accept this patch ?

It would be really useful if this fix could be included for 
Python 2.2 :-)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:26

Message:
Logged In: YES 
user_id=6380

Closing this for lack of progress.

If someone figures out what to do with threads on HPUX-11,
please submit a fresh *patch*.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 10:31

Message:
Logged In: YES 
user_id=6380

Alas, not.  Those binaries don't have threads enabled.

HP doesn't know how to do it either.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:37

Message:
Logged In: YES 
user_id=6380

For all of those in search for an easy solution:

HP makes binaries available.  See

http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-19 03:07

Message:
Logged In: YES 
user_id=200117

I have now applied the new patch file 'python-2.1.patch' 
available at: ftp://ftp.thewrittenword.com/outgoing/pub

I can now successfully build Python 2.1 with threads 
enabled, on HP-UX 11. 



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-14 01:20

Message:
Logged In: YES 
user_id=200117

I applied the patch from thewrittenword's site, but when I 
ran autoconf it generated a corrupt configure script.

There problem occurs around lines 3895-3906:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1
fi
 LDLAST=-threads;;
	    esac
	fi
    fi
fi

The case statement has been trashed by the extra 'fi' 
token. I tried manually editing it like this:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1) LDLAST=-threads;;
	    esac
	fi
    fi
fi

But it still fails with an 'else' not matched at line 3422.
I can't see where the extra 'fi' should go.




----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

----------------------------------------------------------------------

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 15:14:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 07:14:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15UU6X-000248-00@usw-sf-web1.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:14

Message:
Logged In: YES 
user_id=6380

OK, thanks for the explanation.  It seems you've hit a snag
in the autoconf AC_PROG_CC macro. I don't know how
successful we'll be in getting this fixed. :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-07 22:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 15:56:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 07:56:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E15UUlW-0003Wj-00@usw-sf-web1.sourceforge.net>

Bugs item #210665, was opened at 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Open
Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:56

Message:
Logged In: YES 
user_id=6380

Actually, now that you mention it, yes, there's a reason not
to accept that patch (which I hadn't seen before -- sorry).
It appears to be patching tons of unrelated things, and some
of the diffs in it appear to be diffs between different
Python versions. Also, it patches configure instead of
configure.in. configure is a generated file. Ditto for
config.h.in.

In other words, that patch may fix your problem, but I can't
check it in. Perhaps you could work on a *minimal* patch
that solves the problem, and which works with the current
CVS (or at least the 2.2a1 release). Then I'll look again.

Since you show interest in doing this, I've reopened the bug
report.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-08-08 05:44

Message:
Logged In: YES 
user_id=200117

On the 19th June I posted a comment here ref the patch 
file: 'python-2.1.patch' 
from ftp://ftp.thewrittenword.com/outgoing/pub

After applying this patch to Python 2.1 source, I 
successfully built a Python interpreter on HP-UX 11.0 with 
threads enabled. (I have tested it with several examples 
from Mark Lutz's book using the thread and threading 
modules and it works fine).

Is there some reason why you do not accept this patch ?

It would be really useful if this fix could be included for 
Python 2.2 :-)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:26

Message:
Logged In: YES 
user_id=6380

Closing this for lack of progress.

If someone figures out what to do with threads on HPUX-11,
please submit a fresh *patch*.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 10:31

Message:
Logged In: YES 
user_id=6380

Alas, not.  Those binaries don't have threads enabled.

HP doesn't know how to do it either.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:37

Message:
Logged In: YES 
user_id=6380

For all of those in search for an easy solution:

HP makes binaries available.  See

http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-19 03:07

Message:
Logged In: YES 
user_id=200117

I have now applied the new patch file 'python-2.1.patch' 
available at: ftp://ftp.thewrittenword.com/outgoing/pub

I can now successfully build Python 2.1 with threads 
enabled, on HP-UX 11. 



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-14 01:20

Message:
Logged In: YES 
user_id=200117

I applied the patch from thewrittenword's site, but when I 
ran autoconf it generated a corrupt configure script.

There problem occurs around lines 3895-3906:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1
fi
 LDLAST=-threads;;
	    esac
	fi
    fi
fi

The case statement has been trashed by the extra 'fi' 
token. I tried manually editing it like this:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1) LDLAST=-threads;;
	    esac
	fi
    fi
fi

But it still fails with an 'else' not matched at line 3422.
I can't see where the extra 'fi' should go.




----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

----------------------------------------------------------------------

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:05:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:05:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-449151 ] Multiple interpreters break exceptions
Message-ID: <E15UUtP-0001YW-00@usw-sf-web3.sourceforge.net>

Bugs item #449151, was opened at 2001-08-08 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449151&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Multiple interpreters break exceptions

Initial Comment:
When creating multiple interpreters, the initialization
of exceptions in the second interpreter created
overwrites the globals set by the first interpreter,
thereby messing up the identities of exceptions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449151&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:10:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:10:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15UUyU-00011N-00@usw-sf-web2.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:11:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:11:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-210665 ] Compiling python on hpux 11.00 with threads (PR#360)
Message-ID: <E15UUzv-00022x-00@usw-sf-web3.sourceforge.net>

Bugs item #210665, was opened at 2000-07-31 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Compiling python on hpux 11.00 with threads (PR#360)

Initial Comment:
Jitterbug-Id: 360
Submitted-By: philipp.jocham@salomon.at
Date: Fri, 16 Jun 2000 08:47:06 -0400 (EDT)
Version: 1.5.2
OS: HP-UX 11.00


There are two missing details in the configure process to make this work
out of the box.

First: The function 
	pthread_create
isn't found in library libpthread.a but in libcma.a, because
pthread_create is just a macro in sys/pthread.h pointing to 
	__pthread_create_system

After patching ./configure directly and running 
	./configure --with-thread
(now detecting the correct library /usr/lib/libpthread.a) I also
added -lcl to Modules/Makefile at
	LIBS=           -lnet -lnsl -ldld  -lpthread -lcl

otherwise importing of modules with threads didn't work 
(in this case oci_.sl from DCOracle). 

I'm not sure about the correct syntax or wether it's the correct
place and method, but I would suggest a solution like the following
code snippet.

[...]
AC_MSG_CHECKING(for --with-thread)
[...]
AC_DEFINE(_POSIX_THREADS)
LIBS="$LIBS -lpthread -lcl"
LIBOBJS="$LIBOBJS thread.o"], [
AC_CHECK_LIB(pthread, __pthread_create_system, [AC_DEFINE(WITH_THREAD)
[...]

I hope this helps to make installation process smoother.
Fell free to contact me, if there are further questions.
Philipp
-- 
I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



====================================================================
Audit trail:
Tue Jul 11 08:26:01 2000	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-08-08 08:11

Message:
Logged In: YES 
user_id=119770

I'd rather see a new configure option, --with-cma-threads,
similar to --with-dec-threads, to enable the CMA thread
support for HP-UX 10.20.

We'll try to work on a configure.in patch against CVS for
HP-UX 11.00.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:56

Message:
Logged In: YES 
user_id=6380

Actually, now that you mention it, yes, there's a reason not
to accept that patch (which I hadn't seen before -- sorry).
It appears to be patching tons of unrelated things, and some
of the diffs in it appear to be diffs between different
Python versions. Also, it patches configure instead of
configure.in. configure is a generated file. Ditto for
config.h.in.

In other words, that patch may fix your problem, but I can't
check it in. Perhaps you could work on a *minimal* patch
that solves the problem, and which works with the current
CVS (or at least the 2.2a1 release). Then I'll look again.

Since you show interest in doing this, I've reopened the bug
report.

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-08-08 05:44

Message:
Logged In: YES 
user_id=200117

On the 19th June I posted a comment here ref the patch 
file: 'python-2.1.patch' 
from ftp://ftp.thewrittenword.com/outgoing/pub

After applying this patch to Python 2.1 source, I 
successfully built a Python interpreter on HP-UX 11.0 with 
threads enabled. (I have tested it with several examples 
from Mark Lutz's book using the thread and threading 
modules and it works fine).

Is there some reason why you do not accept this patch ?

It would be really useful if this fix could be included for 
Python 2.2 :-)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:26

Message:
Logged In: YES 
user_id=6380

Closing this for lack of progress.

If someone figures out what to do with threads on HPUX-11,
please submit a fresh *patch*.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 10:31

Message:
Logged In: YES 
user_id=6380

Alas, not.  Those binaries don't have threads enabled.

HP doesn't know how to do it either.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 08:37

Message:
Logged In: YES 
user_id=6380

For all of those in search for an easy solution:

HP makes binaries available.  See

http://hpux.connect.org.uk/hppd/hpux/Languages/python-2.1/

----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-19 03:07

Message:
Logged In: YES 
user_id=200117

I have now applied the new patch file 'python-2.1.patch' 
available at: ftp://ftp.thewrittenword.com/outgoing/pub

I can now successfully build Python 2.1 with threads 
enabled, on HP-UX 11. 



----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2001-06-14 01:20

Message:
Logged In: YES 
user_id=200117

I applied the patch from thewrittenword's site, but when I 
ran autoconf it generated a corrupt configure script.

There problem occurs around lines 3895-3906:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1
fi
 LDLAST=-threads;;
	    esac
	fi
    fi
fi

The case statement has been trashed by the extra 'fi' 
token. I tried manually editing it like this:

	if test "$USE_THREAD_MODULE" != "#"
	then
	    # If the above checks didn't disable threads, 
(at least) OSF1
	    # needs this '-threads' argument during linking.
	    case $ac_sys_system in
	    OSF1) LDLAST=-threads;;
	    esac
	fi
    fi
fi

But it still fails with an 'else' not matched at line 3422.
I can't see where the extra 'fi' should go.




----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-02 08:38

Message:
Reopened because there's a dissenting opinion.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-02 07:25

Message:
Ok, check out the configure.in patch I created against Python 2.0:
  ftp://ftp.thewrittenword.com/outgoing/pub/python-2.0.patch

I tested it under HP-UX 11.00 and it works just fine. The thread test worked too.

-- 
albert chin (china@thewrittenword.com)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-11-01 09:18

Message:
Ick! Why check for anything with __ prepended to the name? Isn't that like checking for a "hidden" function, which might not be there in a followup version?

On HP-UX 11.00, pthread_create is in /usr/lib/libc.sl anyway. The proper way to check for pthread_create is:
  AC_TRY_LINK([#include <pthread.h>

  void * start_routine (void *arg) { exit (0); }], [
  pthread_create (NULL, NULL, start_routine, NULL)], [
    AC_MSG_RESULT(yes)], [
    AC_MSG_RESULT(no)])

I modified configure.in in 2.0 to remove the patch you included in CVS 1.175 and added a test to include <pthread.h> similar to the above (linked without -lpthread and with -lpthread). I'm testing now. Will provide a patch when things are tested.

Also, I don't think threads on HP-UX 10.20 will work unless you have the DCE libraries installed. Anyhow, I'd probably avoid threads on 10.20.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 09:48

Message:
Philipp submitted a patch to configure.in that fixes the problem for him and doesn't look like it would break things for others.  configure.in, CVS revision 1.175.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:45

Message:
OK, so the correct thing to do seems to be to somehow add #include <pthread.h> to the tests for thread libraries. I'm afraid I won't be able to fix this in 2.0final, but I'll think about fixing it in 2.1 (or 2.0.1, whichever comes first :-).

----------------------------------------------------------------------

Comment By: Eddy De Greef (edg)
Date: 2000-10-10 04:55

Message:
I can confirm that the bug still exists in 2.0c1.
It works fine on HP-UX 10.20 (which only has libcma),
but not on HP-UX 11 (which both has libcma and libpthread).
The pthread_create function is not defined as a macro though,
but as a static function:

static int pthread_create(pthread_t *tid, const pthread_attr_t *attr, void *(*start_routine)(void *), void *arg)
   { return(__pthread_create_system(tid, attr, start_routine, arg)); }

I don't see an easy way to work around this.
I'm not a configure expert, but perhaps the script should
first check whether this code compiles and links:

#include <pthread.h>
int main()
{
   pthread_create(0,0,0,0);
   return 0;
}

and if not, fall back on the other tests ?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-06 10:40

Message:
I have two reports from people for whom configure, build and run  with threads now works on HP-UX 10 and 11. I'm not sure what to do about this report... What's different on Philipp's system???

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-25 06:10

Message:
I'm hoping that this was fixed by recent changes. Sent an email to the original submittor to verify.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:56

Message:
Taking this because I'm considering to redesign the thread configuration section in configure.in anyway -- there's a similar bug report for Alpha OSF1.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210665&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:11:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:11:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15UV01-0004Zc-00@usw-sf-web1.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 08:11

Message:
Logged In: YES 
user_id=45365

If I may chime in (but don't you _dare_ assign this item to
me:-): it is the AC_EXEEXT macro that fails, not AC_PROG_CC.
AC_EXEEXT just compiles and links a program, and assumes
that whatever comes out has to be the executable.

But: the Metrowerks compilers/linkers produce 2 files: the
executable (without suffix)
and the debugger symbol table (with .xSYM suffix). AC_EXEEXT
picks the wrong one:-(

Hmm, on my SGI system I can't find the definition of
AC_EXEEXT (??!?) so this is about as much help as I can
give.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:14

Message:
Logged In: YES 
user_id=6380

OK, thanks for the explanation.  It seems you've hit a snag
in the autoconf AC_PROG_CC macro. I don't know how
successful we'll be in getting this fixed. :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-07 22:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:14:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:14:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15UV2L-0004c3-00@usw-sf-web1.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

>Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 16:19:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 08:19:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-448481 ] Missing .h files and compiler warnings
Message-ID: <E15UV7M-0004hF-00@usw-sf-web1.sourceforge.net>

Bugs item #448481, was opened at 2001-08-06 11:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470

Category: Macintosh
Group: Python 2.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: Missing .h files and compiler warnings

Initial Comment:
Attempted to build 2.2a1 on Mac OS X 10.0.4. Got a 
LOT of compiler warnings (mostly "function 
declaration not a prototype"), but make specifically 
stopped when trying the following:
Python/dynload_next.c:30: header file 'mach-o/
rld.h' not found
Python/dynload_next.c:51: undefined type, found 
`NXStream'
cpp-precomp: warning: errors during smart 
preprocessing, retrying in basic mode
make: *** [Python/dynload_next.o] Error 1

I can redirect all warnings and errors to a .txt file 
and e-mail it to anyone who might want to have a 
look.

-John Buell

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 08:19

Message:
Logged In: YES 
user_id=45365

This should be fixed in the CVS repository as of this
afternoon. Please let me know if there are more problems.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 17:19:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 09:19:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-448481 ] Missing .h files and compiler warnings
Message-ID: <E15UW3N-0004ZE-00@usw-sf-web3.sourceforge.net>

Bugs item #448481, was opened at 2001-08-06 11:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: Missing .h files and compiler warnings

Initial Comment:
Attempted to build 2.2a1 on Mac OS X 10.0.4. Got a 
LOT of compiler warnings (mostly "function 
declaration not a prototype"), but make specifically 
stopped when trying the following:
Python/dynload_next.c:30: header file 'mach-o/
rld.h' not found
Python/dynload_next.c:51: undefined type, found 
`NXStream'
cpp-precomp: warning: errors during smart 
preprocessing, retrying in basic mode
make: *** [Python/dynload_next.o] Error 1

I can redirect all warnings and errors to a .txt file 
and e-mail it to anyone who might want to have a 
look.

-John Buell

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-08 09:19

Message:
Logged In: NO 

make got a lot further this time:
cc  -u __dummy -u _PyMac_Error -framework System -
framework Foundation -framework Carbon -o python \
                Modules/python.o \
                libpython2.2.a -lpthread -ldl      
/usr/bin/ld: can't create output file: python (Is a directory, 
errno = 21)
make: *** [python] Error 1

Except for that bit about the output file. I'm wondering if 
anyone else is having that problem, or if it's unique to 
the way I set up my directories. I've got everything in /
Users/jbuell/Documents/Python with the full cvs 
directories underneath that.

-John Buell

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 08:19

Message:
Logged In: YES 
user_id=45365

This should be fixed in the CVS repository as of this
afternoon. Please let me know if there are more problems.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448481&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 17:44:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 09:44:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E15UWRh-0005jp-00@usw-sf-web3.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I'm guessing this is resultant of a problem elsewhere, but I'm 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 09:44

Message:
Logged In: YES 
user_id=6380

Thanks, Jack. I sent a msg to the autoconf list and they
said they would fix it in their CVS. Also they said:

As a workaround (so Python users don't require a CVS or
hacked version of
autoconf), you could strip '-g' from CFLAGS on BeOS (as it
seems to be that
flag that produces the .xSYM file) in configure.in.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 08:11

Message:
Logged In: YES 
user_id=45365

If I may chime in (but don't you _dare_ assign this item to
me:-): it is the AC_EXEEXT macro that fails, not AC_PROG_CC.
AC_EXEEXT just compiles and links a program, and assumes
that whatever comes out has to be the executable.

But: the Metrowerks compilers/linkers produce 2 files: the
executable (without suffix)
and the debugger symbol table (with .xSYM suffix). AC_EXEEXT
picks the wrong one:-(

Hmm, on my SGI system I can't find the definition of
AC_EXEEXT (??!?) so this is about as much help as I can
give.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 07:14

Message:
Logged In: YES 
user_id=6380

OK, thanks for the explanation.  It seems you've hit a snag
in the autoconf AC_PROG_CC macro. I don't know how
successful we'll be in getting this fixed. :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-07 22:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 03:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 12:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 03:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 03:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 02:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 03:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 02:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 04:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 01:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 05:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 20:35:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 12:35:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZ6r-0006tR-00@usw-sf-web1.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Nobody/Anonymous (nobody)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 20:45:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 12:45:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZGu-0004fx-00@usw-sf-web3.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:06:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:06:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZb3-0005MZ-00@usw-sf-web3.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Guido van Rossum (gvanrossum)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:10:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:10:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZeW-00009c-00@usw-sf-web1.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

>Category: Documentation
Group: Not a Bug
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:16:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:16:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZl3-0004Qh-00@usw-sf-web2.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

>Category: Python Interpreter Core
Group: Not a Bug
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:21:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:21:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15UZpW-0000K8-00@usw-sf-web1.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Nobody/Anonymous (nobody)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:22:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:22:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15UZqG-0000LK-00@usw-sf-web1.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
>Assigned to: Martin v. Lіwis (loewis)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 21:26:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 13:26:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UZuS-0004ZA-00@usw-sf-web2.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Guido van Rossum (gvanrossum)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:26

Message:
Logged In: YES 
user_id=20438

tim_one, are you saying that the objects that do/don't 
participate in gc shouldn't be documented?!?

I'm certainly no expert in Python internals but I 
understand enough to know what that distinction means and 
would like to see the list documented for each release.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 22:06:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 14:06:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UaXJ-0007kC-00@usw-sf-web3.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

>Category: Documentation
>Group: None
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-08 14:06

Message:
Logged In: YES 
user_id=31435

Yes and no.  There are about 100 internal types implemented 
in C, and you've probably never even heard of most of them 
(heck, I bet even Guido wouldn't recognize the names of 
dozens of them).  So if we give you a giant list of which 
do and don't participate in gc, what good would it do you?

sys._getframe() starts with an underscore to scare you 
away:  it's an internal function that only experts should 
even think about using.

You're using inspect.stack(), and that's where the problem 
is:  if we expose a "high level" interface that isn't meant 
for experts only, then *that's* where cautions about cycles 
should appear, in its docs.  You need to know that 
inspect.stack can get you in trouble, but going on about 
internal implementation details isn't going to help -- the 
latter is at the wrong level for inspect.stack()'s users.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:26

Message:
Logged In: YES 
user_id=20438

tim_one, are you saying that the objects that do/don't 
participate in gc shouldn't be documented?!?

I'm certainly no expert in Python internals but I 
understand enough to know what that distinction means and 
would like to see the list documented for each release.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Wed Aug  8 23:21:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 15:21:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15UbhW-0005Jh-00@usw-sf-web1.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 15:21

Message:
Logged In: YES 
user_id=20438

I understand your point, but I disagree with it wrt GC.

Assuming I am willing to take on the cost/risk of using 
sys._getframe() I should be able to find documentation 
that describes at least minimally the risks related to GC, 
threads, and recursion.  This is because I don't want to 
become a Python master, just use the language well to make 
my job easier.

For example, I am making use of sys._getframe() to make 
coding an Interceptor pattern less mind numbing.  I 
recognize that I need to be careful - and previously have 
even gone so far into the code as to provide a Python 
patch to implement sys._getframes().


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 14:06

Message:
Logged In: YES 
user_id=31435

Yes and no.  There are about 100 internal types implemented 
in C, and you've probably never even heard of most of them 
(heck, I bet even Guido wouldn't recognize the names of 
dozens of them).  So if we give you a giant list of which 
do and don't participate in gc, what good would it do you?

sys._getframe() starts with an underscore to scare you 
away:  it's an internal function that only experts should 
even think about using.

You're using inspect.stack(), and that's where the problem 
is:  if we expose a "high level" interface that isn't meant 
for experts only, then *that's* where cautions about cycles 
should appear, in its docs.  You need to know that 
inspect.stack can get you in trouble, but going on about 
internal implementation details isn't going to help -- the 
latter is at the wrong level for inspect.stack()'s users.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:26

Message:
Logged In: YES 
user_id=20438

tim_one, are you saying that the objects that do/don't 
participate in gc shouldn't be documented?!?

I'm certainly no expert in Python internals but I 
understand enough to know what that distinction means and 
would like to see the list documented for each release.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 05:02:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 21:02:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-449383 ] os.chmod sets mode incorrectly
Message-ID: <E15Uh1O-0002F9-00@usw-sf-web1.sourceforge.net>

Bugs item #449383, was opened at 2001-08-08 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449383&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: UoC COSC Programmers (uoccosc)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.chmod sets mode incorrectly

Initial Comment:
I'm using
ActivePython 2.1, build 211 (ActiveState)
based on Python 2.1 (#1, Jun 13 2001, 01:01:26) 
[GCC 2.95.2 19991024 (release)] on sunos5

on
SunOS %host% 5.7 Generic sun4u sparc SUNW,Ultra-1

os.chmod does not set the correct mode, for example

os.chmod(path, 700)
result   --w-rwxr--
expected -rwx------

os.chmod(path, 644)
result   --w----r--
expected -rw-r--r--

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449383&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 05:17:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 08 Aug 2001 21:17:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-449383 ] os.chmod sets mode incorrectly
Message-ID: <E15UhGX-0002r7-00@usw-sf-web1.sourceforge.net>

Bugs item #449383, was opened at 2001-08-08 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449383&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: UoC COSC Programmers (uoccosc)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.chmod sets mode incorrectly

Initial Comment:
I'm using
ActivePython 2.1, build 211 (ActiveState)
based on Python 2.1 (#1, Jun 13 2001, 01:01:26) 
[GCC 2.95.2 19991024 (release)] on sunos5

on
SunOS %host% 5.7 Generic sun4u sparc SUNW,Ultra-1

os.chmod does not set the correct mode, for example

os.chmod(path, 700)
result   --w-rwxr--
expected -rwx------

os.chmod(path, 644)
result   --w----r--
expected -rw-r--r--

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-08 21:17

Message:
Logged In: YES 
user_id=31435

This looks like pilot error to me:  chmod interprets its 
second argument as a bitmask, and you're passing it decimal 
integers.

>>> oct(700)
'01274'
>>> oct(644)
'01204'
>>>

That explains what you're seeing, so I'm closing this bug.  
Pass 0700 and 0644 instead.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449383&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 13:27:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 05:27:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E15Uou2-000188-00@usw-sf-web3.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Closed
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 14:14:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 06:14:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E15UpeC-00010G-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 06:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

----------------------------------------------------------------------

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 15:11:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 07:11:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-449493 ] <module>.__dict__ goes into 'help>'
Message-ID: <E15UqX2-0005oI-00@usw-sf-web3.sourceforge.net>

Bugs item #449493, was opened at 2001-08-09 07:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449493&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mario Ruggier (ruggier)
Assigned to: Nobody/Anonymous (nobody)
Summary: <module>.__dict__ goes into 'help>'

Initial Comment:
Environment: 
ActiveState Python21 (#15, April 16 2001) on Win2000.

Problem:
when I ask for the __dict__ of a module interactively,
I am consistently presneted with python interactive 
elp prompt. The __dict__ seems to be returned 
orrectly, but for the 'help' entry (the last shown), 
it prints some about-help info, and then presents the 
help prompt. This seems to happen with any module, 
even standard modules such as 're'. 

==
Additional remarks (to post on python-help)
from Alex Martelli:

I don't have that particular build installed, so I 
don't observe this phenomenon (I don't even get 
'help' entry in my modules!-) -- but it's easy to see 
what must be happening.

When you type an expression-statement at the 
interactive interpreter prompt, and that expression 
returns a result that is not None, the interactive 
interpreter's default hook (sys.displayhook) emits the 
repr() of that result (and also sets __builtin__._ to 
the result).  The repr() of a dictionary, in turn, 
calls the repr() of each key and value of that 
dictionary (as well as emitting some other stuff).

So, given the symptoms you observe, it must be that 
the whatever.__dict__['help'] entry is set to an 
object such that its repr() 'presents a prompt' (at 
least when called from an interactive session -- 
isatty (stdout) or something like that).  This is 
presumably done so that one can just write at the 
interpreter prompt
    >>> re.help
(etc) and get the interactive-session implicitly, 
rather than having to bother with a CALL of it
    >>> re.help()
as would presumably be more natural.

I can see how this could be a bother -- things meant
to be highly convenient under certain hypotheses can
easily be a bother instead of those hypotheses do not
obtain!  One fix might be to tweak the sys.displayhook
for your purposes: if it's passed specifically a
dictionary, it could display, instead of the repr
of that dictionary, the repr of a slightly different
dictionary whose 'help' key's value, if any, is
temporarily changed to a non-highly-magical object.
Just for example...

It might be worth posting this as a bug to the
bug-tracker at python.sourceforge.net -- if you
do so, please feel free to include any or all
of this response.

Alex




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449493&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 15:25:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 07:25:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-449493 ] <module>.__dict__ goes into 'help>'
Message-ID: <E15UqkS-0002A5-00@usw-sf-web1.sourceforge.net>

Bugs item #449493, was opened at 2001-08-09 07:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449493&group_id=5470

>Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Mario Ruggier (ruggier)
Assigned to: Nobody/Anonymous (nobody)
Summary: <module>.__dict__ goes into 'help>'

Initial Comment:
Environment: 
ActiveState Python21 (#15, April 16 2001) on Win2000.

Problem:
when I ask for the __dict__ of a module interactively,
I am consistently presneted with python interactive 
elp prompt. The __dict__ seems to be returned 
orrectly, but for the 'help' entry (the last shown), 
it prints some about-help info, and then presents the 
help prompt. This seems to happen with any module, 
even standard modules such as 're'. 

==
Additional remarks (to post on python-help)
from Alex Martelli:

I don't have that particular build installed, so I 
don't observe this phenomenon (I don't even get 
'help' entry in my modules!-) -- but it's easy to see 
what must be happening.

When you type an expression-statement at the 
interactive interpreter prompt, and that expression 
returns a result that is not None, the interactive 
interpreter's default hook (sys.displayhook) emits the 
repr() of that result (and also sets __builtin__._ to 
the result).  The repr() of a dictionary, in turn, 
calls the repr() of each key and value of that 
dictionary (as well as emitting some other stuff).

So, given the symptoms you observe, it must be that 
the whatever.__dict__['help'] entry is set to an 
object such that its repr() 'presents a prompt' (at 
least when called from an interactive session -- 
isatty (stdout) or something like that).  This is 
presumably done so that one can just write at the 
interpreter prompt
    >>> re.help
(etc) and get the interactive-session implicitly, 
rather than having to bother with a CALL of it
    >>> re.help()
as would presumably be more natural.

I can see how this could be a bother -- things meant
to be highly convenient under certain hypotheses can
easily be a bother instead of those hypotheses do not
obtain!  One fix might be to tweak the sys.displayhook
for your purposes: if it's passed specifically a
dictionary, it could display, instead of the repr
of that dictionary, the repr of a slightly different
dictionary whose 'help' key's value, if any, is
temporarily changed to a non-highly-magical object.
Just for example...

It might be worth posting this as a bug to the
bug-tracker at python.sourceforge.net -- if you
do so, please feel free to include any or all
of this response.

Alex




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 07:25

Message:
Logged In: YES 
user_id=6380

It appears that ActiveState have added the help feature more
aggressively to their release than PythonLabs.  The
PythonLabs releases through 2.1.1 do not include help among
the built-ins.  In Python 2.2a1, help is a builtin, but
asking for its repr() does not enter interactive help mode
-- you have to type help() for that. I'll forward this bug
report to ActiveState.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449493&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 17:04:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 09:04:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-215076 ] threads of __del__
Message-ID: <E15UsIb-0007FJ-00@usw-sf-web2.sourceforge.net>

Bugs item #215076, was opened at 2000-09-22 02:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Toby Dickenson (htrd)
>Assigned to: Martin v. Lіwis (loewis)
Summary: threads of __del__

Initial Comment:
I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-09 09:04

Message:
Logged In: YES 
user_id=31435

Assigning to Martin, since the corresponding patch got 
assigned to him too.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-22 18:28

Message:
Logged In: NO 

Im trying to learn the art of cracking


----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-25 02:04

Message:
Ive noticed that this patch also fixes a different problem that I hadnt realised was related....

We were observing that one thread occasionally became blocked for a few tens of seconds, and the profiler wasnt giving any hints.

It turns out that this thread was busy emptying the trashcan, and running the deallocator functions for the objects used and discardered by all the other threads.

The script below shows up this problem (on NT). It prints pairs of numbers; the first out of each pair will stay the same for 'a long time'.

Mark: I assume Python.net will print the 'Waaah' lines too?

import thread,time

class A:
    def __init__(self,other):
        self._other = other
        self._ident = thread.get_ident()

    def __del__(self):
        new_ident = thread.get_ident()
        if new_ident!=self._ident:
            print 'Waaaaaah', new_ident, self._ident

def work(size):
    ident = thread.get_ident()
    while 1:
        a=None
        for i in range(size):
            a = A(a)
            for i in range(10):
                a = (a,)
            


# Three few big ones
for i in range(3):
    thread.start_new_thread(work,(1000,))
# And one huge one
work(100000)


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2000-09-22 16:57

Message:
I've got to side with Tim that "last thread with a reference" is not the correct semantic to be applied here.

On the other hand, I do agree that some determinism would be nice here.  The reporter is completely correct about, eg, COM rules.  If I was BDFL, I would probably go for something deterministic, and that probably is "last thread to release", as anything else is just unreasonable.

My understanding of .NET is that it does GC on a seperate GC thread!  So there you are guaranteed to not get the behaviour (but guaranteed not to get it ever ;-)

Sorry Tim - back at ya!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 11:52

Message:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 07:52

Message:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 06:30

Message:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:27

Message:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 03:08

Message:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:05

Message:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:52

Message:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 18:04:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 10:04:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-215076 ] threads of __del__
Message-ID: <E15UtEI-0001Mi-00@usw-sf-web2.sourceforge.net>

Bugs item #215076, was opened at 2000-09-22 02:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470

Category: Threads
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Toby Dickenson (htrd)
Assigned to: Martin v. Lіwis (loewis)
Summary: threads of __del__

Initial Comment:
I suspect (but have not proved) that the support for destroying deeply recursive structures can allow for an instances __del__ method to get called in a thread other than the one in which it lost its last reference.

This can happen if it switches to a different thread during deletion of a deeply recursive structure (with _PyTrash_delete_later not empty). 

Should Python guarantee that this does not happen? (I say yes - it is important for COM clients)

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-09 10:04

Message:
Logged In: YES 
user_id=21627

Since the patch that was supposed to fix this problem got
rejected, it appears that this problem (whatever the problem
exactly is) won't get fixed. It appears that this report is
asking for an enhancement of Python, rather than reporting a
bug. If you still think something needs to be done, I
recommend to produce a PEP explaining the problem and the
proposed solution in detail.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-09 09:04

Message:
Logged In: YES 
user_id=31435

Assigning to Martin, since the corresponding patch got 
assigned to him too.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-03-22 18:28

Message:
Logged In: NO 

Im trying to learn the art of cracking


----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-25 02:04

Message:
Ive noticed that this patch also fixes a different problem that I hadnt realised was related....

We were observing that one thread occasionally became blocked for a few tens of seconds, and the profiler wasnt giving any hints.

It turns out that this thread was busy emptying the trashcan, and running the deallocator functions for the objects used and discardered by all the other threads.

The script below shows up this problem (on NT). It prints pairs of numbers; the first out of each pair will stay the same for 'a long time'.

Mark: I assume Python.net will print the 'Waaah' lines too?

import thread,time

class A:
    def __init__(self,other):
        self._other = other
        self._ident = thread.get_ident()

    def __del__(self):
        new_ident = thread.get_ident()
        if new_ident!=self._ident:
            print 'Waaaaaah', new_ident, self._ident

def work(size):
    ident = thread.get_ident()
    while 1:
        a=None
        for i in range(size):
            a = A(a)
            for i in range(10):
                a = (a,)
            


# Three few big ones
for i in range(3):
    thread.start_new_thread(work,(1000,))
# And one huge one
work(100000)


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2000-09-22 16:57

Message:
I've got to side with Tim that "last thread with a reference" is not the correct semantic to be applied here.

On the other hand, I do agree that some determinism would be nice here.  The reporter is completely correct about, eg, COM rules.  If I was BDFL, I would probably go for something deterministic, and that probably is "last thread to release", as anything else is just unreasonable.

My understanding of .NET is that it does GC on a seperate GC thread!  So there you are guaranteed to not get the behaviour (but guaranteed not to get it ever ;-)

Sorry Tim - back at ya!

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 11:52

Message:
Assigned to MarkH, as I want his opinion on this.

I dislike it on principle:  it elevates an accident of refcount semantics into a design goal, and complicates the code to achieve that.

The Microsoft .NET implementation of Python doesn't do refcounting, so not even the pre-trashcan refcount semantics can be relied on there, and I don't want to add to users' difficulties in moving among Python implementations (despite that it may be in my immediate financial interest to lock people into CPython, I'll leave "embrace & extend" to MS <wink>).

If this sounds like a good idea to Mark anyway, fine, but I don't buy it otherwise.

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 07:52

Message:
There is a patch to move the trashcan into the thread state. see http://sourceforge.net/patch/?func=detailpatch&patch_id=101606&group_id=5470

This uses PyThreadState_GET() once to avoid the extra function call in the normal path, and only uses the trashcan if the thread state is non NULL. (assuming we are never deleting deeply recursive objects with no thread state)

On performance, this gives me a 2% increase in pystones....


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 06:30

Message:
It sounds that it will be hard to enforce that __del__ is called in the constructing thread even without the complication of the trashcan code.

Explicitly referencing thread-specific data in a __del__ seems silly -- if the object is tied so closely to the thread, why not add a pointer to the thread to the object.

Nevertheless, especially the COM thing sounds like it would be a good thing to prevent this if it is possible, and your solution (make the trashcan state part of the thread state) sounds reasonable -- except that it means that every deallocation of a tuple, list, dict, frame or traceback needs yet another call to PyThreadState_Get(). And, most disturbing of all, we found before releasing 2.0b1 that there are situations where dictionaries (and possibly other objects) are used when there is no current thread state!!!

Replacing one theoretical problem with another not-so-theoretical one doesn't seem right. Perhaps we could invent a flag that prevents thread-switches while the trashcan dealloc code is running? This could be a simple global boolean that, when set, stops the ceval main loop (and the BEGIN/END ALLOW THREADS macros and related functions!) from ever yielding the interpreter loop. It would almost never be triggered in practice, but guarantee safety in worst cases -- if not efficiency (other threads would be completely blocked until the trashcan code is done).

Back to Tim...

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:27

Message:
There are two cases that I have in mind:

First is that of a COM client.

It depends on the COM threading model in use, but this problem applies in the most common threading model which is also the default threading model using Mark Hammond's pythoncom.

It is only permitted to access a reference to a COM object from the thread in which it is created. This restiction applies to the Release() method that is used by pythoncom to release its reference to the COM server.


Secondly, it is common to use a dictionary keyed by thread.get_ident() to provide thread-local storage. This is used extensively in Zope. Any application that uses this type of thread-local storage in a __del__ is likely to be broken.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 03:08

Message:
And why, exactly, would it be a problem that the trash is deleted in the 'wrong" thread? It's just trash. Any thread can delete it.

Or am I missing something?

----------------------------------------------------------------------

Comment By: Toby Dickenson (htrd)
Date: 2000-09-22 03:05

Message:
I agree there is no self-consistency problem with the trashcan, however......

The code in _PyTrash_destroy_chain can call an objects __del__ method, which can release the interpreter lock.

A second thread may then reenter _PyTrash_destroy_chain and continue to clean up the first thread's garbage. (the first thread is safely blocked inside the Py_DECREF)

Yes the garbage gets cleaned up, however it happens in the wrong thread.

I suggest that _PyTrash_delete_later should be part of pyThreadState




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-22 02:52

Message:
Agreed that this would be a problem if it could cause an inconsistent state of the trashcan (at the end of object.c) structure. However, since the "trash" code is all executed with the global interpreter lock held, I don't see that there can be a problem. Here's why:

The code in _PyTrash_deposit_object() doesn't make any calls that could invoke __del__, so it's safe. The code in _PyTrash_destroy_chain() makes exactly one call to Py_DECREF(), but it takes care that its global data structures are consistent at this point. For a second I thought that _PyTrash_delete_later would have to be declared volatile, but on second thought I don't: the Py_DECREF() macro expands to a possible (indirect) function call, signaling the compiler that the global _PyTrash_delete_later may be changed in arbitrary ways.

Assigned to Tim Peters to verify my reasoning, because of his superior mind in reasoning about threads and race conditions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=215076&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 18:43:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 10:43:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-420725 ] urllib: MIME header for local files
Message-ID: <E15Utqf-0006CP-00@usw-sf-web3.sourceforge.net>

Bugs item #420725, was opened at 2001-05-02 07:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420725&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib: MIME header for local files

Initial Comment:
For local files urllib.py doesn't return the MIME 
headers that the documentation says it does:

http://www.python.org/doc/current/lib/module-
urllib.html#l2h-2187 states that "When the method is 
local-file, returned headers will include a Date 
representing the file's last-modified time, a Content-
Length giving file size, and a Content-Type containing 
a guess at the file's type"

But in Python 2.1 the only header that gets returned
is the Content-Type:

>>> import urllib
>>> f = urllib.urlopen("gurk.txt")      
>>> f.info().headers  
['Content-Type: text/plain\n']


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 10:43

Message:
Logged In: YES 
user_id=6380

Good patch.  APplied as urllib.py 1.128 (with cosmetic
changes to avoid long lines).

(What was the point of assigning this to PaulP?)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 08:57

Message:
Logged In: YES 
user_id=31392

What do you think, Paul?


----------------------------------------------------------------------

Comment By: Walter Dіrwald (doerwalter)
Date: 2001-05-02 09:22

Message:
Logged In: YES 
user_id=89016

A patch (#420753) has been upload to SF.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420725&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 19:15:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 11:15:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-424106 ] PyImport_ExecCodeModule not correct
Message-ID: <E15UuKw-0004gb-00@usw-sf-web2.sourceforge.net>

Bugs item #424106, was opened at 2001-05-14 18:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: PyImport_ExecCodeModule not correct

Initial Comment:
PyImport_ExecCodeModule doesn't handle package imports
correctly. Using it to import a module "A.B" will
result in an entry in sys.modules of "A.B" but no
information for module "A" will be created. The
documentation in the C API reference makes no statement
about this - just that the module name may be of the
form "package.module". Looking at the code in import.c,
there is definitely no handling of the package. If this
is the intended behaviour, please amend the
documentation (and possibly give some hint as to how
one _should_ go about importing a code object in a
package structure ;)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-09 11:15

Message:
Logged In: YES 
user_id=31435

Assigned to Guido cuz he understands this stuff much better.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 19:33:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 11:33:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-424106 ] PyImport_ExecCodeModule not correct
Message-ID: <E15Uucr-0007j1-00@usw-sf-web3.sourceforge.net>

Bugs item #424106, was opened at 2001-05-14 18:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Richard Jones (richard)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyImport_ExecCodeModule not correct

Initial Comment:
PyImport_ExecCodeModule doesn't handle package imports
correctly. Using it to import a module "A.B" will
result in an entry in sys.modules of "A.B" but no
information for module "A" will be created. The
documentation in the C API reference makes no statement
about this - just that the module name may be of the
form "package.module". Looking at the code in import.c,
there is definitely no handling of the package. If this
is the intended behaviour, please amend the
documentation (and possibly give some hint as to how
one _should_ go about importing a code object in a
package structure ;)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 11:33

Message:
Logged In: YES 
user_id=6380

It's a documentation issue.

This is a very low-level helper API in the set of import
APIs.

The package handling is done by the higher-level import
APIs.

If you want to fake importing A.B by providing a code
object, you will have to also fake the other stuff.

I'm leaving this open as a documentation issue, but beware
that this stuff is tricky -- your best bet is to study the
source code.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-09 11:15

Message:
Logged In: YES 
user_id=31435

Assigned to Guido cuz he understands this stuff much better.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=424106&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 19:49:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 11:49:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-449572 ] thread.locked() missing
Message-ID: <E15UusK-0005xT-00@usw-sf-web2.sourceforge.net>

Bugs item #449572, was opened at 2001-08-09 11:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449572&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: thread.locked() missing

Initial Comment:
According to the Library Reference (section 7.4), there
is a function called locked() in the thread module. In
both Python 2.1.1 and Python 2.2a the function was not
found after importing thread.

>> python
>> ] import thread
>> ] print thread.locked.__doc__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute
'locked'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449572&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 19:59:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 11:59:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-449572 ] thread.locked() missing
Message-ID: <E15Uv1Q-000669-00@usw-sf-web2.sourceforge.net>

Bugs item #449572, was opened at 2001-08-09 11:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449572&group_id=5470

Category: Documentation
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: thread.locked() missing

Initial Comment:
According to the Library Reference (section 7.4), there
is a function called locked() in the thread module. In
both Python 2.1.1 and Python 2.2a the function was not
found after importing thread.

>> python
>> ] import thread
>> ] print thread.locked.__doc__
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute
'locked'


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 11:59

Message:
Logged In: YES 
user_id=6380

You are misreading the manual.  The locked() method is a
method on locks, not a function in the module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449572&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 21:22:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 13:22:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-449093 ] docs need to discuss // and __future__.division
Message-ID: <E15UwJf-000153-00@usw-sf-web2.sourceforge.net>

Bugs item #449093, was opened at 2001-08-08 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470

>Category: Documentation
Group: Python 2.2
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: docs need to discuss // and __future__.division

Initial Comment:
The operator needs to get new interfaces added in
support of truediv and floordiv.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 13:22

Message:
Logged In: YES 
user_id=3066

Added floordiv() and truediv() in Modules/operator.c
revision 2.18.  There's still plenty of documentation to be
written regarding the changes in division, so I'm
re-classifying this as a documentation request.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 05:40

Message:
Logged In: YES 
user_id=6380

Also a reminder for Fred to add more docs for this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 21:34:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 13:34:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-414316 ] Script installation failures
Message-ID: <E15UwWA-0001Ed-00@usw-sf-web2.sourceforge.net>

Bugs item #414316, was opened at 2001-04-06 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414316&group_id=5470

Category: Distutils
Group: None
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Script installation failures

Initial Comment:
The "scripts" feature installs scripts with no write 
permission. This is a good thing. But when copying 
scripts down into build/scripts or installing into the 
target python, there are failures because distutils 
does not have write permission on the target when it 
has been previously installed. I assume attempts to 
uninstall are going to have similar difficulties.

In a related matter, we have had to create 
an "artificial user", which is a big pain, who owns 
the files installed because Distutils doesn't work 
right when the file has group write but is owned by 
another developer.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 13:34

Message:
Logged In: YES 
user_id=3066

Paul, have you had a chance to look at my proposed fix?

I'm marking this as "pending" for now.  It will be
automatically reopened when you respond.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-05 10:58

Message:
Logged In: YES 
user_id=3066

Paul,

I think I see what's happening.  In distutils/command/build_scripts.py, at the end of the copy_scripts() method, there is a call to self.copy_file().  You should be able to add a keyword parameter preserve_mode=0 to that to fix this.  If that is not sufficient, please let me know.  (The existing build and installation of your package will need to have the write bit enabled before this will work, unfortunately, but this should take care of future installations.)

Please report your results, and I'll get this checked in if it is sufficient.  Thanks!

----------------------------------------------------------------------

Comment By: Paul F. Dubois (dubois)
Date: 2001-08-05 10:32

Message:
Logged In: YES 
user_id=5550

Attached is a file with the details on the report.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-03 20:54

Message:
Logged In: YES 
user_id=3066

Assigned to me, since Paul has asked me about this and I
don't want to keep that mail in my inbox forever.

Paul, please tell me exactly what you're seeing:  what
permissions are set on the file in the source directory,
what's the umask you're using, and what are the final
permissions of the installed file.  The only thing that the
install_scripts command appears to be doing is ensuring that
the executable bit is set.

Is the "group-sticky" bit set in the destination directory?
 How do the identities of the installer relate to the
owner/group of the destination directory?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-07 13:04

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414316&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 22:00:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 14:00:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-449613 ] Mapping Type "in" and "not in" operators
Message-ID: <E15Uwui-0005J2-00@usw-sf-web3.sourceforge.net>

Bugs item #449613, was opened at 2001-08-09 14:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Mapping Type "in" and "not in" operators

Initial Comment:
According to the Python 2.1 documentation, Mapping 
Types support the "in" and "not in" operation.
http://www.python.org/doc/current/lib/typesmapping.html

But it doesn't work.  I tried the following:

>>> k = "key"
>>> a = { k : "value" }
>>> k in a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right 
argument

-Mike

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 22:05:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 14:05:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-449613 ] Mapping Type "in" and "not in" operators
Message-ID: <E15Ux0A-0005nF-00@usw-sf-web3.sourceforge.net>

Bugs item #449613, was opened at 2001-08-09 14:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470

>Category: Documentation
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Mapping Type "in" and "not in" operators

Initial Comment:
According to the Python 2.1 documentation, Mapping 
Types support the "in" and "not in" operation.
http://www.python.org/doc/current/lib/typesmapping.html

But it doesn't work.  I tried the following:

>>> k = "key"
>>> a = { k : "value" }
>>> k in a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right 
argument

-Mike

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-09 14:05

Message:
Logged In: YES 
user_id=31435

Changed to Docs and assigned to Fred.  The use of 
infix "in" with a mapping object is a new-in-2.2 feature.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 23:03:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 15:03:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-449613 ] Mapping Type "in" and "not in" operators
Message-ID: <E15Uxtg-0007lA-00@usw-sf-web3.sourceforge.net>

Bugs item #449613, was opened at 2001-08-09 14:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470

Category: Documentation
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Mapping Type "in" and "not in" operators

Initial Comment:
According to the Python 2.1 documentation, Mapping 
Types support the "in" and "not in" operation.
http://www.python.org/doc/current/lib/typesmapping.html

But it doesn't work.  I tried the following:

>>> k = "key"
>>> a = { k : "value" }
>>> k in a
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'in' or 'not in' needs sequence right 
argument

-Mike

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 15:03

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstdtypes.tex revision 1.52.4.3.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-09 14:05

Message:
Logged In: YES 
user_id=31435

Changed to Docs and assigned to Fred.  The use of 
infix "in" with a mapping object is a new-in-2.2 feature.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449613&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 23:26:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 15:26:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-442903 ] import Numeric fails on Linux
Message-ID: <E15UyGQ-0000Rr-00@usw-sf-web3.sourceforge.net>

Bugs item #442903, was opened at 2001-07-19 14:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442903&group_id=5470

Category: Extension Modules
>Group: 3rd Party
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: import Numeric fails on Linux

Initial Comment:
\h* python
Python 2.1.1c1 (#1, Jul 19 2001, 14:43:40) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import Numeric
BUG IN DYNAMIC LINKER ld.so: dynamic-link.h: 62:
elf_get_dynamic_info: Assertion `! "bad dynamic tag"'
failed!
\h* ^D


Python was compiled on a Debian Linux system,
with 2.4.5 kernel.  It runs there, but creates the
above
error when the same code is run on a Red Hat system
with a 2.4.0 kernel.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:59

Message:
Logged In: YES 
user_id=31392

Have you tried contacting the Numeric team?  This doesn't
look like it was anything to do with Python.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442903&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 23:28:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 15:28:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-434199 ] ftplib changes CRLF to LF on Windows
Message-ID: <E15UyHt-0000T5-00@usw-sf-web3.sourceforge.net>

Bugs item #434199, was opened at 2001-06-18 08:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434199&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib changes CRLF to LF on Windows

Initial Comment:
Version 2.0 
Putting a file to an FTP server (NT 4.0)
seems to change the line endings from CRLF to LF only.
It does not matter if the transfer is ascii or binary.



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-09 15:28

Message:
Logged In: YES 
user_id=31392

Closed for lack of information


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-06-18 11:56

Message:
Logged In: YES 
user_id=6380

Sorry, there's not enough information in this bug report to
be able to track it down.  Can you show a brief
self-contained program that demonstrates the bug?

Since ftplib doesn't open the file to be transferred, my
suspicion is that the problem is actually in your code
calling ftplib: if you used ``f = open(filename, "r")'' to
open the file that you pass to ftplib's storbinary() method,
you are opening it in text mode.  Try ``f = open(filename,
"rb")'' to open it in binary mode.

Please report back here otherwise we'll close this bug
report next week for lack of information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434199&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 23:29:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 15:29:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-416039 ] pstats browser crashes
Message-ID: <E15UyJC-0000UF-00@usw-sf-web3.sourceforge.net>

Bugs item #416039, was opened at 2001-04-13 15:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Eric S. Raymond (esr)
Summary: pstats browser crashes

Initial Comment:
My very first attempt to use the pstats browser failed
immediately.

w221:~/src/python/dist/src/Tools/compiler> python2.1
../../Lib/pstats.py compiler/__init__.py.prof 
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF             add             callees        
callers         quit           
read            reverse         sort           
stats           strip           

Undocumented commands:
======================
help            

% callers
Traceback (most recent call last):
  File "../../Lib/pstats.py", line 646, in ?
    ProfileBrowser(initprofile).cmdloop()
  File "../../Lib/cmd.py", line 86, in cmdloop
    stop = self.onecmd(line)
  File "../../Lib/cmd.py", line 124, in onecmd
    return func(arg)
  File "../../Lib/pstats.py", line 580, in do_callers
    return self.generic('callers', line)
  File "../../Lib/pstats.py", line 563, in generic
    apply(getattr(self.stats, fn), processed)
AttributeError: Stats instance has no attribute
'callers'

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-09 15:29

Message:
Logged In: YES 
user_id=31392

I think this was fixed but no one closed the bug report.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:16

Message:
Logged In: YES 
user_id=6380

Jeremy, since you reported the problem, it is at least
polite to report whether the applied fix made your problem
go away.  Did it? (Eric *did* check something in that
claimed to deal with a reported bug.) 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-17 18:09

Message:
Logged In: YES 
user_id=31392

Eric-- If you fixed the bug, please close the bug report.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470


From noreply@sourceforge.net  Thu Aug  9 23:29:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 15:29:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-416039 ] pstats browser crashes
Message-ID: <E15UyJS-0000UO-00@usw-sf-web3.sourceforge.net>

Bugs item #416039, was opened at 2001-04-13 15:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Eric S. Raymond (esr)
Summary: pstats browser crashes

Initial Comment:
My very first attempt to use the pstats browser failed
immediately.

w221:~/src/python/dist/src/Tools/compiler> python2.1
../../Lib/pstats.py compiler/__init__.py.prof 
Welcome to the profile statistics browser.
% help

Documented commands (type help <topic>):
========================================
EOF             add             callees        
callers         quit           
read            reverse         sort           
stats           strip           

Undocumented commands:
======================
help            

% callers
Traceback (most recent call last):
  File "../../Lib/pstats.py", line 646, in ?
    ProfileBrowser(initprofile).cmdloop()
  File "../../Lib/cmd.py", line 86, in cmdloop
    stop = self.onecmd(line)
  File "../../Lib/cmd.py", line 124, in onecmd
    return func(arg)
  File "../../Lib/pstats.py", line 580, in do_callers
    return self.generic('callers', line)
  File "../../Lib/pstats.py", line 563, in generic
    apply(getattr(self.stats, fn), processed)
AttributeError: Stats instance has no attribute
'callers'

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-09 15:29

Message:
Logged In: YES 
user_id=31392

I think this was fixed but no one closed the bug report.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-17 21:16

Message:
Logged In: YES 
user_id=6380

Jeremy, since you reported the problem, it is at least
polite to report whether the applied fix made your problem
go away.  Did it? (Eric *did* check something in that
claimed to deal with a reported bug.) 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-17 18:09

Message:
Logged In: YES 
user_id=31392

Eric-- If you fixed the bug, please close the bug report.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416039&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 06:31:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 22:31:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-231540 ] threads and profiler don't work together
Message-ID: <E15V4sv-0007le-00@usw-sf-web3.sourceforge.net>

Bugs item #231540, was opened at 2001-02-08 07:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231540&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Dave Brueck (dbrueck)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: threads and profiler don't work together

Initial Comment:
When a new thread is created, it doesn't inherit from the parent thread the trace and profile functions (sys_tracefunc and sys_profilefunc in PyThreadState), so multithreaded programs can't easily be profiled. 

This may be by design for safety/complexity sake, but the profiler module should still find some way to function correctly. A temporary (and performance-killing) workaround is to modify the standard profiler to hook into threads to start a new profiler for each new thread, and then merge the stats from a child thread into the parent's when the child thread ends.

Here is sample code that exhibits the problem. Stats are printed only for the main thread because the child thread has no profiling function and therefore collects no stats:

import threading, profile, time

def yo():
    for j in range(5):
        print j,

def go():
    threading.Thread(target=yo).start()
    time.sleep(1)

profile.run('go()')


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-09 22:31

Message:
Logged In: YES 
user_id=31435

Reassigned to Fred, our current profiler expert.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:57

Message:
Assigned to me but reduced the priority.  I'll take a look at it, but have to suspect it will get reclassified as a Feature Request and moved into PEP 42.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231540&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 06:32:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 09 Aug 2001 22:32:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-446525 ] python 2.1 debug library missing _sre?
Message-ID: <E15V4uN-0007mT-00@usw-sf-web3.sourceforge.net>

Bugs item #446525, was opened at 2001-07-31 12:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470

Category: Windows
>Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: python 2.1 debug library missing _sre?

Initial Comment:
I downloaded the most current python 2.1 debug library 
as follows:

Python-2.1-Debug.zip    16-Apr-2001 23:06   1.3M  ZIP 
archive

After initialization of the interpreter, a simple call 
like "PyRun_SimpleString("import re");" will return 
the following error:

Traceback (most recent call last):
...
  File "c:\python21\lib\sre_compile.py", line 11, in ?
    import _sre
ImportError: No module named _sre

By comparision, running the same code using the Python 
Release library gives no such problem.

Is this a bug? 

Much Thanks,
Hugo

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-09 22:32

Message:
Logged In: YES 
user_id=31435

Closed for lack of requested followup.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-01 13:20

Message:
Logged In: YES 
user_id=31435

Not enough info.  You downloaded the .zip file, and *then* 
what?  Did you unpack it?  If so, to where?  Note that the 
zip file is captured from a build tree, not a release tree.

Then what?  I don't know how you run your app, or how you 
compile it, or really anything else relevant.  Try running 
python_d with -vv to see *where* it's looking for _sre.  
Also try getting your own extensions out of the picture.

Note that I'm no longer going to ship the ...-Debug.zip 
file in 2.2, as tracking down misuses of it is a time 
sink.  If you want to build things in debug mode, much 
better to compile Python yourself from the source release.

In the meantime, if you want help with this, I'm afraid 
you're going to have attach enough files and info to this 
report so that I can reproduce your problem on my machine.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446525&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 09:58:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 01:58:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4
Message-ID: <E15V87n-0007BF-00@usw-sf-web3.sourceforge.net>

Bugs item #438786, was opened at 2001-07-05 07:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Martin v. Lіwis (loewis)
Summary: CVS 2.1.1c1 broken on osf1V4

Initial Comment:
As of right now, the CVS branch for the 2.1 bugfix
release cannot import the math module on my Digital
Unix platform.

ImportError: Unresolved symbol in
/tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so:
__eprintf

uname is

OSF1 surya V4.0 878 alpha



----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 01:58

Message:
Logged In: YES 
user_id=21627

Ok, I have committed your setup.py patch as 1.47.

I still cannot see the problem solved with the
Makefile.pre.in. If I set CC to 'foo' and invoke make,
setup.py will still use 'gcc', not 'foo'. The reason is that
make passes all variables that where in the original
environment to subprocesses; if they were overwritten in the
Makefile, it will pass the new values (unless -e was
specified).

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:38

Message:
Logged In: YES 
user_id=11365

Thanks for your work on this. I'll try and explain about
setup.py etc.

If you look in
distutils.sysconfig.customize_compiler(compiler)

you will see that the command line for compiling shared
libraries is built up from Makefile variables like so:

$(CC) $(OPT) $(CCSHARED)

which is consistent with the traditional operation of the
python Makefile.

The problem with setup.py is that it does not recognize
the importance of the $(OPT) variable.  Before the
extensions are built it decides to recreate the compilation
command line using the current environment variables (I
doubt this is a worthwhile thing to do, but anyway...)
and if it finds $CC in the environment it effectively
defines the command line to be 

$(CC) $(CCSHARED)

i.e. $(OPT) has disappeared, and the CC variable is expected
to take on its role.

This is inconsistent with
1) The way distutils normally treats $(CC)
2) The way the Makefile uses $(CC)
3) The way make interprets $CC in the environment
4) The way configure interprets $CC in the environment.

Now until fairly recently there was no setup.py in the
python build process.  If you set CC=gcc in the environment
it would be interpreted consistently as in 2/3/4 above,
specifically, *not* implying that you wished not to use the
$(OPT) variable in the Makefile.

Ok, so let's assume that I didn't know that this was a bad
idea and kept doing it with the new python build.  At the
last step of building the shared modules, the value of
$(OPT) is discarded.  This is probably something like

OPT = -g -O3 -Wall -Wstrict-prototypes

so the shared modules are built without optimisation or
compiler warnings turned on.  Ok, I admit this doesn't break
the build.  But it could harm the performance of one's
python install noticeably.

So, my patch addresses this in a minimal way.  The
optimization flags OPT from distutils.sysconfig are retained
in the new commandline.  That's all.

This is really just a slight generalization of the patch
attached to #437487 which made sure that $(CCSHARED) was
retained in the commandline... omitting it broke the build
very badly in some cases.

Finally, the patch I was thinking about to Makefile.pre.in
addresses this comment in setup.py

# When you run "make CC=altcc" or something similar, you
# really want those environment variables passed into the
# setup.py phase.  Here's a small set of useful ones.

The problem is that just because a variable is in the
environment does *not* mean that it was passed as an
argument to make.  It is unfortunate that that's the way
make passes on variables, and it can't be disambiguated.

Make itself of course *doesn't* accept CC from the
environment since that is overridden by an assigment in the
Makefile.  So the make part of the build and the setup.py
part of the build become inconsistent.

This caused the original problem on OSF1V4: configure looked
at $CC and decided it was to be ignored.  Setup.py had no
clue that this decision had been made, and reinstated it.
The result was that the dynamic modules were linked with
the wrong libraries.

The fix I thought about was this:  when invoking setup.py
from the Makefile, explicitly pass CC (and LDSHARED which is
treated the same) in its environment.
My second attempt is attached here - it quotes the variables
which is needed of course...
What would be better is if you could give a commandline
argument to setup.py.  The help says that there is a
--compiler (-c) option to the build command.


That is not currently helpful though.  I tried
./python setup.py build -c gcc
and saw

    raise DistutilsPlatformError, msg
distutils.errors.DistutilsPlatformError: don't know how to
compile C/C++ code on platform 'posix' with 'gcc' compiler

which is unfortunate...

So that about covers it, I hope.



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-25 00:48

Message:
Logged In: YES 
user_id=21627

osf.patch was committed as 1.235. As for the changes to
setup.py and Makefile.pre.in: I cannot understand what
problem they solve. Please demonstrate the bug that is fixed
with these changes in more detail (i.e. what is the setting
of your environment variables, and what unexpected results
do you get without these changes). 

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 14:39

Message:
Logged In: YES 
user_id=11365

I tried testing that patch and it sucked.
I'll try again.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:06

Message:
Logged In: YES 
user_id=11365

Doh! Now it's uploaded. Sorry for the extra traffic.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:05

Message:
Logged In: YES 
user_id=11365

Next patch uploaded.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:04

Message:
Logged In: YES 
user_id=11365

Yes, the patch works and make test fails only on
test_format, I believe this is a known platform C library
bug.

I have attached a patch for the setup.py in python/dist/src.

It touches code which is supposed to allow variables set on
the make commandline to have effect.  I see two issues with
it.

One,  it effectively replaces CC and OPT from the Makefile
with just CC.  This is inconsistent with the behaviour of
the Makefile and configure.  My setup.patch addresses this.

Two, it doesn't really do what it says, because the variable
it picks up from the environment can has not necessarily got
there through a commandline argument to make.  This only
becomes a problem when configure decides to ignore an
environment variable, as was the case on OSF.  Martin's
patch stops this from happening on OSF, but the code is
still fragile.

Here's an idea:  make should always export its value of CC
into the environment of subprocesses.  Using Gnu make I'd do
this with an 'export' directive.  I'll next send a patch to
Makefile.pre.in which should do the job portably but it
isn't especially pretty. 



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-24 00:11

Message:
Logged In: YES 
user_id=21627

Gregory, can you please try the attached patch, and report 
whether it changes anything?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 13:33

Message:
Logged In: YES 
user_id=6380

I don't recall why that was.  It was 6 years ago!  Quite
possibly things have changed; the OSF in use now is probably
quite different than the one then.

So, Martin, try to back out the change and see if this
doesn't break other things.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-19 12:38

Message:
Logged In: YES 
user_id=21627

This seems to originate fromt the fragment

	OSF1)	CC=cc
		without_gcc=;;

which was introduced in configure.in 1.23, with the comment

on osf/1, never use gcc

Therefore, I'm assigning it to Guido. My proposal is to 
close this as "won't fix" - if setting CC doesn't work, 
just don't do that.

Alternatively, if nobody can remember why gcc should not 
be used on OSF/1, it might be reasonable to back-out this 
change.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-19 12:12

Message:
Logged In: YES 
user_id=11365

I just checked out the 2.1.1 branch again and
it still seems to be broken.  After a fresh config with $CC
set to gcc in the environment, the Makefile contains

CC=             cc
OPT=            -O -Olimit 1500
CCSHARED=

so it looks like configure has decided to use cc and
chosen flags for that compiler.

Then, the actual build command lines look like

gcc -I.
-I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o

i.e. just "gcc" instead of "cc -O -Olimit 1500"

so it looks like the environment variable gets pulled in
only at the last moment and replaces $(CC), $(OPT) and
possibly $(CCSHARED), thereby throwing away the work done by
configure. 



----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:59

Message:
Logged In: YES 
user_id=34209

Gregory, did you get a chance to test the patch attached to
bug #437487, or the 2.1.1 CVS tree ? I'd like to know if
this is fixed in 2.1.1.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:56

Message:
Logged In: YES 
user_id=34209

Ah, yes, that sounds very plausible. The fix for that
problem, which was checked in on the trunk, will be in
Python 2.1.1-final as well. The Solaris bugreport has a
patch attached to it; could you test it to see if it solves
your 2.1.1c1 problem ?


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-09 08:48

Message:
Logged In: YES 
user_id=11365

The problem goes away if I clear $CC instead of having it
set to gcc.  There's a similar problem on Solaris reported
recently.
I think the configure script should try to spot this sort of
thing,
but I suppose that's an Autoconf feature request, not a
python bug...

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-08 14:06

Message:
Logged In: YES 
user_id=21627

This sounds like a bug in your compiler installation. 
__eprintf is typically defined in libgcc.a; make sure you 
use a consistent compiler capable of building binaries for 
your system throughout the build process.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 10:23:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 02:23:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-421878 ] File in a directory with a special chara
Message-ID: <E15V8Vp-0005k9-00@usw-sf-web1.sourceforge.net>

Bugs item #421878, was opened at 2001-05-06 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421878&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gсbor BORGULYA (borgulya)
Assigned to: Martin v. Lіwis (loewis)
Summary: File in a directory with a special chara

Initial Comment:
Using IDLE I tryed to save my work in the directory

C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt

but it failed:

Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
IDLE 0.8 -- press F1 for help
>>> Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\program files\python21\lib\lib-tk\Tkinter.py", line 1285, in __call__
    return apply(self.func, args)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 145, in save_a_copy
    self.writefile(filename)
  File "C:\PROGRA~1\Python21\Tools\idle\IOBinding.py", line 152, in writefile
    f = open(filename, "w")
UnicodeError: ASCII encoding error: ordinal not in range(128)

After a log of tries I have renamed the directory: (sajat instead of sajсt)

C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt

and the file was finally saved.

I use WIN2000P.

I hope you can fix it.

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 02:23

Message:
Logged In: YES 
user_id=21627

It works flawlessly in 2.2a1, probably due to the Unicode
file encoding support, so I close this as "fixed".

----------------------------------------------------------------------

Comment By: Gсbor BORGULYA (borgulya)
Date: 2001-05-09 10:31

Message:
Logged In: YES 
user_id=131307

Summary:
IDLE couldn't save into the directory
  C:\Documents and Settings\tdk.000\Dokumentumok\python\sajсt
but when it was renamed to
  C:\Documents and Settings\tdk.000\Dokumentumok\python\sajat
(without the accent above the last "a") it suceeded.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421878&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 11:15:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 03:15:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-449761 ] PyFile_WriteString has 2 args
Message-ID: <E15V9KN-00027h-00@usw-sf-web3.sourceforge.net>

Bugs item #449761, was opened at 2001-08-10 03:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449761&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyFile_WriteString has 2 args

Initial Comment:
http://www.python.org/doc/current/api/fileObjects.html,
 and all equivalent pages in older docs, say that 
PyFile_WriteString has 3 arguments, but it only has 2 -
- no 'flags' argument appies.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449761&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 11:22:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 03:22:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15V9R7-0008AJ-00@usw-sf-web1.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Martin v. Lіwis (loewis)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

>Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:22

Message:
Logged In: YES 
user_id=292642

The patch doesn't work, I'm afraid. RedHat 5 doesn't support
sockaddr_ll:

Python-2.1.1/Modules/socketmodule.c:391: field `ll' has
incomplete type

(By the way, RedHat 5 is libc 6 -- it's just glibc 2.0,
rather than 2.1.)

I think the proper solution would be to turn the AF_PACKET
support into an autoconf feature test, rather than a test
for the AF_PACKET and linux defines. A quicker hack is the
attached patch (plus the changes to configure.in and
pyconfig.h) which just undefines AF_PACKET if there is no
netpacket/packet.h.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 11:24:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 03:24:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15V9SX-0008Bc-00@usw-sf-web1.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Martin v. Lіwis (loewis)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

>Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:24

Message:
Logged In: YES 
user_id=292642

Oops, missed the tick box to attach the file...

----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:22

Message:
Logged In: YES 
user_id=292642

The patch doesn't work, I'm afraid. RedHat 5 doesn't support
sockaddr_ll:

Python-2.1.1/Modules/socketmodule.c:391: field `ll' has
incomplete type

(By the way, RedHat 5 is libc 6 -- it's just glibc 2.0,
rather than 2.1.)

I think the proper solution would be to turn the AF_PACKET
support into an autoconf feature test, rather than a test
for the AF_PACKET and linux defines. A quicker hack is the
attached patch (plus the changes to configure.in and
pyconfig.h) which just undefines AF_PACKET if there is no
netpacket/packet.h.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 15:33:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 07:33:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-449761 ] PyFile_WriteString has 2 args
Message-ID: <E15VDLr-0001nP-00@usw-sf-web1.sourceforge.net>

Bugs item #449761, was opened at 2001-08-10 03:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449761&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyFile_WriteString has 2 args

Initial Comment:
http://www.python.org/doc/current/api/fileObjects.html,
 and all equivalent pages in older docs, say that 
PyFile_WriteString has 3 arguments, but it only has 2 -
- no 'flags' argument appies.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 07:33

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/api/api.tex revision 1.137.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449761&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 16:10:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 08:10:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4
Message-ID: <E15VDvq-0005fL-00@usw-sf-web3.sourceforge.net>

Bugs item #438786, was opened at 2001-07-05 07:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Martin v. Lіwis (loewis)
Summary: CVS 2.1.1c1 broken on osf1V4

Initial Comment:
As of right now, the CVS branch for the 2.1 bugfix
release cannot import the math module on my Digital
Unix platform.

ImportError: Unresolved symbol in
/tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so:
__eprintf

uname is

OSF1 surya V4.0 878 alpha



----------------------------------------------------------------------

>Comment By: Gregory H. Ball (greg_ball)
Date: 2001-08-10 08:10

Message:
Logged In: YES 
user_id=11365

Ok, I'll withdraw that patch.  (I already tried to delete at
least on of those files, but without luck...) 
The source of the confusion is the following. In a nutshell,
my vendor make is broken.
Here are a couple of tiny files.

# contents of test.mk
FOO=hello
dothis:
	python showFOO.py
# end of test.mk
# contents of showFOO.py
import os
print os.environ.get('FOO')
# end of showFOO.py

Now lets try them out (OSF1V4)

surya:~/stuff>setenv FOO goodbye
surya:~/stuff>make -f test.mk
python showFOO.py
goodbye
surya:~/stuff>gmake -f test.mk
python showFOO.py
hello
surya:~/stuff>

So GNU Make shows the nice behaviour you just described
(so does my vendor make on Solaris.)  But the vendor make
on OSF1V4 does not.  The GNU make manual does seem to
mention the environment stuff under "features of GNU Make".

Perhaps the potential for problems with this make could be
mentioned in the README file.  Is OSF1V4 the same thing as
DEC Unix?  

Thanks.


----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 01:58

Message:
Logged In: YES 
user_id=21627

Ok, I have committed your setup.py patch as 1.47.

I still cannot see the problem solved with the
Makefile.pre.in. If I set CC to 'foo' and invoke make,
setup.py will still use 'gcc', not 'foo'. The reason is that
make passes all variables that where in the original
environment to subprocesses; if they were overwritten in the
Makefile, it will pass the new values (unless -e was
specified).

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:38

Message:
Logged In: YES 
user_id=11365

Thanks for your work on this. I'll try and explain about
setup.py etc.

If you look in
distutils.sysconfig.customize_compiler(compiler)

you will see that the command line for compiling shared
libraries is built up from Makefile variables like so:

$(CC) $(OPT) $(CCSHARED)

which is consistent with the traditional operation of the
python Makefile.

The problem with setup.py is that it does not recognize
the importance of the $(OPT) variable.  Before the
extensions are built it decides to recreate the compilation
command line using the current environment variables (I
doubt this is a worthwhile thing to do, but anyway...)
and if it finds $CC in the environment it effectively
defines the command line to be 

$(CC) $(CCSHARED)

i.e. $(OPT) has disappeared, and the CC variable is expected
to take on its role.

This is inconsistent with
1) The way distutils normally treats $(CC)
2) The way the Makefile uses $(CC)
3) The way make interprets $CC in the environment
4) The way configure interprets $CC in the environment.

Now until fairly recently there was no setup.py in the
python build process.  If you set CC=gcc in the environment
it would be interpreted consistently as in 2/3/4 above,
specifically, *not* implying that you wished not to use the
$(OPT) variable in the Makefile.

Ok, so let's assume that I didn't know that this was a bad
idea and kept doing it with the new python build.  At the
last step of building the shared modules, the value of
$(OPT) is discarded.  This is probably something like

OPT = -g -O3 -Wall -Wstrict-prototypes

so the shared modules are built without optimisation or
compiler warnings turned on.  Ok, I admit this doesn't break
the build.  But it could harm the performance of one's
python install noticeably.

So, my patch addresses this in a minimal way.  The
optimization flags OPT from distutils.sysconfig are retained
in the new commandline.  That's all.

This is really just a slight generalization of the patch
attached to #437487 which made sure that $(CCSHARED) was
retained in the commandline... omitting it broke the build
very badly in some cases.

Finally, the patch I was thinking about to Makefile.pre.in
addresses this comment in setup.py

# When you run "make CC=altcc" or something similar, you
# really want those environment variables passed into the
# setup.py phase.  Here's a small set of useful ones.

The problem is that just because a variable is in the
environment does *not* mean that it was passed as an
argument to make.  It is unfortunate that that's the way
make passes on variables, and it can't be disambiguated.

Make itself of course *doesn't* accept CC from the
environment since that is overridden by an assigment in the
Makefile.  So the make part of the build and the setup.py
part of the build become inconsistent.

This caused the original problem on OSF1V4: configure looked
at $CC and decided it was to be ignored.  Setup.py had no
clue that this decision had been made, and reinstated it.
The result was that the dynamic modules were linked with
the wrong libraries.

The fix I thought about was this:  when invoking setup.py
from the Makefile, explicitly pass CC (and LDSHARED which is
treated the same) in its environment.
My second attempt is attached here - it quotes the variables
which is needed of course...
What would be better is if you could give a commandline
argument to setup.py.  The help says that there is a
--compiler (-c) option to the build command.


That is not currently helpful though.  I tried
./python setup.py build -c gcc
and saw

    raise DistutilsPlatformError, msg
distutils.errors.DistutilsPlatformError: don't know how to
compile C/C++ code on platform 'posix' with 'gcc' compiler

which is unfortunate...

So that about covers it, I hope.



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-25 00:48

Message:
Logged In: YES 
user_id=21627

osf.patch was committed as 1.235. As for the changes to
setup.py and Makefile.pre.in: I cannot understand what
problem they solve. Please demonstrate the bug that is fixed
with these changes in more detail (i.e. what is the setting
of your environment variables, and what unexpected results
do you get without these changes). 

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 14:39

Message:
Logged In: YES 
user_id=11365

I tried testing that patch and it sucked.
I'll try again.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:06

Message:
Logged In: YES 
user_id=11365

Doh! Now it's uploaded. Sorry for the extra traffic.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:05

Message:
Logged In: YES 
user_id=11365

Next patch uploaded.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:04

Message:
Logged In: YES 
user_id=11365

Yes, the patch works and make test fails only on
test_format, I believe this is a known platform C library
bug.

I have attached a patch for the setup.py in python/dist/src.

It touches code which is supposed to allow variables set on
the make commandline to have effect.  I see two issues with
it.

One,  it effectively replaces CC and OPT from the Makefile
with just CC.  This is inconsistent with the behaviour of
the Makefile and configure.  My setup.patch addresses this.

Two, it doesn't really do what it says, because the variable
it picks up from the environment can has not necessarily got
there through a commandline argument to make.  This only
becomes a problem when configure decides to ignore an
environment variable, as was the case on OSF.  Martin's
patch stops this from happening on OSF, but the code is
still fragile.

Here's an idea:  make should always export its value of CC
into the environment of subprocesses.  Using Gnu make I'd do
this with an 'export' directive.  I'll next send a patch to
Makefile.pre.in which should do the job portably but it
isn't especially pretty. 



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-24 00:11

Message:
Logged In: YES 
user_id=21627

Gregory, can you please try the attached patch, and report 
whether it changes anything?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 13:33

Message:
Logged In: YES 
user_id=6380

I don't recall why that was.  It was 6 years ago!  Quite
possibly things have changed; the OSF in use now is probably
quite different than the one then.

So, Martin, try to back out the change and see if this
doesn't break other things.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-19 12:38

Message:
Logged In: YES 
user_id=21627

This seems to originate fromt the fragment

	OSF1)	CC=cc
		without_gcc=;;

which was introduced in configure.in 1.23, with the comment

on osf/1, never use gcc

Therefore, I'm assigning it to Guido. My proposal is to 
close this as "won't fix" - if setting CC doesn't work, 
just don't do that.

Alternatively, if nobody can remember why gcc should not 
be used on OSF/1, it might be reasonable to back-out this 
change.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-19 12:12

Message:
Logged In: YES 
user_id=11365

I just checked out the 2.1.1 branch again and
it still seems to be broken.  After a fresh config with $CC
set to gcc in the environment, the Makefile contains

CC=             cc
OPT=            -O -Olimit 1500
CCSHARED=

so it looks like configure has decided to use cc and
chosen flags for that compiler.

Then, the actual build command lines look like

gcc -I.
-I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o

i.e. just "gcc" instead of "cc -O -Olimit 1500"

so it looks like the environment variable gets pulled in
only at the last moment and replaces $(CC), $(OPT) and
possibly $(CCSHARED), thereby throwing away the work done by
configure. 



----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:59

Message:
Logged In: YES 
user_id=34209

Gregory, did you get a chance to test the patch attached to
bug #437487, or the 2.1.1 CVS tree ? I'd like to know if
this is fixed in 2.1.1.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:56

Message:
Logged In: YES 
user_id=34209

Ah, yes, that sounds very plausible. The fix for that
problem, which was checked in on the trunk, will be in
Python 2.1.1-final as well. The Solaris bugreport has a
patch attached to it; could you test it to see if it solves
your 2.1.1c1 problem ?


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-09 08:48

Message:
Logged In: YES 
user_id=11365

The problem goes away if I clear $CC instead of having it
set to gcc.  There's a similar problem on Solaris reported
recently.
I think the configure script should try to spot this sort of
thing,
but I suppose that's an Autoconf feature request, not a
python bug...

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-08 14:06

Message:
Logged In: YES 
user_id=21627

This sounds like a bug in your compiler installation. 
__eprintf is typically defined in libgcc.a; make sure you 
use a consistent compiler capable of building binaries for 
your system throughout the build process.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 16:58:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 08:58:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-449093 ] docs need to discuss // and __future__.division
Message-ID: <E15VEfi-0002rs-00@usw-sf-web2.sourceforge.net>

Bugs item #449093, was opened at 2001-08-08 05:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: docs need to discuss // and __future__.division

Initial Comment:
The operator needs to get new interfaces added in
support of truediv and floordiv.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 08:58

Message:
Logged In: YES 
user_id=3066

Added documentation for the operator.floordiv() and
operator.truediv() in Doc/lib/liboperator.tex revision 1.20.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-09 13:22

Message:
Logged In: YES 
user_id=3066

Added floordiv() and truediv() in Modules/operator.c
revision 2.18.  There's still plenty of documentation to be
written regarding the changes in division, so I'm
re-classifying this as a documentation request.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 05:40

Message:
Logged In: YES 
user_id=6380

Also a reminder for Fred to add more docs for this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449093&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 18:04:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 10:04:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-449854 ] make failing on OS X 10.0.4
Message-ID: <E15VFiB-0005Kw-00@usw-sf-web2.sourceforge.net>

Bugs item #449854, was opened at 2001-08-10 10:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449854&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: make failing on OS X 10.0.4

Initial Comment:
Trying to do 'make' again on 10.0.4 with CVS 
current as of this morning. I get all the way down 
to:
ranlib libpython2.2.a
cc  -u __dummy -u _PyMac_Error -framework 
System -framework Foundation -framework 
Carbon -o python \
                Modules/python.o \
                libpython2.2.a -lpthread -ldl      
/usr/bin/ld: can't create output file: python (Is a 
directory, errno = 21)
make: *** [python] Error 1

Is this a flaw in the Makefile or is it a "feature" of 
Mac OS X being on HFS+ (which is NOT case 
sensitive)? Either way, I looked at the Makefile and 
had no idea where to even try to attempt a change. 
Any suggestions?

-John Buell

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449854&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 18:38:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 10:38:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-449258 ] inspect.stack() refcount problem
Message-ID: <E15VGEo-0006yr-00@usw-sf-web2.sourceforge.net>

Bugs item #449258, was opened at 2001-08-08 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: W. Eliot Kimber (drmacro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inspect.stack() refcount problem

Initial Comment:
The attached code exhibits the problem: Calling a 
function that assigns the results of inspect.stack() 
to a local variable causes an extra ref to objects in 
the caller's space. Not doing the assignment does not 
cause the problem.

Appears that the stack frame is disrupting the 
reference counting in some way.

Tested with Python 2.1 and 2.1.1

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 10:38

Message:
Logged In: YES 
user_id=3066

Added warning in the inspect documentation as
Doc/lib/libinspect.tex revision 1.4.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 15:21

Message:
Logged In: YES 
user_id=20438

I understand your point, but I disagree with it wrt GC.

Assuming I am willing to take on the cost/risk of using 
sys._getframe() I should be able to find documentation 
that describes at least minimally the risks related to GC, 
threads, and recursion.  This is because I don't want to 
become a Python master, just use the language well to make 
my job easier.

For example, I am making use of sys._getframe() to make 
coding an Interceptor pattern less mind numbing.  I 
recognize that I need to be careful - and previously have 
even gone so far into the code as to provide a Python 
patch to implement sys._getframes().


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 14:06

Message:
Logged In: YES 
user_id=31435

Yes and no.  There are about 100 internal types implemented 
in C, and you've probably never even heard of most of them 
(heck, I bet even Guido wouldn't recognize the names of 
dozens of them).  So if we give you a giant list of which 
do and don't participate in gc, what good would it do you?

sys._getframe() starts with an underscore to scare you 
away:  it's an internal function that only experts should 
even think about using.

You're using inspect.stack(), and that's where the problem 
is:  if we expose a "high level" interface that isn't meant 
for experts only, then *that's* where cautions about cycles 
should appear, in its docs.  You need to know that 
inspect.stack can get you in trouble, but going on about 
internal implementation details isn't going to help -- the 
latter is at the wrong level for inspect.stack()'s users.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:26

Message:
Logged In: YES 
user_id=20438

tim_one, are you saying that the objects that do/don't 
participate in gc shouldn't be documented?!?

I'm certainly no expert in Python internals but I 
understand enough to know what that distinction means and 
would like to see the list documented for each release.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-08 13:16

Message:
Logged In: YES 
user_id=31435

__del__ only applies to objects coded *in* Python.  frame 
objects are coded in C, and __del__ isn't relevant to those.

Not all objects are tracked by gc, and the set of objects 
which are changes from release to release (it grows); even 
if that were documented, you'd never be able to keep it 
straight unless you were an expert too in how Python is 
implemented, and in all the implementation variations 
across releases.

Tracking an object type in gc has both memory and speed 
costs, so the pressure has been to do it only for object 
types highly likely to be involved in cycles.  Since you 
really can't get a cycle involving frame objects unless 
you're doing disgusting tricks <wink>, frame objects were 
left out of this subsystem.

In 2.2 that changes, though, because the addition of 
generators and iterators makes it more likely that a frame 
object can end up in a cycle even when you're not playing 
games with _getframe().  That is, frame objects in cycles 
will be collected by magic in 2.2 (they already are in the 
current CVS Python).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 13:10

Message:
Logged In: YES 
user_id=6380

In Python 2.1 and 2.1.1, frames are not GC'ed.

In Python 2.2 they will be (they are in CVS but they weren't
in 2.2a1).

I don't understand your question about __del__ methods.

I agree with the documentation question, but don't know
where best to add this.  I'll reopen this as a documentation
issue and assign to Fred.

----------------------------------------------------------------------

Comment By: John D. Heintz (jheintz)
Date: 2001-08-08 13:06

Message:
Logged In: YES 
user_id=20438

What about GC collection of circular references?

Which object in the cycle (frame or frame locals) 
implements a __del__() method?

At the least the documentation should be more clear about 
which builtins implement del and therefore are not 
collectable.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:45

Message:
Logged In: YES 
user_id=6380

Your attachment didn't work.

But don't bother.  The behavior you describe is not a bug.
It creates a circular reference.  If you don't want that,
don't use
inspect.stack() or sys._getframe() (which is the same
thing).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449258&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 19:14:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 11:14:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-443490 ] 2.2 Install on Linux/Mod Install Error
Message-ID: <E15VGoC-0000CP-00@usw-sf-web2.sourceforge.net>

Bugs item #443490, was opened at 2001-07-22 00:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470

Category: Installation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: 2.2 Install on Linux/Mod Install Error

Initial Comment:
*Start*

copying build/scripts/pydoc -> /usr/local/bin
changing mode of /usr/local/bin/pydoc to 100755
warning: install: modules installed 
to '/usr/local/lib/python2.1/lib-dynload/', which is 
not in Python's module search path (sys.path) -- 
you'll have to change the search path yourself

*End*


I do not know if this is a bug or not. Reinstalled 
many times with different ./configure options for 
Linux, and always gives the same error.

If I am wrong and it is only an error, I appologize. 
*I'm New* Please notify me via email of what I need to 
do to correct this issue is it is an error.

:?/

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 11:14

Message:
Logged In: YES 
user_id=11375

This is just a warning, and is harmless; while building 
itself, Python is using a sys.path of ./Lib, so when it 
installs things to /usr/local/, that directory isn't on 
sys.path, hence the warning.

This is fixed in Python 2.2a1.  You can just ignore the 
message printed by 2.1.1.



----------------------------------------------------------------------

Comment By: Allan Digiby (just_gnu_it)
Date: 2001-07-28 11:17

Message:
Logged In: YES 
user_id=277768

I'm only bugging him a he's my roomie.

It's an inside thing... newbie to the Linux world.

Me and my preferences rubbing off on others... :)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-22 08:23

Message:
Logged In: YES 
user_id=6380

To just_gnu_it, or Allan Digiby: there was no need to be
condescending.  Wait till we laugh at your bug reports.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-22 07:33

Message:
Logged In: YES 
user_id=6380

This is probably because there's already a Python installed
on your system (most Linux installations come with Python
1.5.2).

But the error message could be better.  Andrew, do you know
more about this?  Help a fellow Canadian. :-)

----------------------------------------------------------------------

Comment By: Allan Digiby (just_gnu_it)
Date: 2001-07-22 01:08

Message:
Logged In: YES 
user_id=277768

[quote]*I'm New* [/quote]

Below is proof enough of his claim.

LOL

:p

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-22 00:54

Message:
Logged In: NO 

Env: Linux 2.2.14

Email address is reginaravers@accesscomm.ca

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-22 00:52

Message:
Logged In: NO 

Oops...

Env: Linux 2.2.14

reginaravers@accesscomm.ca is my email address.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443490&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 19:28:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 11:28:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-449880 ] File size limit exceeded causes ABEND
Message-ID: <E15VH1Q-0003Lb-00@usw-sf-web1.sourceforge.net>

Bugs item #449880, was opened at 2001-08-10 11:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: File size limit exceeded causes ABEND

Initial Comment:
The following code will never run to completion on
systems with a 2GB file size limit. The interpreter
exits as soon as it exceeds the file size limit.

Create a file called "testfile" that is 2GB - 1 in
size. Run the following program to observe behaviour.

#!/usr/bin/env python2
#
# Create a file called "testfile" that is 2147483647
bytes in size. Then
# run this application. The python interpreter prints
the message "File
# size limit exceeded" and exits, rather than raising
an exception. 
#
# Tested with Python-2.1.1 on Red Hat 7.2 beta (Roswell)

fp = open('testfile', 'a')

try:
	fp.write('foo')
	fp.flush()
	fp.close()
except OSError, e:
	print e

print "done"



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:01:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:01:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-449880 ] File size limit exceeded causes ABEND
Message-ID: <E15VHX2-0004dJ-00@usw-sf-web1.sourceforge.net>

Bugs item #449880, was opened at 2001-08-10 11:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: File size limit exceeded causes ABEND

Initial Comment:
The following code will never run to completion on
systems with a 2GB file size limit. The interpreter
exits as soon as it exceeds the file size limit.

Create a file called "testfile" that is 2GB - 1 in
size. Run the following program to observe behaviour.

#!/usr/bin/env python2
#
# Create a file called "testfile" that is 2147483647
bytes in size. Then
# run this application. The python interpreter prints
the message "File
# size limit exceeded" and exits, rather than raising
an exception. 
#
# Tested with Python-2.1.1 on Red Hat 7.2 beta (Roswell)

fp = open('testfile', 'a')

try:
	fp.write('foo')
	fp.flush()
	fp.close()
except OSError, e:
	print e

print "done"



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:01

Message:
Logged In: YES 
user_id=6380

Yes, this is a bug.

It happens in the fp.flush() call.  This does a write() that
would cause the file size to exceed the limit, and such a
write receives a SIGXFSZ signal - a signal similar to
SIGPIPE.

A workaround is to do this before writing such a large file:

import signal
signal.signal(signal.SIGXFSZ, signal.SIG_IGN)

Python should ignore the SIGXFSZ signal, if it exists, just
like it ignores SIGPIPE.

I wonder, are there any other signals that we would want to
ignore like this?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:04:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:04:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-449880 ] File size limit exceeded causes ABEND
Message-ID: <E15VHZm-0004fc-00@usw-sf-web1.sourceforge.net>

Bugs item #449880, was opened at 2001-08-10 11:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: File size limit exceeded causes ABEND

Initial Comment:
The following code will never run to completion on
systems with a 2GB file size limit. The interpreter
exits as soon as it exceeds the file size limit.

Create a file called "testfile" that is 2GB - 1 in
size. Run the following program to observe behaviour.

#!/usr/bin/env python2
#
# Create a file called "testfile" that is 2147483647
bytes in size. Then
# run this application. The python interpreter prints
the message "File
# size limit exceeded" and exits, rather than raising
an exception. 
#
# Tested with Python-2.1.1 on Red Hat 7.2 beta (Roswell)

fp = open('testfile', 'a')

try:
	fp.write('foo')
	fp.flush()
	fp.close()
except OSError, e:
	print e

print "done"



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:04

Message:
Logged In: YES 
user_id=6380

Please try this patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:01

Message:
Logged In: YES 
user_id=6380

Yes, this is a bug.

It happens in the fp.flush() call.  This does a write() that
would cause the file size to exceed the limit, and such a
write receives a SIGXFSZ signal - a signal similar to
SIGPIPE.

A workaround is to do this before writing such a large file:

import signal
signal.signal(signal.SIGXFSZ, signal.SIG_IGN)

Python should ignore the SIGXFSZ signal, if it exists, just
like it ignores SIGPIPE.

I wonder, are there any other signals that we would want to
ignore like this?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:08:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:08:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-412271 ] licence/license confusion
Message-ID: <E15VHdZ-0001iE-00@usw-sf-web2.sourceforge.net>

Bugs item #412271, was opened at 2001-03-29 11:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412271&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: licence/license confusion

Initial Comment:
Thomas Heller points out:

Playing with the new meta info, I noticed that the
license specified in this way:
 
setup(..., license="MIT/X11", ...)
 
isn't recognized, while it works if one uses:
 
setup(..., licence="MIT/X11", ...)

BTW; according to www.opensource.org the MIT license
seems to be spelled MIT license nowadays, no longer
MIT/X11 license.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 12:08

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.48 of dist.py.  I've also edited PEP 
241 to just say "MIT license".



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-04-16 07:17

Message:
Logged In: YES 
user_id=11375

No, I wasn't planning to.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-13 08:46

Message:
Logged In: YES 
user_id=6380

andrew, were you going to fix this before 2.1?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=412271&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:08:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:08:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-416696 ] --with-threads fail for 2.1c2 on HPUX 11
Message-ID: <E15VHeH-00027S-00@usw-sf-web2.sourceforge.net>

Bugs item #416696, was opened at 2001-04-17 07:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470

Category: None
Group: Platform-specific
Status: Open
>Resolution: Out of Date
>Priority: 4
Submitted By: Harri Pasanen (harripasanen)
Assigned to: Guido van Rossum (gvanrossum)
Summary: --with-threads fail for 2.1c2 on HPUX 11

Initial Comment:
 ./configure --with-thread --without-gcc
.
.
.
checking for --with-threads... yes
checking for mach/cthreads.h... no
checking for --with-pth... no
checking for pthread_create in -lpthread... no
checking for pthread_detach... yes
.
.
.
 make test
.
.
.
test_thread
test test_thread crashed -- thread.error: can't start
new thread                
.
.
.

4 tests failed: test_asynchat test_fork1 test_thread
test_threadedtempfile

-- 

The cause here is that at link time -lpthread is not
included.  If I manually relink with -lpthread, then no
tests fail tests pass.
113 tests
OK.                                                                   

-Harri

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:08

Message:
Logged In: YES 
user_id=6380

Sorry, that patch no longer works.

Would you mind submitting a new patch that only does a
minimal change (rather than re-indenting a large block of
code)?

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-05-06 22:36

Message:
Logged In: YES 
user_id=119770

You can find a patch to fix this against python 2.1 at:
ftp://ftp.thewrittenword.com/outgoing/pub/python-2.1-416696.patch

You'll need to rerun autoconf to test.

This is a duplicate of bug #210665 (PR#360).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-19 15:16

Message:
Logged In: YES 
user_id=31435

Assigned to Guido.  Harri, can you supply a patch?  You 
seem to know what you're doing on this box, and nobody else 
does:  every release *something* about threads is broken on 
HPUX, and no patch submitted to date has ever cured this.  
No active Python developer runs HPUX, and I think we've all 
given up trying to sort out the conflicting claims of HP-UX 
users.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416696&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:11:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:11:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-417913 ] odd behavior when reloading "exceptions"
Message-ID: <E15VHhH-00074X-00@usw-sf-web3.sourceforge.net>

Bugs item #417913, was opened at 2001-04-21 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael Klatt (michaelklatt)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: odd behavior when reloading "exceptions"

Initial Comment:

After reloading the "exceptions" module, "exceptions.OSError" is not the same object as "os.error".

Let me illustrate by example:


# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os, exceptions
>>> os.error == exceptions.OSError
1
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> os.error == exceptions.OSError
0
>>>


Here's an example of how this could wreak havoc in a python script:

# ./python
Python 2.1 (#1, Apr 20 2001, 23:16:45) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
>>> import os
>>> import exceptions
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
exception caught
>>> reload(exceptions)
<module 'exceptions' (built-in)>
>>> 
>>> try:
...    os.stat("dummy")
... except os.error, e:
...     print "exception caught"
... 
Traceback (most recent call last):
  File "<stdin>", line 2, in ?
OSError: [Errno 2] No such file or directory: 'dummy'
>>> 


A quick test shows that this problem also occurred in python 1.5.2 and python 2.0.  I believe I 
understand why this is happening (when the exceptions module is reloaded, a new object for 
OSError is created), but I'm hoping someone has a creative solution.  

This will cause problems in any application which calls Py_NewInterpreter() (like mod_python).  
To verify this, add the following lines to Demo/embed/demo.c at line 36:

 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");
 
        Py_NewInterpreter(); 
        PyRun_SimpleString("import os,exceptions\n");
        PyRun_SimpleString("print os.error == exceptions.OSError\n");

The first comparison will result in 1, and the second will result in 0. 

Thanks!

Mike



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:11

Message:
Logged In: YES 
user_id=6380

This is the same problem as bug #449151, but it was easier
to fix this appearance: I simply prevented exceptions from
being reloaded. 

Fixed in CVS.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 09:00

Message:
Logged In: YES 
user_id=31392

It seems like a bug, except that it also seems obviously
correct <wink>.  Any opinion about whether we should fix
this?


----------------------------------------------------------------------

Comment By: Michael Klatt (michaelklatt)
Date: 2001-04-21 23:44

Message:
Logged In: YES 
user_id=201661


I did find a workaround for mod_python (and any application that uses Py_NewInterpreter()...).  I modified it 
to add this line after *every* call to Py_NewInterpreter()

PyRun_SimpleString("__import__(\os\).error = __import__(\exceptions\).OSError\n");

This is ugly, but it's a works.

Mike


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417913&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:17:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:17:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-422004 ] Missing "fixup" for "exceptions" module
Message-ID: <E15VHmG-00078f-00@usw-sf-web3.sourceforge.net>

Bugs item #422004, was opened at 2001-05-07 05:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422004&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jќrgen Hermann (jhermann)
>Assigned to: Barry Warsaw (bwarsaw)
>Summary: Missing "fixup" for "exceptions" module

Initial Comment:
The following call is missing in Py_Initialize():

*** pythonrun.c,1       Mon May  7 14:41:29 2001
--- pythonrun.c Mon May  7 14:42:39 2001
***************
*** 147,152 ****
--- 147,153 ----
 
        /* phase 2 of builtins */
        _PyImport_FixupExtension
("__builtin__", "__builtin__");
+       _PyImport_FixupExtension
("exceptions", "exceptions");
 
        initsigs(); /* Signal handling stuff, 
including initintr() */           

Without this patch, you might get this exception:

Traceback (most recent call last):
  File "/export/home/jhe/ns/httpd-
8332.195.226.107.82/cgi-bin/extest.py", line 1, in ?
    import exceptions
ImportError: Cannot re-init internal module 
exceptions                          

This bug was probably introduced when exception.py 
became a built-in extension module. Applies to both 
2.0 and 2.1 code.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:17

Message:
Logged In: YES 
user_id=6380

Assigning this to Barry. I suspect this is related to SF bug
#449151.

I wonder if this would be sufficient to fix that bug?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422004&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:17:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:17:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-449009 ] distutils spelling error
Message-ID: <E15VHmw-0002cx-00@usw-sf-web2.sourceforge.net>

Bugs item #449009, was opened at 2001-08-07 22:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470

Category: Distutils
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils spelling error

Initial Comment:
In dist.py, "license" is spelled "licence".  This 
carries through to the setup.py;  if you want to 
specify a "license", it must be under the key 
"licence".

Also, the description mappings are kind of weird:

setup.py => PKG-INFO
-------------------------------
description => summary
long_description => description



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 12:17

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.48 of dist.py.  

The description mappings are a bit strange, but that's what
the Distutils SIG arrived at.  


----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-08-07 22:43

Message:
Logged In: YES 
user_id=103811

I just realized the licence/license issue is a duplicate of 
#412271.

Maybe this should be retooled as a "make distutils 
meta info keys consistent"?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449009&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:17:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:17:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-421973 ] Coercion rules incomplete
Message-ID: <E15VHn0-00079F-00@usw-sf-web3.sourceforge.net>

Bugs item #421973, was opened at 2001-05-07 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Coercion rules incomplete

Initial Comment:
The description of the coercion rules for numeric types
at
http://www.python.org/doc/current/ref/numeric-types.html
is incomplete. Step 3 says "We only get here if neither
x nor y is a class instance. " But step 2a also refers
to step 3 for the case that an explicit coercion
function returns None. It is not clear what happens in
that case.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-09 11:04

Message:
Logged In: YES 
user_id=3066

Guido, can you correct this?  I'm afraid I might get it
wrong.  The coercion rules are strange turf for me.  ;-(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=421973&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:18:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:18:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E15VHnL-0002de-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 3
Submitted By: Kevin Altis (kasplat)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer fix for Windows

Initial Comment:
CGIHTTPServer.py in the Python 2.1 library needs two 
changes to the popen2 section in order to support 
binary data and to avoid buffering problems under 
Windows. The complete code block is shown at the end 
of this message. The two changed lines are:
cmdline = "%s -u %s" % (interp, cmdline)
fi, fo = os.popen2(cmdline, 'b')

I've tested this under Windows 2000 Pro and binary 
file uploads now work, however more extensive tests 
should probably be done.

It appears there is another socket-related problem 
and/or end-of-line conversion error that occurs when 
using Internet Explorer 5.x and BASEHTTPServer with 
CGIHTTPServer on the same machine. I'm still 
investigating that issue.

Finally, I have done a small rewrite of 
CGIHTTPServer.py to simplify subclassing it to support 
running CGIs in any or all directories and using other 
file extensions such as .cgi. The maintainer for the 
current file should email me about the changes to see 
whether they want to update the official library file. 
I didn't post it here since it needs more tweaking

ka
---
CGIHTTPServer.p fixes...
elif self.have_popen2:
    # Windows -- use popen2 to create a subprocess
    import shutil
    os.environ.update(env)
    cmdline = scriptfile
    if self.is_python(scriptfile):
        interp = sys.executable
        if interp.lower().endswith("w.exe"):
            # On Windows, use python.exe, not 
python.exe
            interp = interp[:-5] = interp[-4:]
        cmdline = "%s -u %s" % (interp, cmdline)
    if '=' not in query and '"' not in query:
        cmdline = '%s "%s"' % (cmdline, query)
    self.log_error("command: %s", cmdline)
    try:
        nbytes = int(length)
    except:
        nbytes = 0
    fi, fo = os.popen2(cmdline, 'b')
    if self.command.lower() == "post" and nbytes > 0:
        data = self.rfile.read(nbytes)
        fi.write(data)
    fi.close()
    shutil.copyfileobj(fo, self.wfile)
    sts = fo.close()
    if sts:
        self.log_error("CGI script exit status %#x", 
sts)
    else:
        self.log_error("CGI script exited OK")


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 06:14

Message:
Logged In: YES 
user_id=6380

Reopening -- not that I have time for this. :-(

Note that that patch is in socket.py.

If this really is a work-around, I'd like to understand why.

----------------------------------------------------------------------

Comment By: Steve Pike (oztourer)
Date: 2001-08-09 05:27

Message:
Logged In: YES 
user_id=120658

To further elaborate on the problems with POST on Windows 
95: without having reached any real understanding of the 
problem I have found a tolerable workaround. By modifying 
the default _rbufsize for class _fileobject in socket.py I 
can get any POSTs with text length less than _rbufsize to 
work. Here is the mod:

<pre>
class _fileobject:
    def __init__(self, sock, mode, bufsize):
        self._sock = sock
        self._mode = mode
        if bufsize < 0:
            bufsize = 512
        # SP 9 Aug 2001: default _rbufsize is too small, 
crashing CGIHTTPServer on POST's
        # This fix still only allows pages of less than 
given buffer size to be updated,
        # so the real fix has still to be discovered.
        #self._rbufsize = max(1, bufsize)
        self._rbufsize = max(16*1024, bufsize)
        self._wbufsize = bufsize
        self._wbuf = self._rbuf = ""
</pre>

-- StevePike

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-07 12:59

Message:
Logged In: YES 
user_id=6380

I agree that this is a laudable goal, but I don't have the
time to spend to work on this.  Please upload a patch to the
SF patch manager and assign it to me and I'll look at it.

In the mean time, I've applied the two small suggestions and
will close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 09:29

Message:
Logged In: NO 

I want to elaborate on the second-to-last 
paragraph in this report.  CGIHTTPServer 
in 2.1 and 2.0 is apparently broken for 
POST requests (only) to CGI scripts, when
running locally on Windows with an IE client.

The details: there is a problem with 
the combination of a CGIHTTPServer and 
Intenernet Explorer both running locally 
on Windows (with server name "localhost").
In this setup, POST requests to CGI scripts
fail, but GET requests to the exact same 
script work fine.  That is, a form with 
method=GET, or a URL with an appended 
query string, both work ok.

In POST mode, the CGI script gets proper
data in the input stream, and generates 
a correct reply stream (which is in fact 
identical to the output generated for 
quivalent GET requests).  So, somewhere 
between CGIHTTPServer and IE, the data 
seems to be dropped or munged.  The same
thing happens of you force CGIHTTPServer 
to use execfile() to launch the script, 
instead of os.popen2.

I've also observed that endline conventions 
seem to be irrelevant to the problem; using 
\n or \r\n makes no difference in both the 
input and reply streams.  I've also been 
told that the problem may not exist in 
Netscape clients.

Since CGIHTTPServer is a very nice way to test
CGI scripts (all you need is a standard Python
install), this seems important.  It would also 
be nice if the directory assumptions in that 
module were more customizable, but that's just
a wish.

--Mark Lutz


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=427345&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:29:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:29:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-440041 ] Inconsistencies in C API calls
Message-ID: <E15VHxz-0007Jk-00@usw-sf-web3.sourceforge.net>

Bugs item #440041, was opened at 2001-07-10 06:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440041&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Inconsistencies in C API calls

Initial Comment:
Hello,

While writing a code generator for calling Python
functions from C, I encountered some inconsistencies in
a few calls in C API interface:

- PyLong_AS_LONG() does not exist, while
PyInt_AS_LONG() does
- The return type of PyList_SET_ITEM() is different
from 'void PyTuple_SET_ITEM()

I also found a number of documentation bugs, but those
are reported in report #440037

Albert

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 12:29

Message:
Logged In: YES 
user_id=3066

The return values from PyList_SET_ITEM() and
PyTuple_SET_ITEM() are not meant to be used, but both
evaluate to the type of the third argument.

PyInt_AS_LONG is guaranteed to succeed as long as the
argument is an integer object; PyLong_AS_LONG() cannot make
the parallel guarantee, so they would not be parallel
anyway.  (Remember, a PyLong is unbounded.)

There's no need to change any of these APIs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440041&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:35:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:35:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-416288 ] infrequent memory leak in pyexpat
Message-ID: <E15VI4W-0005vZ-00@usw-sf-web1.sourceforge.net>

Bugs item #416288, was opened at 2001-04-15 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: douglas orr (dougbo)
Assigned to: Martin v. Lіwis (loewis)
Summary: infrequent memory leak in pyexpat

Initial Comment:
In pyexpat.c, the macro call for the handler dispatch 
(my##NAME##Handler) for CharacterHandler allocates an 
object implicitly by calling one of the conversion-to-
unicode routines.  

If there is a problem in the PyBuildValue, resulting 
in args == NULL, that object will be leaked.

Low priority, but the macros probably need some 
reworking to handle this.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-09 04:48

Message:
Logged In: YES 
user_id=21627

That seems to be a bug in Py_BuildValue: It should decref 
its N arguments if it can't create a tuple.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416288&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 20:54:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 12:54:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1
Message-ID: <E15VIMv-0008Tp-00@usw-sf-web3.sourceforge.net>

Bugs item #441580, was opened at 2001-07-15 21:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470

>Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: can't import readline in 2.1.1c1

Initial Comment:
I get the following error for 2.1.1c1 built on SuSE 
Linux 7.1 , gcc 2.95.2 :

>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: undefined symbol: BC

Needless to say, this makes the interactive session 
interesting as readline is not imported on startup. 
Temporary fix for me is to use readline.so from 2.0 - 
it seems to work fine in 2.1.1c1.

Chuck


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 12:54

Message:
Logged In: YES 
user_id=11375

Try the patch I've now attached to the bug; does it fix 
the problem?



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-07-19 07:33

Message:
Logged In: YES 
user_id=35752

I believe that linking with ncurses is the right thing
to do if ncurses is available.  However, there are probably
systems out there that don't have ncurses but have termcap.
setup.py could decide what to link readline with based on
the HAVE_NCURSES_H define.

Andrew is better at wrangling setup.py so I'm assigning to
him.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:25

Message:
Logged In: YES 
user_id=34209

I'm sorry, I'm not going to fix this one for 2.1.1... I need
some feedback and more than a little testing on other
platforms before I'll check in a patch that adds -lncurses
to the library list for readline.

We can fix it for 2.1.2, if necessary, and 2.2, but someone
with setup.py clue needs to look at this... Neil has shown
such before, so assigning to him :)



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-16 17:27

Message:
Logged In: NO 

Ok, I looked at the Setup file for 2.0 from SuSE. They had

readline readline.c -lreadline -lncurses #-ltermcap 

whereas 2.1.1c1 had

readline readline.c -lreadline -ltermcap

I made the change, recompiled, and everything is dandy.

Chuck 


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:11

Message:
Logged In: YES 
user_id=34209

Did this work in Python 2.1(.0) ? Nothing readline-specific
changed in 2.1.1c1... It looks like setup.py is using the
wrong libraries to link with. When you enable readline.so in
2.0's Setup file, do you edit the list of include/library
paths or libraries linked with ?

I don't have a SuSe installation to test with, unfortunately.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 21:09:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 13:09:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-441429 ] curses, can't write to loverright corner
Message-ID: <E15VIbA-0007al-00@usw-sf-web1.sourceforge.net>

Bugs item #441429, was opened at 2001-07-15 04:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: curses, can't write to loverright corner

Initial Comment:
Whenever I try to write something to a window that
would cause text to appear in the lower right corner
I get an error
w = curses.newwin(2,10,0,0)
w.addstr(1,9,"X")   ->   
      _curses.error: addstr() returned ERR


w.addch(1,9,ord("x")) ->
      _curses.error: addch() returned ERR

Same behaviour on all versions I tried.
1.5.2
2.1
2.0


ncurses-5.2 if that is of importance.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 13:09

Message:
Logged In: YES 
user_id=11375

I believe this is a curses/ncurses limitation and not a 
bug, though  admittedly the limitation doesn't make much 
sense for windows that don't touch the lower-right corner 
of the terminal.  You could try writing the analogous C 
program and see if that also fails to work.

Making the window scrollable with w.scrollok(1) allows 
this to work, at the cost of making the window scroll up 
a line.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 21:20:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 13:20:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-438786 ] CVS 2.1.1c1 broken on osf1V4
Message-ID: <E15VIlp-0007lq-00@usw-sf-web1.sourceforge.net>

Bugs item #438786, was opened at 2001-07-05 07:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Martin v. Lіwis (loewis)
Summary: CVS 2.1.1c1 broken on osf1V4

Initial Comment:
As of right now, the CVS branch for the 2.1 bugfix
release cannot import the math module on my Digital
Unix platform.

ImportError: Unresolved symbol in
/tmp_mnt/home/gball/usr/src/python/dist/src/build/lib.osf1-V4.0-alpha-2.1/math.so:
__eprintf

uname is

OSF1 surya V4.0 878 alpha



----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 13:20

Message:
Logged In: YES 
user_id=21627

I've tried to find out what the mandated behaviour for 
make is. The Unix98 specification is a bit vague as to 
what values the environment of the subprocess shall have. 
However, in the draft 5 of the next Posix and Unix 
revisions, I find

#quote
Macros are not exported to the environment of commands to 
be run. This was never the case in any historical make and 
would have serious consequences. The environment is the 
same as the environment to make except that MAKEFLAGS and 
macros defined on the make command line are added.
#endquote

So it seems that both the Solaris make and GNU make are 
broken in this respect (not strictly speaking, since the 
behaviour of Posix make is unspecified unless the .POSIX 
target is given). So I have applied your patch as 
Makefile.pre.in 1.50.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-08-10 08:10

Message:
Logged In: YES 
user_id=11365

Ok, I'll withdraw that patch.  (I already tried to delete at
least on of those files, but without luck...) 
The source of the confusion is the following. In a nutshell,
my vendor make is broken.
Here are a couple of tiny files.

# contents of test.mk
FOO=hello
dothis:
	python showFOO.py
# end of test.mk
# contents of showFOO.py
import os
print os.environ.get('FOO')
# end of showFOO.py

Now lets try them out (OSF1V4)

surya:~/stuff>setenv FOO goodbye
surya:~/stuff>make -f test.mk
python showFOO.py
goodbye
surya:~/stuff>gmake -f test.mk
python showFOO.py
hello
surya:~/stuff>

So GNU Make shows the nice behaviour you just described
(so does my vendor make on Solaris.)  But the vendor make
on OSF1V4 does not.  The GNU make manual does seem to
mention the environment stuff under "features of GNU Make".

Perhaps the potential for problems with this make could be
mentioned in the README file.  Is OSF1V4 the same thing as
DEC Unix?  

Thanks.


----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 01:58

Message:
Logged In: YES 
user_id=21627

Ok, I have committed your setup.py patch as 1.47.

I still cannot see the problem solved with the
Makefile.pre.in. If I set CC to 'foo' and invoke make,
setup.py will still use 'gcc', not 'foo'. The reason is that
make passes all variables that where in the original
environment to subprocesses; if they were overwritten in the
Makefile, it will pass the new values (unless -e was
specified).

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-30 11:38

Message:
Logged In: YES 
user_id=11365

Thanks for your work on this. I'll try and explain about
setup.py etc.

If you look in
distutils.sysconfig.customize_compiler(compiler)

you will see that the command line for compiling shared
libraries is built up from Makefile variables like so:

$(CC) $(OPT) $(CCSHARED)

which is consistent with the traditional operation of the
python Makefile.

The problem with setup.py is that it does not recognize
the importance of the $(OPT) variable.  Before the
extensions are built it decides to recreate the compilation
command line using the current environment variables (I
doubt this is a worthwhile thing to do, but anyway...)
and if it finds $CC in the environment it effectively
defines the command line to be 

$(CC) $(CCSHARED)

i.e. $(OPT) has disappeared, and the CC variable is expected
to take on its role.

This is inconsistent with
1) The way distutils normally treats $(CC)
2) The way the Makefile uses $(CC)
3) The way make interprets $CC in the environment
4) The way configure interprets $CC in the environment.

Now until fairly recently there was no setup.py in the
python build process.  If you set CC=gcc in the environment
it would be interpreted consistently as in 2/3/4 above,
specifically, *not* implying that you wished not to use the
$(OPT) variable in the Makefile.

Ok, so let's assume that I didn't know that this was a bad
idea and kept doing it with the new python build.  At the
last step of building the shared modules, the value of
$(OPT) is discarded.  This is probably something like

OPT = -g -O3 -Wall -Wstrict-prototypes

so the shared modules are built without optimisation or
compiler warnings turned on.  Ok, I admit this doesn't break
the build.  But it could harm the performance of one's
python install noticeably.

So, my patch addresses this in a minimal way.  The
optimization flags OPT from distutils.sysconfig are retained
in the new commandline.  That's all.

This is really just a slight generalization of the patch
attached to #437487 which made sure that $(CCSHARED) was
retained in the commandline... omitting it broke the build
very badly in some cases.

Finally, the patch I was thinking about to Makefile.pre.in
addresses this comment in setup.py

# When you run "make CC=altcc" or something similar, you
# really want those environment variables passed into the
# setup.py phase.  Here's a small set of useful ones.

The problem is that just because a variable is in the
environment does *not* mean that it was passed as an
argument to make.  It is unfortunate that that's the way
make passes on variables, and it can't be disambiguated.

Make itself of course *doesn't* accept CC from the
environment since that is overridden by an assigment in the
Makefile.  So the make part of the build and the setup.py
part of the build become inconsistent.

This caused the original problem on OSF1V4: configure looked
at $CC and decided it was to be ignored.  Setup.py had no
clue that this decision had been made, and reinstated it.
The result was that the dynamic modules were linked with
the wrong libraries.

The fix I thought about was this:  when invoking setup.py
from the Makefile, explicitly pass CC (and LDSHARED which is
treated the same) in its environment.
My second attempt is attached here - it quotes the variables
which is needed of course...
What would be better is if you could give a commandline
argument to setup.py.  The help says that there is a
--compiler (-c) option to the build command.


That is not currently helpful though.  I tried
./python setup.py build -c gcc
and saw

    raise DistutilsPlatformError, msg
distutils.errors.DistutilsPlatformError: don't know how to
compile C/C++ code on platform 'posix' with 'gcc' compiler

which is unfortunate...

So that about covers it, I hope.



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-25 00:48

Message:
Logged In: YES 
user_id=21627

osf.patch was committed as 1.235. As for the changes to
setup.py and Makefile.pre.in: I cannot understand what
problem they solve. Please demonstrate the bug that is fixed
with these changes in more detail (i.e. what is the setting
of your environment variables, and what unexpected results
do you get without these changes). 

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 14:39

Message:
Logged In: YES 
user_id=11365

I tried testing that patch and it sucked.
I'll try again.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:06

Message:
Logged In: YES 
user_id=11365

Doh! Now it's uploaded. Sorry for the extra traffic.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:05

Message:
Logged In: YES 
user_id=11365

Next patch uploaded.

----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-24 11:04

Message:
Logged In: YES 
user_id=11365

Yes, the patch works and make test fails only on
test_format, I believe this is a known platform C library
bug.

I have attached a patch for the setup.py in python/dist/src.

It touches code which is supposed to allow variables set on
the make commandline to have effect.  I see two issues with
it.

One,  it effectively replaces CC and OPT from the Makefile
with just CC.  This is inconsistent with the behaviour of
the Makefile and configure.  My setup.patch addresses this.

Two, it doesn't really do what it says, because the variable
it picks up from the environment can has not necessarily got
there through a commandline argument to make.  This only
becomes a problem when configure decides to ignore an
environment variable, as was the case on OSF.  Martin's
patch stops this from happening on OSF, but the code is
still fragile.

Here's an idea:  make should always export its value of CC
into the environment of subprocesses.  Using Gnu make I'd do
this with an 'export' directive.  I'll next send a patch to
Makefile.pre.in which should do the job portably but it
isn't especially pretty. 



----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-24 00:11

Message:
Logged In: YES 
user_id=21627

Gregory, can you please try the attached patch, and report 
whether it changes anything?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 13:33

Message:
Logged In: YES 
user_id=6380

I don't recall why that was.  It was 6 years ago!  Quite
possibly things have changed; the OSF in use now is probably
quite different than the one then.

So, Martin, try to back out the change and see if this
doesn't break other things.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-19 12:38

Message:
Logged In: YES 
user_id=21627

This seems to originate fromt the fragment

	OSF1)	CC=cc
		without_gcc=;;

which was introduced in configure.in 1.23, with the comment

on osf/1, never use gcc

Therefore, I'm assigning it to Guido. My proposal is to 
close this as "won't fix" - if setting CC doesn't work, 
just don't do that.

Alternatively, if nobody can remember why gcc should not 
be used on OSF/1, it might be reasonable to back-out this 
change.


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-19 12:12

Message:
Logged In: YES 
user_id=11365

I just checked out the 2.1.1 branch again and
it still seems to be broken.  After a fresh config with $CC
set to gcc in the environment, the Makefile contains

CC=             cc
OPT=            -O -Olimit 1500
CCSHARED=

so it looks like configure has decided to use cc and
chosen flags for that compiler.

Then, the actual build command lines look like

gcc -I.
-I/tmp_mnt/home/gball/usr/src/python/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/tmp_mnt/home/gball/usr/src/python/dist/src/Modules/fpectlmodule.c
-o build/temp.osf1-V4.0-alpha-2.1/fpectlmodule.o

i.e. just "gcc" instead of "cc -O -Olimit 1500"

so it looks like the environment variable gets pulled in
only at the last moment and replaces $(CC), $(OPT) and
possibly $(CCSHARED), thereby throwing away the work done by
configure. 



----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:59

Message:
Logged In: YES 
user_id=34209

Gregory, did you get a chance to test the patch attached to
bug #437487, or the 2.1.1 CVS tree ? I'd like to know if
this is fixed in 2.1.1.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:56

Message:
Logged In: YES 
user_id=34209

Ah, yes, that sounds very plausible. The fix for that
problem, which was checked in on the trunk, will be in
Python 2.1.1-final as well. The Solaris bugreport has a
patch attached to it; could you test it to see if it solves
your 2.1.1c1 problem ?


----------------------------------------------------------------------

Comment By: Gregory H. Ball (greg_ball)
Date: 2001-07-09 08:48

Message:
Logged In: YES 
user_id=11365

The problem goes away if I clear $CC instead of having it
set to gcc.  There's a similar problem on Solaris reported
recently.
I think the configure script should try to spot this sort of
thing,
but I suppose that's an Autoconf feature request, not a
python bug...

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-08 14:06

Message:
Logged In: YES 
user_id=21627

This sounds like a bug in your compiler installation. 
__eprintf is typically defined in libgcc.a; make sure you 
use a consistent compiler capable of building binaries for 
your system throughout the build process.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438786&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 21:25:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 13:25:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-414032 ] clib option is broken
Message-ID: <E15VIqW-0007qW-00@usw-sf-web1.sourceforge.net>

Bugs item #414032, was opened at 2001-04-05 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414032&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: A.M. Kuchling (akuchling)
Summary: clib option is broken

Initial Comment:
You cannot build a source distribution when the setup script contains libraries.

Here is the traceback:

C:\sf\py2exe>setup sdist
running sdist
Traceback (most recent call last):
  File "C:\sf\py2exe\setup.py", line 317, in ?
    package_dir={'py2exe.tools': "tools" + sys.version[:3]},
  File "c:\python20\distutils\core.py", line 138, in setup
    dist.run_commands()
  File "c:\python20\distutils\dist.py", line 903, in run_commands
    self.run_command(cmd)
  File "c:\python20\distutils\dist.py", line 923, in run_command
    cmd_obj.run()
  File "C:\Python20\distutils\command\sdist.py", line 142, in run
    self.get_file_list()
  File "C:\Python20\distutils\command\sdist.py", line 241, in get_file_list
    self.add_defaults()
  File "C:\Python20\distutils\command\sdist.py", line 318, in add_defaults
    self.filelist.extend(build_clib.get_source_files())
  File "c:\python20\distutils\cmd.py", line 107, in __getattr__
    raise AttributeError, attr
AttributeError: get_source_files

C:\sf\py2exe>

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 13:25

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.23 of build_clib.py, by adding Rene's
.get_source_files() method.  Thanks!



----------------------------------------------------------------------

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 01:01

Message:
Logged In: YES 
user_id=28463

remove the line

        self.check_extensions_list(self.extensions)

in the previous comment  (it doesn't belong there,
it was accidently pasted in.)

----------------------------------------------------------------------

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:50

Message:
Logged In: YES 
user_id=28463

(How can I attach files?)

    def get_source_files (self):
        filenames = []
        for (lib_name, build_info) in self.libraries:
            sources = build_info.get('sources')
            if sources is None or type(sources) not in \
                       (ListType, TupleType):
                raise DistutilsSetupError, \
                ("in 'libraries' option (library '%s'), "+ \
                "'sources' must be present and must be "+ \
                "a list of source filenames") % lib_name
            filenames.extend(sources)

        self.check_extensions_list(self.extensions)

        return filenames


----------------------------------------------------------------------

Comment By: Rene Liebscher (rliebscher)
Date: 2001-08-07 00:46

Message:
Logged In: YES 
user_id=28463

The problem is the missing get_source_files method in 
distutils/command/build_clib.py.

I think someone has already solved the problem, it doesn't
seem too hard.

Adding a method similar to build_ext.py should
the problem.

See the attached file for a suggestion. (It is not tested by
me.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=414032&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 21:37:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 13:37:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15VJ2K-0001pi-00@usw-sf-web3.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Martin v. Lіwis (loewis)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 13:37

Message:
Logged In: YES 
user_id=21627

I took a slightly different approach: always depend on 
HAVE_NETPACKET_PACKET_H for the AF_PACKET code. This is 
committed in configure.in 1.244 and socketmodule.c 1.163.

If you can, please confirm that the current CVS code works 
on glibc 2.0. Assuming that it does, I close the bug 
report.


----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:24

Message:
Logged In: YES 
user_id=292642

Oops, missed the tick box to attach the file...

----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:22

Message:
Logged In: YES 
user_id=292642

The patch doesn't work, I'm afraid. RedHat 5 doesn't support
sockaddr_ll:

Python-2.1.1/Modules/socketmodule.c:391: field `ll' has
incomplete type

(By the way, RedHat 5 is libc 6 -- it's just glibc 2.0,
rather than 2.1.)

I think the proper solution would be to turn the AF_PACKET
support into an autoconf feature test, rather than a test
for the AF_PACKET and linux defines. A quicker hack is the
attached patch (plus the changes to configure.in and
pyconfig.h) which just undefines AF_PACKET if there is no
netpacket/packet.h.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 22:24:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 14:24:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-442833 ] 2.2a1: __int__ and multiple inheritance
Message-ID: <E15VJln-0001rM-00@usw-sf-web1.sourceforge.net>

Bugs item #442833, was opened at 2001-07-19 11:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470

Category: type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: __int__ and multiple inheritance

Initial Comment:
The __int__ special method doesn't seem to be 
inherited correctly somehow when multiple inheritance 
is involved:

----
class Node(object):
   def __int__(self):
      return int(self.str())
   def str(self):
      return "23"

class Frag(Node, list):
   def str(self):
      return "42"

print Node().__int__()
print int(Node())
print Frag().__int__()
print int(Frag())
----
Output is:
----
23
23
42
Traceback (most recent call last):
  File "xsc.py", line 14, in ?
    print int(Frag())
TypeError: object can't be converted to int


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 14:24

Message:
Logged In: YES 
user_id=6380

Fixed in CVS. typeobject.c: 2.29.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-19 11:42

Message:
Logged In: YES 
user_id=6380

Right again.  This will take some time to fix...  I believe
I currently only look in the "primary" base class for
special slots, where the "primary" base class in your
example is 'list'.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442833&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 22:27:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 14:27:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-448951 ] Bug in re group handling
Message-ID: <E15VJoB-0002IQ-00@usw-sf-web1.sourceforge.net>

Bugs item #448951, was opened at 2001-08-07 17:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470

>Category: Regular Expressions
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fredrik Lundh (effbot)
Summary: Bug in re group handling

Initial Comment:
#
# read it or run it!
#
import re,sys
print sys.version
#
# Bug in 're' lib in Python 2.1
#
# Consider this regexp : (?:([0-3]):)?0#
# This will match one of
# '0#', '0:0#', '1:0#', '2:0#', '3:0#' 
#
# The matching itself works fine, but group(1) should
# be None for the '0#' case, and 'x' for the 'x:0#' cases.
# For '0#', the optional '([0-3]):' part of the
# r.e. (enclosed in (?: )) does not match anything, and that
# is what contains group 1.
#
# The actual result is, group(1) is '0' for both '0#' and '0:0#'.
# Likely this happens because when '0' is seen, the state machine
# cannot not yet determine whether the ([0-3]): should be matched,
# but has already seen enough of it to know what group(1) is, assuming
# it does match. The match needs to be deleted once the containing 
# ? fails. Indeed, if the group is expanded to include the ':',
# as in '(?:([0-3]:))?0#', or just '([0-3]:)?0#', '0#' produces
# group(1)=None as it should.
#
# Also, this is a good time to point out an error in the
# docs. The docs say that group(n) returns -1 when the
# group is in an unmatched part the of the r.e.; actually
# it returns None, which is more sensible.
#

rexp = '(?:([0-3]):)?0#'
mat1 = re.compile(rexp)

print "Re = ", rexp

for str in [ '2:0#', '0:0#', '0#', '0:#', ':0#']:
	print "\n-----<<", str, ">>-----"
	mat = mat1.match(str)
	if mat:
		print "    group(0) = ", mat.group(0)
		print "    group(1) = ", mat.group(1)
	else:
		print "    no match"
#
# output is below
#
#################################
# Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
# Re =  (?:([0-3]):)?0#
# 
# -----<< 2:0# >>-----
#     group(0) =  2:0#
#     group(1) =  2
# 
# -----<< 0:0# >>-----
#     group(0) =  0:0#
#     group(1) =  0
# 
# -----<< 0# >>-----
#     group(0) =  0#
#     group(1) =  0
# 
# -----<< 0:# >>-----
#     no match
# 
# -----<< :0# >>-----
#     no match
#
############################################

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 22:56:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 14:56:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-223616 ] Tools/compiler needs documentation.
Message-ID: <E15VKGQ-0004tu-00@usw-sf-web3.sourceforge.net>

Bugs item #223616, was opened at 2000-11-27 10:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
>Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: Tools/compiler needs documentation.

Initial Comment:
The compiler package is not documented; this needs to be done before tools are likely to be written on top of it.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 14:56

Message:
Logged In: YES 
user_id=3066

Jeremy said he'd work on this next week, so I'm bumping the
priority as a reminder.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 19:48

Message:
Jeremy -- is there anything that can be done to make it easier for you to get this done?  I think these should really be documented and moved into the library.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223616&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 22:57:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 14:57:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-441429 ] curses, can't write to loverright corner
Message-ID: <E15VKHo-0003Wp-00@usw-sf-web1.sourceforge.net>

Bugs item #441429, was opened at 2001-07-15 04:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470

Category: Extension Modules
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: curses, can't write to loverright corner

Initial Comment:
Whenever I try to write something to a window that
would cause text to appear in the lower right corner
I get an error
w = curses.newwin(2,10,0,0)
w.addstr(1,9,"X")   ->   
      _curses.error: addstr() returned ERR


w.addch(1,9,ord("x")) ->
      _curses.error: addch() returned ERR

Same behaviour on all versions I tried.
1.5.2
2.1
2.0


ncurses-5.2 if that is of importance.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-10 14:57

Message:
Logged In: NO 

Ok, I tried a little program in C.


#include <curses.h>

WINDOW *w;

int i,c,x1,x2,x3;
int main()
{
  initscr();cbreak();noecho();
  
  w = newwin(2,10,0,0);
  c = wgetch(w);
  x1 = mvwprintw(w,0,9,"Y"); /* IS OK */
  x2 = mvwprintw(w,1,9,"Y"); /* IS OK, BUT MIGHT REPORT
WRONG */
  x3 = mvwprintw(w,2,9,"Y"); /* THIS SHOULD NOT WORK */
  wrefresh(w);
  c = wgetch(w);
   
  echo();endwin();nocbreak();
  printf("RETURN VALUES: %d,%d,%d\n",x1,x2,x3);
  return 0;
}


When run, this program produces a screen with an Y on each
of the two first lines, just as expected.
It then ends and prints the output:

RETURN VALUES: 0,-1,-1

The first -1 should, as I see it, have been 0. I assume 
the python code sees the -1 and raises the error?

So yes, this would seem to be an error in curses.

/Magnus.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 13:09

Message:
Logged In: YES 
user_id=11375

I believe this is a curses/ncurses limitation and not a 
bug, though  admittedly the limitation doesn't make much 
sense for windows that don't touch the lower-right corner 
of the terminal.  You could try writing the analogous C 
program and see if that also fails to work.

Making the window scrollable with w.scrollok(1) allows 
this to work, at the cost of making the window scroll up 
a line.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441429&group_id=5470


From noreply@sourceforge.net  Fri Aug 10 23:50:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 15:50:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-449854 ] make failing on OS X 10.0.4
Message-ID: <E15VL7L-0007BQ-00@usw-sf-web3.sourceforge.net>

Bugs item #449854, was opened at 2001-08-10 10:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449854&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: make failing on OS X 10.0.4

Initial Comment:
Trying to do 'make' again on 10.0.4 with CVS 
current as of this morning. I get all the way down 
to:
ranlib libpython2.2.a
cc  -u __dummy -u _PyMac_Error -framework 
System -framework Foundation -framework 
Carbon -o python \
                Modules/python.o \
                libpython2.2.a -lpthread -ldl      
/usr/bin/ld: can't create output file: python (Is a 
directory, errno = 21)
make: *** [python] Error 1

Is this a flaw in the Makefile or is it a "feature" of 
Mac OS X being on HFS+ (which is NOT case 
sensitive)? Either way, I looked at the Makefile and 
had no idea where to even try to attempt a change. 
Any suggestions?

-John Buell

----------------------------------------------------------------------

Comment By: Jim Hill (jthill)
Date: 2001-08-10 15:50

Message:
Logged In: YES 
user_id=21626

I bet it's the case-insensitive filesystem.  Try 
`./configure --program-suffix=_`; you can rename manually 
later.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449854&group_id=5470


From noreply@sourceforge.net  Sat Aug 11 01:06:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 10 Aug 2001 17:06:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-449964 ] sre.sub() fails
Message-ID: <E15VMIg-0004vO-00@usw-sf-web2.sourceforge.net>

Bugs item #449964, was opened at 2001-08-10 17:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449964&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Atsuo Ishimoto (atsuoi)
Assigned to: Nobody/Anonymous (nobody)
Summary: sre.sub() fails 

Initial Comment:

sre.sub() raises exception if template contains
"\g<number>" .

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\tools\python21\lib\sre.py", line 71, in subn
    return _compile(pattern, 0).subn(repl, string, 
count)
  File "c:\tools\python21\lib\sre.py", line 171, in 
_subn
    template = _compile_repl(template, pattern)
  File "c:\tools\python21\lib\sre.py", line 149, in 
_compile_repl
    p = sre_parse.parse_template(repl, pattern)
  File "c:\tools\python21\lib\sre_parse.py", line 701, 
in parse_template
    this = char(ESCAPES[this][1])
TypeError: object is not callable: '>'

---------------------------------------------------

This patch fix problem.

$ diff -u sre_parse.py.orig sre_parse.py
--- sre_parse.py.orig   Sat Aug 11 08:44:11 2001
+++ sre_parse.py        Sat Aug 11 08:51:43 2001
@@ -658,12 +658,12 @@
                 name = ""
                 if s.match("<"):
                     while 1:
-                        char = s.get()
-                        if char is None:
+                        c = s.get()
+                        if c is None:
                             raise 
error, "unterminated group name"
-                        if char == ">":
+                        if c == ">":
                             break
-                        name = name + char
+                        name = name + c
                 if not name:
                     raise error, "bad group name"
                 try:



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449964&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 18:48:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 10:48:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-450510 ] results of build on Mac OS X 10.0.4
Message-ID: <E15WiIx-0006aW-00@usw-sf-web1.sourceforge.net>

Bugs item #450510, was opened at 2001-08-13 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: results of build on Mac OS X 10.0.4

Initial Comment:
I simply wanted to post my list of compiler warnings
and so on, as maybe these are things that need to be
addressed/fixed, or maybe not :)

-John Buell

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-14 10:48

Message:
Logged In: NO 

I had to make a change to setup.py to get some of the
modules to build correctly (even after Jack's changes in
cvs 8/13).  I think there is an interaction with the 
-bundle and -shared ld flags.

--Bill Noon

Index: setup.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.47
diff -r1.47 setup.py
144c144
<             args['linker_so'] = linker_so + ' -shared'
---
>             args['linker_so'] = linker_so + ''


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 19:27:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 11:27:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-446645 ] rexec and function attributes
Message-ID: <E15Wiul-0001YA-00@usw-sf-web1.sourceforge.net>

Bugs item #446645, was opened at 2001-07-31 19:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446645&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Brecknell (brecknell)
Assigned to: Barry Warsaw (bwarsaw)
Summary: rexec and function attributes

Initial Comment:
The behaviour of the rexec module seems to be 
inconsistent with respect to function attributes. The 
function attribute dictionary is read-only in the 
restricted environment until you go and write to it 
outside the restricted environment. After that, the 
dictionary becomes writable in the restricted 
environment too. See the following examples:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> def f(): pass
... 
>>> r.modules['__main__'].f = f
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Or, looking at it another way:

Python 2.1 (#1, Jun 29 2001, 15:51:00) 
[GCC 2.95.3 19991030 (prerelease)] on openbsd2
Type "copyright", "credits" or "license" for more 
information.
>>> import rexec
>>> r = rexec.RExec()
>>> r.r_exec("def f(): pass")
>>> r.r_exec('f.__dict__["attr"] = "value"')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/python/lib/python2.1/rexec.py", line 264, 
in r_exec
    exec code in m.__dict__
  File "<string>", line 1, in ?
TypeError: object does not support item assignment
>>> f = r.modules['__main__'].f
>>> f.attr = "value"
>>> r.r_exec('f.__dict__["attr"] = "new value"')
>>> f.attr
'new value'
>>> 

Please don't abuse me too much for still being on 
Python 2.1, since I haven't had time to try 2.1.1 or 
2.2a1! If I don't put this in now, I'll forget. I'm 
guessing that neither rexec nor function attributes 
are widely used, so not too many people would have 
come across this. If I get more time down the track, 
I'll look into it further.

Regards,
Matt.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-14 11:27

Message:
Logged In: YES 
user_id=12800

Done.  funcobject.c 2.40, Python 2.2


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 09:01

Message:
Logged In: YES 
user_id=6380

OK, you've convinced me.  A __dict__ that appears to be
always there is fine. Please update the PEP and fix the bug!

Back to Barry.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-13 16:36

Message:
Logged In: YES 
user_id=12800

I'm bouncing this one back to Guido for BDFL pronouncement.  

Back when PEP 232 was being finalized (circa Feb 2001), Greg
Ball brought up this very point in a private thread entitled
"Update to PEP 232".  Greg also thought that allowing
func.__dict__ to be None was confusing, and I agreed.  Guido
disagreed; he actually liked the current semantics, so it
was documented in the PEP and implementation.

Thinking about this again, I still think that 
1) del f.__dict__ should raise a TypeError
2) f.__dict__ = not_a_concrete_dict should raise TypeError
3) f.__dict__ before any attribute assignment should
initialize the attribute to the empty dict and return it.
One way to think about it is modeling func.__dict__ after
instance.__dict__.  del'ing the latter, or setting it to
None both result in TypeError.  Same for module.__dict__. 
Should func.__dict__ act the same way?

Guido: if you still agree with the semantics in PEP 232,
please close this as Wont Fix.  Otherwise, reassign it back
to me and I'll update both the PEP and the implementation.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-01 13:00

Message:
Logged In: YES 
user_id=31392

You can see this behavior without using rexec.  The problem
you're seeing is that a function's __dict__ is None until
you set an attribute on the function.  Then the __dict__
slot is created and a new dictionary bound there.  The error
you see, which you attributed to rexec, is attempting to
execute f.__dict__["attr"] => None["attr"].

There are two policy questions here, which Barry can better
answer:

1. Should a function's __dict__ be accessible in restricted
mode?  A class's __dict__ is not, but it's a horse of a
different color.

2. Is it okay for __dict__ to occasionally return None?  I
don't think it is.  It's fine to be lazy about the creation
of __dict__, but it should be created as soon as it is
referenced.  Otherwise, any code that wants to use __dict__
should be prepared to deal with None.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=446645&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 20:20:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 12:20:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-450909 ] __future__.division fails at prompt
Message-ID: <E15Wjjn-0002Qi-00@usw-sf-web1.sourceforge.net>

Bugs item #450909, was opened at 2001-08-14 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: __future__.division fails at prompt

Initial Comment:
At the interactive prompt, this should use the __truediv__() method to implement division, not __div__():

>>> from __future__ import division
>>> class C:
...   def __div__(self, other):
...     return self
...
>>> c = C()
>>> c / 1
<__main__.C instance at 0x81aede4>

# This should have raised TypeError

>>> class C:
...   def __div__(self, other):
...     return 1.0
...   def __truediv__(self, other):
...     return 2.0
...
>>> c2 = C()
>>> c2 / 1
1.0

# This should have returned 2.0

Appearantly a flag isn't being maintained with the global state.  This is using the CVS version of Python as of 10 minutes ago.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 20:26:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 12:26:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-450909 ] __future__.division fails at prompt
Message-ID: <E15Wjpa-0002WL-00@usw-sf-web1.sourceforge.net>

Bugs item #450909, was opened at 2001-08-14 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: __future__.division fails at prompt

Initial Comment:
At the interactive prompt, this should use the __truediv__() method to implement division, not __div__():

>>> from __future__ import division
>>> class C:
...   def __div__(self, other):
...     return self
...
>>> c = C()
>>> c / 1
<__main__.C instance at 0x81aede4>

# This should have raised TypeError

>>> class C:
...   def __div__(self, other):
...     return 1.0
...   def __truediv__(self, other):
...     return 2.0
...
>>> c2 = C()
>>> c2 / 1
1.0

# This should have returned 2.0

Appearantly a flag isn't being maintained with the global state.  This is using the CVS version of Python as of 10 minutes ago.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:26

Message:
Logged In: YES 
user_id=6380

Note that the problem happens even for built-in types:

(Current CVS)
>>> from __future__ import division
>>> 3/2
1
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 20:28:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 12:28:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-450909 ] __future__.division fails at prompt
Message-ID: <E15WjrJ-0002Xy-00@usw-sf-web1.sourceforge.net>

Bugs item #450909, was opened at 2001-08-14 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: __future__.division fails at prompt

Initial Comment:
At the interactive prompt, this should use the __truediv__() method to implement division, not __div__():

>>> from __future__ import division
>>> class C:
...   def __div__(self, other):
...     return self
...
>>> c = C()
>>> c / 1
<__main__.C instance at 0x81aede4>

# This should have raised TypeError

>>> class C:
...   def __div__(self, other):
...     return 1.0
...   def __truediv__(self, other):
...     return 2.0
...
>>> c2 = C()
>>> c2 / 1
1.0

# This should have returned 2.0

Appearantly a flag isn't being maintained with the global state.  This is using the CVS version of Python as of 10 minutes ago.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:28

Message:
Logged In: YES 
user_id=6380

Also note that this *used* to work.  Here's a different
version I built on August 10:

>>> from __future__ import division
>>> 1/3
0.33333333333333331
>>> 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:26

Message:
Logged In: YES 
user_id=6380

Note that the problem happens even for built-in types:

(Current CVS)
>>> from __future__ import division
>>> 3/2
1
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 20:56:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 12:56:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-450633 ] Had error trying to follow tutorial.
Message-ID: <E15WkIT-00030p-00@usw-sf-web1.sourceforge.net>

Bugs item #450633, was opened at 2001-08-13 15:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450633&group_id=5470

Category: Documentation
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Had error trying to follow tutorial.

Initial Comment:
I copied code from the Python tutorial from your site 
and pasted into the Windows Python shell, but I got an 
error. I already had an x floating around, so I used 
k. 

>>> k = int(raw_input("Please enter a number: "))
Please enter a number: 6.8
Traceback (most recent call last):
  File "<pyshell#43>", line 1, in ?
    k = int(raw_input("Please enter a number: "))
ValueError: invalid literal for int(): 6.8

Thanks for your time.

Thu Duong
thubar2000@yahoo.com

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-14 12:56

Message:
Logged In: YES 
user_id=3066

You entered a float, but int() only converts to integers, not floats, so the exception was expected.  The prompt in the example is misleading.  I've corrected this in the revision control repository to request "an integer" instead of "a number".

Doc/tut/tut.tex revision 1.147.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450633&group_id=5470


From noreply@sourceforge.net  Tue Aug 14 21:03:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 13:03:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-450909 ] __future__.division fails at prompt
Message-ID: <E15WkPF-00037O-00@usw-sf-web1.sourceforge.net>

Bugs item #450909, was opened at 2001-08-14 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: __future__.division fails at prompt

Initial Comment:
At the interactive prompt, this should use the __truediv__() method to implement division, not __div__():

>>> from __future__ import division
>>> class C:
...   def __div__(self, other):
...     return self
...
>>> c = C()
>>> c / 1
<__main__.C instance at 0x81aede4>

# This should have raised TypeError

>>> class C:
...   def __div__(self, other):
...     return 1.0
...   def __truediv__(self, other):
...     return 2.0
...
>>> c2 = C()
>>> c2 / 1
1.0

# This should have returned 2.0

Appearantly a flag isn't being maintained with the global state.  This is using the CVS version of Python as of 10 minutes ago.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-14 13:03

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.217 of compile.c


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:28

Message:
Logged In: YES 
user_id=6380

Also note that this *used* to work.  Here's a different
version I built on August 10:

>>> from __future__ import division
>>> 1/3
0.33333333333333331
>>> 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:26

Message:
Logged In: YES 
user_id=6380

Note that the problem happens even for built-in types:

(Current CVS)
>>> from __future__ import division
>>> 3/2
1
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 02:28:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 18:28:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-420601 ] --with-next-framework very broken on OSX
Message-ID: <E15WpTa-0000km-00@usw-sf-web3.sourceforge.net>

Bugs item #420601, was opened at 2001-05-01 18:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jack Jansen (jackjansen)
Summary: --with-next-framework very broken on OSX

Initial Comment:
This bug report is not going to have a lot of useful 
data;  mostly just to get it into the system to see if 
others may care (or already be working on it).

In any case, --with-next-frameworks is quite broken 
under OSX.   It may not even really be pertinent any 
longer, but I have yet to verify that [investigation 
commences soon].

- executes ranlib against the dylib which breaks on 
OSX

- doesn't actually build a framework at all, but 
installs a dynamically loadable library (which may 
actually be more appropriate, all things 
considered)

- fails to install the dylib or any of the other .so 
modules in the actual platform specific directory 
where one might expect.  Instead, they end up in 
the generic dylib directory, but the PYTHONPATH 
does not search that directory.

- python executable will not launch because the 
dylib cannot be found.   However, given that the 
python executable does not have any kind of path 
information for the dylib, I'm not sure it would find it 
even if the dylib were installed in a "more correct" 
place.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-14 18:28

Message:
Logged In: YES 
user_id=45365

This is fixed in the CVS tree (I hope:-).

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-05-12 13:37

Message:
Logged In: YES 
user_id=45365

I know next-to-nothing of OSX frameworks yet, so I asked Steve Majewski <sdm7g@Virginia.EDU>,
and he came up with the following bit. Any more insights are welcome.

Steve said:
 It's definitely badly broken for OSX, and my suggestion was (and is)
to make (eventually) building a framework a separate post-build step
with it's own script. I'm not sure if anything different has to be
done during the build as prep or not. I'm guessing not -- I think on
OSX it's mainly going to be a question of packaging -- sort of how
you bundle up the resources, etc. into MacPython. 
 I think the only question about ripping it out is whether it's needed
for Next or OpenStep  support and is anyone still using it? ( There 
REALLY ARE folks who are still using them, and occasionally complain
on *.advocacy that it's still better than OSX, etc. but do any of them
use Python? ) 

 What is the policy ? 

 If it's that if no one on python-dev wants to speak up and adopt a 
platform, out it goes -- then by all means, dump it. (Although you
might want to put out an "official" Last Call first.)  

 Has this come up before ? Is there a PEP ? 
 If not, maybe we should write up a "last call for platform savior" 
 process proposal.  

 I know there's a PEP on removing features -- I'll have to look at
it and see if it covers platforms. I do prefer having a policy 
(whatever it is) than doing it ad.hoc. for basically the same reasons
as having one on feature removal. 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420601&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 02:31:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 14 Aug 2001 18:31:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-450510 ] results of build on Mac OS X 10.0.4
Message-ID: <E15WpWo-0000nP-00@usw-sf-web3.sourceforge.net>

Bugs item #450510, was opened at 2001-08-13 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: results of build on Mac OS X 10.0.4

Initial Comment:
I simply wanted to post my list of compiler warnings
and so on, as maybe these are things that need to be
addressed/fixed, or maybe not :)

-John Buell

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-14 18:31

Message:
Logged In: YES 
user_id=45365

Ah, thanks! I had noticed the saveFP and restFP errors suddenly popping up but I didn't know where they came from.

I'll fix this shortly, but depending on platform (I assume the '-shared' option wasn't added for nothing, so it'll be needed on some other platform, probably).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-14 10:48

Message:
Logged In: NO 

I had to make a change to setup.py to get some of the
modules to build correctly (even after Jack's changes in
cvs 8/13).  I think there is an interaction with the 
-bundle and -shared ld flags.

--Bill Noon

Index: setup.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.47
diff -r1.47 setup.py
144c144
<             args['linker_so'] = linker_so + ' -shared'
---
>             args['linker_so'] = linker_so + ''


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 09:35:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 01:35:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-451107 ] re.sub does not replace slahes (2.2a1)
Message-ID: <E15Ww8j-0005t6-00@usw-sf-web1.sourceforge.net>

Bugs item #451107, was opened at 2001-08-15 01:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai (muqker)
Assigned to: Nobody/Anonymous (nobody)
Summary: re.sub does not replace slahes (2.2a1)

Initial Comment:
Python  2.2a1:
>>> re.findall ('\\', 'a\')
['\']

but

>>> re.sub ('\\', 'b', 'a\')
'a\'
>>>

Python 2.0.1:
>>> re.sub ('\\', 'b', 'a\')
'ab'
>>>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 13:19:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 05:19:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-450909 ] __future__.division fails at prompt
Message-ID: <E15WzeF-0008Ut-00@usw-sf-web3.sourceforge.net>

Bugs item #450909, was opened at 2001-08-14 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Jeremy Hylton (jhylton)
Summary: __future__.division fails at prompt

Initial Comment:
At the interactive prompt, this should use the __truediv__() method to implement division, not __div__():

>>> from __future__ import division
>>> class C:
...   def __div__(self, other):
...     return self
...
>>> c = C()
>>> c / 1
<__main__.C instance at 0x81aede4>

# This should have raised TypeError

>>> class C:
...   def __div__(self, other):
...     return 1.0
...   def __truediv__(self, other):
...     return 2.0
...
>>> c2 = C()
>>> c2 / 1
1.0

# This should have returned 2.0

Appearantly a flag isn't being maintained with the global state.  This is using the CVS version of Python as of 10 minutes ago.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-14 13:03

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.217 of compile.c


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:28

Message:
Logged In: YES 
user_id=6380

Also note that this *used* to work.  Here's a different
version I built on August 10:

>>> from __future__ import division
>>> 1/3
0.33333333333333331
>>> 


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-14 12:26

Message:
Logged In: YES 
user_id=6380

Note that the problem happens even for built-in types:

(Current CVS)
>>> from __future__ import division
>>> 3/2
1
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450909&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 16:58:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 08:58:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-451217 ] Missing big chunk of extend/embed manual
Message-ID: <E15X34E-0004G6-00@usw-sf-web1.sourceforge.net>

Bugs item #451217, was opened at 2001-08-15 08:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing big chunk of extend/embed manual

Initial Comment:
I was looking for some information on the tp_setattro
slot and checked the Extending and Embedding manual.
Unfortunately, the section on Type Methods seems to be
truncated (both online and in the ext.tex source).  It
indicates that each slot in the type object will be
discussed, but the section ends abruptly after saying
it will discuss the basic type methods.

Check here for the online example:

  http://www.python.org/doc/ext/dnt-type-methods.html

Also, it appears that some of the slot names have
changed since this text was written.  I can update
those bits, but need the help of someone better
versed in the Python core to add explanations of the
various fields.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 17:05:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 09:05:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-451217 ] Missing big chunk of extend/embed manual
Message-ID: <E15X3Ay-0004Ni-00@usw-sf-web1.sourceforge.net>

Bugs item #451217, was opened at 2001-08-15 08:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing big chunk of extend/embed manual

Initial Comment:
I was looking for some information on the tp_setattro
slot and checked the Extending and Embedding manual.
Unfortunately, the section on Type Methods seems to be
truncated (both online and in the ext.tex source).  It
indicates that each slot in the type object will be
discussed, but the section ends abruptly after saying
it will discuss the basic type methods.

Check here for the online example:

  http://www.python.org/doc/ext/dnt-type-methods.html

Also, it appears that some of the slot names have
changed since this text was written.  I can update
those bits, but need the help of someone better
versed in the Python core to add explanations of the
various fields.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-15 09:05

Message:
Logged In: YES 
user_id=44345

I retract my supposition that some slot names have changed.
There are some new ones, but none of the existing ones
changed names.  My apologies...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 18:20:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 10:20:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-449157 ] socketmodule.c doesn't compile on RH 5.
Message-ID: <E15X4L8-00044U-00@usw-sf-web3.sourceforge.net>

Bugs item #449157, was opened at 2001-08-08 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470

Category: Build
Group: Python 2.1.1
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Duncan Grisby (dgrisby)
Assigned to: Martin v. Lіwis (loewis)
Summary: socketmodule.c doesn't compile on RH 5.

Initial Comment:
Python 2.1's socketmodule.c added support for AF_PACKET
sockets on Linux. Unfortunately, RedHat 5 machines have
the AF_PACKET define in /usr/include/linux/socket.h,
but they do not have /usr/include/netpacket/packet.h.
socketmodule.c tries to #include <netpacket/packet.h>,
so the build fails.

One work-around is to check for __GLIBC_MINOR__ >= 1
before supporting AF_PACKET in socketmodule.c. This
works for RedHat, but I don't know about other
distributions.

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-15 10:20

Message:
Logged In: YES 
user_id=21627

The patch looks fine to me, so I have committed it as
socketmodule.c 1.165, getnameinfo.c 1.3, addrinfo.h 1.2,
_localemodule.c 2.22, pyconfig.h.in 1.5, configure.in 1.247.

Until further problems occur, I'll close this again.

----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-13 04:34

Message:
Logged In: YES 
user_id=292642

The current CVS does fix the AF_PACKET problem, but it adds
a bunch of unrelated problems for glibc 2.0. I've attached
another patch, against current CVS, which permits it to
compile.

One thing that may need changing in the patch: glibc 2.0
does not have gai_strerror. The patch replaces it with a
fixed error string, but I'm not sure the string I used is a
good one.


----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-10 13:37

Message:
Logged In: YES 
user_id=21627

I took a slightly different approach: always depend on 
HAVE_NETPACKET_PACKET_H for the AF_PACKET code. This is 
committed in configure.in 1.244 and socketmodule.c 1.163.

If you can, please confirm that the current CVS code works 
on glibc 2.0. Assuming that it does, I close the bug 
report.


----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:24

Message:
Logged In: YES 
user_id=292642

Oops, missed the tick box to attach the file...

----------------------------------------------------------------------

Comment By: Duncan Grisby (dgrisby)
Date: 2001-08-10 03:22

Message:
Logged In: YES 
user_id=292642

The patch doesn't work, I'm afraid. RedHat 5 doesn't support
sockaddr_ll:

Python-2.1.1/Modules/socketmodule.c:391: field `ll' has
incomplete type

(By the way, RedHat 5 is libc 6 -- it's just glibc 2.0,
rather than 2.1.)

I think the proper solution would be to turn the AF_PACKET
support into an autoconf feature test, rather than a test
for the AF_PACKET and linux defines. A quicker hack is the
attached patch (plus the changes to configure.in and
pyconfig.h) which just undefines AF_PACKET if there is no
netpacket/packet.h.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-08 13:21

Message:
Logged In: YES 
user_id=21627

Can you please try the attached patch? Since it only 
modifies configure.in, you'll need to run autoconf after 
applying it. Also, when applying it to Python 2.1, the 
pyconfig.h.in chunk actually patches config.h.in.

The critical question probably is whether libc 5 supports 
struct sockaddr_ll as used by the AF_PACKET code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449157&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 20:15:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 12:15:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-451217 ] Missing big chunk of extend/embed manual
Message-ID: <E15X68H-0005cq-00@usw-sf-web3.sourceforge.net>

Bugs item #451217, was opened at 2001-08-15 08:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470

Category: Documentation
>Group: Feature Request
Status: Open
Resolution: None
>Priority: 6
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing big chunk of extend/embed manual

Initial Comment:
I was looking for some information on the tp_setattro
slot and checked the Extending and Embedding manual.
Unfortunately, the section on Type Methods seems to be
truncated (both online and in the ext.tex source).  It
indicates that each slot in the type object will be
discussed, but the section ends abruptly after saying
it will discuss the basic type methods.

Check here for the online example:

  http://www.python.org/doc/ext/dnt-type-methods.html

Also, it appears that some of the slot names have
changed since this text was written.  I can update
those bits, but need the help of someone better
versed in the Python core to add explanations of the
various fields.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-15 12:15

Message:
Logged In: YES 
user_id=3066

Nothing has been dropped, it just hasn't been completed.  I've just checked in a contribution which helps fill in the discussion of many commonly used slots, but it's still far from complete.  (Doc/ext/ext.tex revision 1.103)

I'm marking this as a feature request and dropping the priority since the documentation is not providing incorrect information, just not enough information.

You can also look for related information in the last chapter of the Python/C API reference.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-15 09:05

Message:
Logged In: YES 
user_id=44345

I retract my supposition that some slot names have changed.
There are some new ones, but none of the existing ones
changed names.  My apologies...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451217&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 20:18:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 12:18:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-451285 ] distutils ignores environment variables
Message-ID: <E15X6B6-0005fb-00@usw-sf-web3.sourceforge.net>

Bugs item #451285, was opened at 2001-08-15 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Thomas Heller (theller)
Summary: distutils ignores environment variables

Initial Comment:
Visual C++ 6.0 sets up environment variables for use 
by command-line users -- MSDEVDIR, INCLUDE, LIB.  It 
also provides VCVARS32.BAT to set these environment 
variables.  They specify where to find cl.exe and its 
header files and libraries.

distutils ignores those in favor of the registry.  I 
think distutils should honor the environment variables 
if they are set.

In my case, the registry was pointing to an old, 
removed install of VC.  I later installed a new 
version in a new location, but that install did not 
modify the registry.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 20:36:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 12:36:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-451295 ] HTTPS bugs in urllib2
Message-ID: <E15X6Sc-0007oz-00@usw-sf-web1.sourceforge.net>

Bugs item #451295, was opened at 2001-08-15 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451295&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPS bugs in urllib2

Initial Comment:
1. In AbstractBasicAuthHandler.retry_http_basic_auth()-
 if an HTTP error, other than 401, happens, 
authentication is disabled because 
self.__current_realm is not set to None

2. In HTTPRedirectHandler.http_error_302()- if an 
authenticated file is redirected, the old request 
header is discarded and, therefore, so is the 
authentication information.  If there is a new 
challenge, HTTP error 401 results, 
self.__current_realm is still set and authentication
is thereafter disabled.

I discovered these bugs while testing with a secure 
web site.  I made the following fixes (standard Unix 
diff format) and can be reached via email at 
bcox@semio.com:

bug #1-
631,633c649,660
<             resp = self.parent.open(req)
<             self.__current_realm = None
<             return resp
---
>             try:
>                 resp = self.parent.open(req)
>                 self.__current_realm = None
>                 return resp
> 			# prevent other HTTP errors 
from disabling authentication
>             except HTTPError, e:
>                 if e.code != 401:
>                     self.__current_realm = None
>                 raise
>             except (URLError, socket.error), e:
>                 self.__current_realm = None
>                 raise

bug #2-
447c460,465
<         new = Request(newurl, req.get_data())
---
> 
> 		# forgetting about the current state 
is not a good idea.
> 		# If this is an authenticated URL, 
then discarding the state
> 		# (i.e. the headers) will disable 
further authentication
> 
>         new = Request(newurl, req.get_data(), 
req.headers)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451295&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 20:49:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 12:49:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-451285 ] distutils ignores environment variables
Message-ID: <E15X6fO-000662-00@usw-sf-web3.sourceforge.net>

Bugs item #451285, was opened at 2001-08-15 12:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470

Category: Distutils
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Thomas Heller (theller)
Summary: distutils ignores environment variables

Initial Comment:
Visual C++ 6.0 sets up environment variables for use 
by command-line users -- MSDEVDIR, INCLUDE, LIB.  It 
also provides VCVARS32.BAT to set these environment 
variables.  They specify where to find cl.exe and its 
header files and libraries.

distutils ignores those in favor of the registry.  I 
think distutils should honor the environment variables 
if they are set.

In my case, the registry was pointing to an old, 
removed install of VC.  I later installed a new 
version in a new location, but that install did not 
modify the registry.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-15 12:49

Message:
Logged In: YES 
user_id=31435

Jeremy, do you know how to run regedit?  It's a GUI 
registry browser.  Do Start -> Run and type "regedit" (no 
quotes) then click OK.

I want you to navigate to two places:

HKEY_LOCAL_MACHINE\
Software\
Microsoft\
Devstudio\
6.0\
Build System\

and exactly the same except starting at HKEY_CURRENT_USER 
instead.

My *bet* is that you're going to find that path in both 
places, but that under HKEY_LOCAL_MACHINE it's pointing to 
a wrong place.  This would be a side-effect of not having 
properly uninstalled your previous MSVC.

If that's all true, select the DevStudio node under 
HKEY_LOCAL_MACHINE and then do Edit->Delete.  This will get 
rid of the obsolete registry setting.  Close regedit then.

disutils *should* look under HKEY_CURRENT_USER before 
looking under HKEY_LOCAL_MACHINE, because per-user settings 
are suppused to take precedence over per-machine settings, 
and especially under Win2K.  That appears to be a repeated 
buglet in msvccompiler.py.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451285&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 21:36:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 13:36:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-451309 ] don't store traceback objects
Message-ID: <E15X7Oj-0000L6-00@usw-sf-web1.sourceforge.net>

Bugs item #451309, was opened at 2001-08-15 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Steve Purcell (purcell)
Summary: don't store traceback objects

Initial Comment:
A TestResult object stores the exceptions raised when
tests fail.  The only use of these stored tracebacks,
it seems, is to print a stack trace when the test run's
report is generated.

The traceback objects, however, keep pointers to a bunch
of objects that might otherwise be garbage collected. 
I ran into this on Windows, where the traceback was
keeping a file object alive.  Because the file object
was not collected, my tearDown() method could not
remove the file.

This patch changes unittest to generate the formatted
traceback immediately, so that it does not keep
tracebacks around any longer than needed.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470


From noreply@sourceforge.net  Wed Aug 15 22:46:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 14:46:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-451309 ] don't store traceback objects
Message-ID: <E15X8UD-0001GO-00@usw-sf-web2.sourceforge.net>

Bugs item #451309, was opened at 2001-08-15 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Steve Purcell (purcell)
Summary: don't store traceback objects

Initial Comment:
A TestResult object stores the exceptions raised when
tests fail.  The only use of these stored tracebacks,
it seems, is to print a stack trace when the test run's
report is generated.

The traceback objects, however, keep pointers to a bunch
of objects that might otherwise be garbage collected. 
I ran into this on Windows, where the traceback was
keeping a file object alive.  Because the file object
was not collected, my tearDown() method could not
remove the file.

This patch changes unittest to generate the formatted
traceback immediately, so that it does not keep
tracebacks around any longer than needed.


----------------------------------------------------------------------

>Comment By: Steve Purcell (purcell)
Date: 2001-08-15 14:46

Message:
Logged In: YES 
user_id=21477

Hi Jeremy,

This behaviour is actually known and intentional; the 
dangers are documented as a caveat in the PyUnit docs. The 
intention was that a test runner (GUI or otherwise) could 
potentially make the traceback available for inspection 
when a test fails, to aid in debugging.

In your particular case, relying on GC to close the file 
might have caused problems with following code even if 
PyUnit didn't store the traceback.

Overall I'd prefer to keep storing the tracebacks, 
especially since they only get stored when tests fail. It 
would be worth me adding a note about GC interaction to 
the docs, though.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 07:48:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 15 Aug 2001 23:48:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-231377 ] [HP-UX] Python chokes on pthread_mutex_init
Message-ID: <E15XGxV-0000sx-00@usw-sf-web1.sourceforge.net>

Bugs item #231377, was opened at 2001-02-07 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231377&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 3
Submitted By: Thomas Wallgram (twallgram)
Assigned to: Guido van Rossum (gvanrossum)
Summary: [HP-UX] Python chokes on pthread_mutex_init

Initial Comment:
Hello,
I need python 1.5.2 (only this version) on a HP-UX-System with threads. I started configure with the --with-threads-Option. Then I did the 'make'-command (No problems during the compilation). Then I started make test. See the output bellow:

# make test
        (cd Modules; make -f Makefile.pre Makefile)
`Makefile' is up to date.
making Makefile in subdirectory .
`Makefile' is up to date.
making Makefile in subdirectory Parser
`Makefile' is up to date.
making Makefile in subdirectory Objects
`Makefile' is up to date.
making Makefile in subdirectory Python
`Makefile' is up to date.
making Makefile in subdirectory Modules
        (rm -f Modules/hassignal; cd Modules; make hassignal)
        rm -f hassignal
        for i in threadmodule.o  regexmodule.o regexpr.o  pcremodule.o pypcre.o  posixmodule.o  signalmodule.o  arraymodule.o  cmathmodule.o  mathmodule.o  stropmodule.o  structmodule.o  timemodule.o  operator.o  fcntlmodule.o  pwdmodule.o  grpmodule.o  selectmodule.o  socketmodule.o  errnomodule.o  md5module.o md5c.o  shamodule.o  rotormodule.o  newmodule.o  binascii.o  parsermodule.o  cStringIO.o  cPickle.o config.o getpath.o main.o getbuildinfo.o; do \
                    if test "$i" = "signalmodule.o"; then \
                       echo yes >hassignal; break; \
                    fi; \
                done
        cd Parser ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Objects ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Python ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        cd Modules ; make OPT="-g -O2" VERSION="1.5" \
                        prefix="/usr/local" exec_prefix="/usr/local" all
        if test ! -f libpython1.5.a; \
                then for i in Parser Objects Python Modules; do rm -f $i/add2lib; done; true; \
                else true; fi
        for i in Parser Objects Python Modules; do \
                        (cd $i; make VERSION="1.5" add2lib); done
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
`add2lib' is up to date.
        rm -f ./Lib/test/*.py[co]
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11423 Memory fault(coredump)
*** Error exit code 139 (ignored)
        PYTHONPATH= ./python ./Lib/test/regrtest.py 
pthread_mutex_init: Invalid argument
sh: 11425 Memory fault(coredump)
*** Error exit code 139

Stop.

I need python 1.5.2 for compiling Zope 2.0 (which only needs python in this version with threads). It seems the same error as bug # 130029, but I can submit a coredump. Can anybody help me? You can use this HP-UX-machine for checking the compilation :-) 

bye Tom


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-15 23:48

Message:
Logged In: NO 

I've got the same problem. 
The problem was solved by changes in makefiles.
You should specify some additional D-flags, and
one or more libraries.
If anybody need more details, I'l be responsible on
gpu@swisslog-service.de

regards,
gpu

----------------------------------------------------------------------

Comment By: T Farrell (glory_2_god)
Date: 2001-04-05 11:27

Message:
Logged In: YES 
user_id=11441

harripasanen has the solution nailed.  Unfortunately, just 
how to do this escapes many people.  I will explain a bit 
more thoroughly, so people who come across this by a google 
search (as I did) will have more info.
This is for HP-UX 11.00, Python-2.0, compiling with GNU 
tools:
./configure --with-threads
make
rm python
cd Modules
gcc -Wl,-E -Wl,+s -Wl,+b/lib/python2.0/lib-dynload \
    python.o ../libpython2.0.a -lnsl -ldld \
    -lpthread -lm -o python
mv python ..
make install

Happy Zoping :)
PS. If you built zope before, don't forget to 
python wo_pcgi.py

----------------------------------------------------------------------

Comment By: Harri Pasanen (harripasanen)
Date: 2001-04-04 07:19

Message:
Logged In: YES 
user_id=77088

If it is HP-UX 11.00, just perform the final link of python
manually, replacing -lcma with -lpthread

-Harri

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:50

Message:
Another for the eternal HP-UX pile.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231377&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 10:19:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 02:19:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-442501 ] class.__module__ in 2.2
Message-ID: <E15XJJ6-000379-00@usw-sf-web1.sourceforge.net>

Bugs item #442501, was opened at 2001-07-18 11:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: class.__module__ in 2.2

Initial Comment:
The following little test script for Python 2.2

----
class foo:
   pass
class bar(object):
   pass

print foo.__module__
print bar.__module__
----

prints
__main__
__builtin__

IMHO it should print __main__ twice.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 02:19

Message:
Logged In: YES 
user_id=6380

Fixed in CVS: typeobject.c rev. 2.35.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-18 11:21

Message:
Logged In: YES 
user_id=6380

Yes, you're right.  I need to figure out a way to set the
__module__ property properly.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442501&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 11:47:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 03:47:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-444514 ] raw-unicode-escape codec fails roundtrip
Message-ID: <E15XKgG-0004Rc-00@usw-sf-web1.sourceforge.net>

Bugs item #444514, was opened at 2001-07-25 09:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: raw-unicode-escape codec fails roundtrip

Initial Comment:
On wide Python builds, the raw-unicode-escape codec
fails the round-trip for non-BMP code points.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 03:47

Message:
Logged In: YES 
user_id=38388

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444514&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 11:47:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 03:47:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-438164 ] Format operator % fails with unicode
Message-ID: <E15XKgr-0004S6-00@usw-sf-web1.sourceforge.net>

Bugs item #438164, was opened at 2001-07-03 00:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chema Cortщs (chemacortes)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Format operator % fails with unicode

Initial Comment:
A dictionary with unicode keys raise an error when it 
is applied to a string throught the format operator %.

Here is the ofending code:

>>> "%(aёo)d" % { u"aёo":2001 }  # KeyError: aёo

This fails because u"aёo" and "aёo" cannot be 
compared: byte strings and Unicode strings are 
comparable only if the byte string is ASCII.

> >>> u"%(aёo)4d" % { u"aёo":2001 }  # KeyError: aУБo

This fails because the key is converted to UTF-8 
before lookup.


Must be add the unicode case into the format operator %

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 03:47

Message:
Logged In: YES 
user_id=38388

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438164&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 11:48:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 03:48:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E15XKhb-0004Sx-00@usw-sf-web1.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 06:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: None
>Priority: 3
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Codec naming scheme and aliasing support

Initial Comment:
The docs should contain a note about the codec naming scheme,
the use of codec packages and how to address them in the
encoding name and some notes about the aliasing support
which is available for codecs which are found by the standard
codec search function in the encodings package.

Here's a starter (actually a posting to python-dev, but it has all
the needed details):
"""
I just wanted to inform you of a change I plan for the standard
encodings search function to enable better support for aliasing
of encoding names.

The current implementation caches the aliases returned from the
codecs .getaliases() function in the encodings lookup cache
rather than in the alias cache. As a consequence, the hyphen to
underscore mapping is not applied to the aliases. A codec would
have to return a list of all combinations of names with hyphens
and underscores in order to emulate the standard lookup 
behaviour.

I have a ptach which fixes this and also assures that aliases
cannot be overwritten by codecs which register at some later
point in time. This assures that we won't run into situations
where a codec import suddenly overrides behaviour of previously
active codecs. [The patch was checked into CVS on 2000-12-12.]

I would also like to propose the use of a new naming scheme
for codecs which enables drop-in installation. As discussed
on the i18n-sig list, people would like to install codecs
without having the users to call a codec registration function
or to touch site.py.

The standard search function in the encodings package has a
nice property (which I only noticed after the fact ;) which
allows using Python package names in the encoding names,
e.g. you can install a package 'japanese' and the access the
codecs in that package using 'japanese.shiftjis' without
having to bother registering a new codec search function
for the package -- the encodings package search function
will redirect the lookup to the 'japanese' package.

Using package names in the encoding name has several
advantages:
* you know where the codec comes from
* you can have mutliple codecs for the same encoding
* drop-in installation without registration is possible
* the need for a non-default encoding package is visible in the
  source code
* you no longer need to drop new codecs into the Python
  standard lib

"""


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 03:48

Message:
Logged In: YES 
user_id=38388

This should probably become a PEP...

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225476&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 11:49:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 03:49:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-222395 ] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <E15XKiV-0004Tn-00@usw-sf-web1.sourceforge.net>

Bugs item #222395, was opened at 2000-11-14 05:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=222395&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: M.-A. Lemburg (lemburg)
>Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Initial Comment:
I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\sveta\unicode\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\sveta\unicode\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-14 06:43

Message:
Some background:

.readline() is implemented in the way it is because all other
techniques would require adding real buffering to the codec (AFAIK.
at least) and this is currently out of scope.

Besides, there is another problem:  line breaking in Unicode is much
more difficult to get right than for plain ASCII, since there are a lot
more line break characters to watch out for.

.readline() is currently relying on the underlying stream to do the
line breaking. Since this doesn't know anything about encodings
it will break lines at single bytes. As a result, the input data for the
codec is broken.

To correct the problem, one would have to write a true UTF-16 codec
which implements buffering. This should be doable in Python, e.g. see
how StringIO does it. The codec would then have to read the
input data in chunks of say 1024 bytes (must be even), then
pass the data through the codec and use the .splitlines() method on
the Unicode output. Data which is not on  the current line would
have to be buffered until the next call to .read() or .readline().

Unfortunately, this technique will also break .tell(), .truncate() and friends...
it's a mess.

An easy work-around is reading in the file as a whole and then
using .splitlines() to get at the lines.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-14 06:09

Message:
A little bit of debugging suggests that the StreamReader.readline() method is naive: it calls the underlying stream's readline() method. Since in the example code the underlying stream is a regular 8-bit file, this will return an odd number of byte in the example. Because of the little-endian encoding; the file contains these hex bytes: 61 00 62 00 63 00 0a 00 ... (0a being '\n').

I'm not familiar enough with this class to tell whether this is simply inappropriate use of StreamReader, or that this should be fixed. Maybe Marc-Andre can answer t least that question?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-14 06:02

Message:
One for Marc-Andre. (Unfortunately he's announced he'll be too busy to look at bugs this year, so if someone else has a smart idea, feel free to butt in!)

This was originally classified as a Windows bug, but it's platform independent (I can reproduce it on Linux as well).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=222395&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 11:50:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 03:50:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-433882 ] UTF-8: unpaired surrogates mishandled
Message-ID: <E15XKj3-0004VD-00@usw-sf-web1.sourceforge.net>

Bugs item #433882, was opened at 2001-06-17 04:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433882&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF-8: unpaired surrogates mishandled

Initial Comment:
Two bugs:

1. UTF-8 encoding of unpaired high surrogate produces 
an invalid UTF-8 byte sequence.

2. UTF-8 decoding of any unpaired surrogate produces
an exception ("illegal encoding") instead of the 
corresponding 16-bit scalar value.

See attached file utf8bugs.py for example plus detailed
remarks.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 03:50

Message:
Logged In: YES 
user_id=38388

I'll look into this after I'm back from vacation on the 10.09.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-17 19:03

Message:
Logged In: YES 
user_id=21627

I think the codec should reject unpaired surrogates both 
when encoding and when decoding. I don't have a copy of 
ISO 10646, but Unicode 3.1 points out

# ISO/IEC 10646 does not allow mapping of unpaired 
surrogates, nor U+FFFE and U+FFFF (but it does allow other 
noncharacters).

So apparently, encoding unpaired surrogates as UTF-8 is 
not allowed according to ISO 10646. I think Python should 
follow this rule, instead of the Unicode one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433882&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 14:33:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 06:33:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XNHP-0004OY-00@usw-sf-web2.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 14:59:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 06:59:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-451556 ] bad tags in HTML documentation
Message-ID: <E15XNgY-0002cO-00@usw-sf-web3.sourceforge.net>

Bugs item #451556, was opened at 2001-08-16 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad tags in HTML documentation

Initial Comment:
just grabbed the HTML versions of the 2.1.1 
documentation, and found a couple of rather 
interesting HTML tags in there:

<character>
<cdata>
<command>
<tex2html_cross_ref_visible_mark>
<tex2html_ampersand_mark>

can/should this be fixed?

(to find the culprits, run tidy on the files, and look 
for Error lines.  or use grep...)

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 15:01:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 07:01:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-451107 ] re.sub does not replace slahes (2.2a1)
Message-ID: <E15XNhp-0002dn-00@usw-sf-web3.sourceforge.net>

Bugs item #451107, was opened at 2001-08-15 01:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470

>Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mihai (muqker)
>Assigned to: Fredrik Lundh (effbot)
Summary: re.sub does not replace slahes (2.2a1)

Initial Comment:
Python  2.2a1:
>>> re.findall ('\\', 'a\')
['\']

but

>>> re.sub ('\\', 'b', 'a\')
'a\'
>>>

Python 2.0.1:
>>> re.sub ('\\', 'b', 'a\')
'ab'
>>>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:11:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:11:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XOoJ-0005j4-00@usw-sf-web2.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gordon B. McMillan (gmcm)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:12:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:12:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-449880 ] File size limit exceeded causes ABEND
Message-ID: <E15XOpM-0005k5-00@usw-sf-web2.sourceforge.net>

Bugs item #449880, was opened at 2001-08-10 11:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: File size limit exceeded causes ABEND

Initial Comment:
The following code will never run to completion on
systems with a 2GB file size limit. The interpreter
exits as soon as it exceeds the file size limit.

Create a file called "testfile" that is 2GB - 1 in
size. Run the following program to observe behaviour.

#!/usr/bin/env python2
#
# Create a file called "testfile" that is 2147483647
bytes in size. Then
# run this application. The python interpreter prints
the message "File
# size limit exceeded" and exits, rather than raising
an exception. 
#
# Tested with Python-2.1.1 on Red Hat 7.2 beta (Roswell)

fp = open('testfile', 'a')

try:
	fp.write('foo')
	fp.flush()
	fp.close()
except OSError, e:
	print e

print "done"



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:12

Message:
Logged In: YES 
user_id=6380

I've got no feedback.  I'm just assuming it works.

Fixed in CVS: pythonrun.c:2.145.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:04

Message:
Logged In: YES 
user_id=6380

Please try this patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 12:01

Message:
Logged In: YES 
user_id=6380

Yes, this is a bug.

It happens in the fp.flush() call.  This does a write() that
would cause the file size to exceed the limit, and such a
write receives a SIGXFSZ signal - a signal similar to
SIGPIPE.

A workaround is to do this before writing such a large file:

import signal
signal.signal(signal.SIGXFSZ, signal.SIG_IGN)

Python should ignore the SIGXFSZ signal, if it exists, just
like it ignores SIGPIPE.

I wonder, are there any other signals that we would want to
ignore like this?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449880&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:13:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:13:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-449989 ] Make dir() more b/w compatible
Message-ID: <E15XOpx-0003o5-00@usw-sf-web3.sourceforge.net>

Bugs item #449989, was opened at 2001-08-10 20:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449989&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Tim Peters (tim_one)
Summary: Make dir() more b/w compatible

Initial Comment:
The new dir() semantics are incompatible with Python
2.1 and before, because e.g. dir([]) returns [] instead
of ['append', ...].

One possibility would be to change dir() to use the new
introspection rules to give all instance variables and
all methods that are discoverable using the new
introspection API.

Though for classes I would not want to show the
metaclass attributes, and maybe I'd make an exception
for modules -- it may be confusing to see dir(sys)
return __class__, __getattr__ and so on.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:13

Message:
Logged In: YES 
user_id=6380

Tim, would you mind implementing this?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-10 20:52

Message:
Logged In: YES 
user_id=6380

(The idea here is that giving *more* information than before
is less likely to break old code or cause misgivings than
giving *less* information.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449989&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:27:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:27:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-449151 ] Multiple interpreters break exceptions
Message-ID: <E15XP3i-0005yD-00@usw-sf-web2.sourceforge.net>

Bugs item #449151, was opened at 2001-08-08 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449151&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Multiple interpreters break exceptions

Initial Comment:
When creating multiple interpreters, the initialization
of exceptions in the second interpreter created
overwrites the globals set by the first interpreter,
thereby messing up the identities of exceptions.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 08:27

Message:
Logged In: YES 
user_id=12800

Reassigning back to Guido to remind him to take a closer
look, and provide more information.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-13 16:02

Message:
Logged In: YES 
user_id=12800

This might be related to SF bug #422004, but then again it
may not.  So far I found a reproducible problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449151&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:38:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:38:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-451309 ] don't store traceback objects
Message-ID: <E15XPE6-0000ZM-00@usw-sf-web1.sourceforge.net>

Bugs item #451309, was opened at 2001-08-15 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Steve Purcell (purcell)
Summary: don't store traceback objects

Initial Comment:
A TestResult object stores the exceptions raised when
tests fail.  The only use of these stored tracebacks,
it seems, is to print a stack trace when the test run's
report is generated.

The traceback objects, however, keep pointers to a bunch
of objects that might otherwise be garbage collected. 
I ran into this on Windows, where the traceback was
keeping a file object alive.  Because the file object
was not collected, my tearDown() method could not
remove the file.

This patch changes unittest to generate the formatted
traceback immediately, so that it does not keep
tracebacks around any longer than needed.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-16 08:38

Message:
Logged In: YES 
user_id=31392

I think this feature is more trouble than it's worth. If
a testrunner wants to capture the actual exception, it
could easily override the addError or addFailure method to 
get the traceback then.

The cost of the feature is high, particularly since it is
not used by anyone.  The effects of preserving tracebacks
can be hard to discern, and I expect when it happens it
will cause a lot of confusion.  In my case, two experienced
Python programmers, who are novices with unittest, spent
several hours trying to figure out what went wrong.

I don't think updating the docs will be particularly
helpful, because this situation is somewhat unusual and
the current behavior so surprising.


----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2001-08-15 14:46

Message:
Logged In: YES 
user_id=21477

Hi Jeremy,

This behaviour is actually known and intentional; the 
dangers are documented as a caveat in the PyUnit docs. The 
intention was that a test runner (GUI or otherwise) could 
potentially make the traceback available for inspection 
when a test fails, to aid in debugging.

In your particular case, relying on GC to close the file 
might have caused problems with following code even if 
PyUnit didn't store the traceback.

Overall I'd prefer to keep storing the tracebacks, 
especially since they only get stored when tests fail. It 
would be worth me adding a note about GC interaction to 
the docs, though.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:46:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:46:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-451597 ] Solaris2.6 core dump in test_struct.py
Message-ID: <E15XPLZ-0000hg-00@usw-sf-web1.sourceforge.net>

Bugs item #451597, was opened at 2001-08-16 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451597&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: William S. Annis (wsannis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris2.6 core dump in test_struct.py

Initial Comment:
/s/src/python/Python-2.2a1 $
/test_struct.py             <
trying: xcbhilfd
trying: xcBHILfd
trying: @xcbhilfd
trying: @xcBHILfd
trying: <xcbhilfd
trying: <xcBHILfd
trying: >xcbhilfd
trying: >xcBHILfd
trying: =xcbhilfd
trying: =xcBHILfd
trying: !xcbhilfd
trying: !xcBHILfd
'c' 'a' 'a' 'a'
'xc' 'a' '\x00a' '\x00a'
'cx' 'a' 'a\x00' 'a\x00'
's' 'a' 'a' 'a'
'0s' 'helloworld' '' ''
'1s' 'helloworld' 'h' 'h'
'9s' 'helloworld' 'helloworl' 'helloworl'
'10s' 'helloworld' 'helloworld' 'helloworld'
'11s' 'helloworld' 'helloworld\x00' 'helloworld\x00'
'20s' 'helloworld'
'helloworld\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
'helloworld\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
'b' 7 '\x07' '\x07'
'b' -7 '\xf9' '\xf9'
'B' 7 '\x07' '\x07'
'B' 249 '\xf9' '\xf9'
'h' 700 '\x02\xbc' '\xbc\x02'
'h' -700 '\xfdD' 'D\xfd'
'H' 700 '\x02\xbc' '\xbc\x02'
'H' 64836 '\xfdD' 'D\xfd'
'i' 70000000 '\x04,\x1d\x80' '\x80\x1d,\x04'
'i' -70000000 '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'I' 70000000L '\x04,\x1d\x80' '\x80\x1d,\x04'
'I' 4224967296L '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'l' 70000000 '\x04,\x1d\x80' '\x80\x1d,\x04'
'l' -70000000 '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'L' 70000000L '\x04,\x1d\x80' '\x80\x1d,\x04'
'L' 4224967296L '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'f' 2.0 '@\x00\x00\x00' '\x00\x00\x00@'
'd' 2.0 '@\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00@'
'f' -2.0 '\xc0\x00\x00\x00' '\x00\x00\x00\xc0'
'd' -2.0 '\xc0\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00\xc0'
Bus Error(coredump)

When I run ddd on the core file, the error is at 
Python-2.2a1/Modules/structmodule.c:704.  Backtrace:

(gdb) bt
#0  0xef3c38d4 in np_longlong (p=0x15ae64 "",
v=0xeffff508, f=0xef3d5564) at
/s/src/python/Python-2.2a1/Modules/structmodule.c:704
#1  0xef3c2910 in struct_pack (self=0x2, args=0x1e0254)
at
/s/src/python/Python-2.2a1/Modules/structmodule.c:1362
#2  0x2960c in call_cfunction (func=0x15376c,
arg=0x1e0254, kw=0x15ae64) at Python/ceval.c:3073
#3  0x25714 in eval_frame (f=0x17eecc) at
Python/ceval.c:1913
#4  0x26f18 in PyEval_EvalCodeEx (co=0x1e2938,
globals=0x17f018, locals=0x1e186a, args=0x0,
argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2518
#5  0x29558 in PyEval_EvalCode (co=0x1e2938,
globals=0xec514, locals=0xec514) at Python/ceval.c:491
#6  0x49018 in run_node (n=0x14b2b8, filename=0x1e2938
"", globals=0xec514, locals=0xec514, flags=0xeffffa5c)
at Python/pythonrun.c:1057
#7  0x48fc4 in run_err_node (n=0x14b2b8,
filename=0x1e2938 "", globals=0xec514, locals=0xec514,
flags=0xeffffa5c) at Python/pythonrun.c:1044
#8  0x48ba8 in PyRun_FileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
start=967956, globals=0xec514, locals=0xec514,
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:1035
#9  0x47628 in PyRun_SimpleFileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:672
#10 0x486f4 in PyRun_AnyFileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:482
#11 0x1e81c in Py_Main (argc=2, argv=0xeffffb44) at
Modules/main.c:320
#12 0x1e1e4 in main (argc=2, argv=0xeffffb44) at
Modules/python.c:10

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451597&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:51:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:51:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-451598 ] mimetypes.py needs a test
Message-ID: <E15XPQW-0004LN-00@usw-sf-web3.sourceforge.net>

Bugs item #451598, was opened at 2001-08-16 08:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451598&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: mimetypes.py needs a test

Initial Comment:
The mimetypes.py module needs a regression test.  The
test should be independent of the user's environment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451598&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 16:58:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 08:58:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-451605 ] socket module missing SSL docs
Message-ID: <E15XPXF-0004Sm-00@usw-sf-web3.sourceforge.net>

Bugs item #451605, was opened at 2001-08-16 08:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451605&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: socket module missing SSL docs

Initial Comment:
socket module documentation is missing a description of
the SSL support, both the interfaces and objects.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451605&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:00:15 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:00:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests
Message-ID: <E15XPZ9-0004US-00@usw-sf-web3.sourceforge.net>

Bugs item #451607, was opened at 2001-08-16 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Martin v. Lіwis (loewis)
Summary: SSL support in socket module needs tests

Initial Comment:
SSL support in the socket module should have a
regression test, either in test_socket.py or in a
separate test_ssl.py file.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:02:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:02:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-451605 ] socket module missing SSL docs
Message-ID: <E15XPbm-0000xb-00@usw-sf-web1.sourceforge.net>

Bugs item #451605, was opened at 2001-08-16 08:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451605&group_id=5470

Category: Documentation
>Group: Feature Request
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: socket module missing SSL docs

Initial Comment:
socket module documentation is missing a description of
the SSL support, both the interfaces and objects.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-16 09:02

Message:
Logged In: YES 
user_id=3066

Duplicate of bug #215026.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451605&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:03:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:03:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XPcF-0004XF-00@usw-sf-web3.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-16 09:03

Message:
Logged In: YES 
user_id=4923

Hmm. In the (simplistic) case I was trying, I can't see any 
significant difference between the lambda and the 
equivalent function (names differ, and the func has 2 
appended & apparently unreachable bytecodes, but otherwise 
the func_* and func_code.co_* attributes match). So what am 
I missing?

Lowering priority - I can live without it easily enough.

But if lambda's won't load, they probably shouldn't dump.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:04:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:04:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E15XPdO-0004Y8-00@usw-sf-web3.sourceforge.net>

Bugs item #425370, was opened at 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

>Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:04

Message:
Logged In: YES 
user_id=12800

I believe it is easy to fix (see attached patch), but I
don't have a way of testing it.  There appears to be no
regression test for SSL support, nor is there documentation,
so I have no idea how to /use/ the SSL support in socket module.

Assigning back to Jeremy to double check the patch.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:18

Message:
Logged In: YES 
user_id=31392

Barry, This is a memory leak/free problem, right? So you 
get it.  Seriously, sounds like this would be easy to fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:29:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:29:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-451622 ] xdrlib Packer performance-bug
Message-ID: <E15XQ1G-0004um-00@usw-sf-web3.sourceforge.net>

Bugs item #451622, was opened at 2001-08-16 09:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451622&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: xdrlib Packer performance-bug

Initial Comment:
xrdlib.py's Packer class's pack_whatever functions all 
work by self.__buf = self.__buf + something.  If a 
Packer is used to pack many data items, this leads to 
degraded (quadratic) performance, like always when a 
big string is built up by such concatenation of small 
ones.  Suggested fix: have a self.__aubuf auxiliary 
list set to [] on __init__; change each concatenation 
to __buf into self.__aubuf.append(something); in 
method get_buffer, update the __buf "just in time" via 
self.__buf += ''.join(self.__aubuf), then of course 
self.__aubuf = [], before returning self.__buf to the 
caller.

This may be fixed in other ways of course, but the 
suggested fix seems very simple and safe.


Alex


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451622&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:31:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:31:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XQ3Q-0004we-00@usw-sf-web3.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:31

Message:
Logged In: YES 
user_id=6380

I guess what you're missing is that pickling a function
doesn't pickle the bytecode! It pickles the name instead. So
a reference to "foo.bar" is pickled as "foo.bar", and the
unpickler imports bar from foo.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-16 09:03

Message:
Logged In: YES 
user_id=4923

Hmm. In the (simplistic) case I was trying, I can't see any 
significant difference between the lambda and the 
equivalent function (names differ, and the func has 2 
appended & apparently unreachable bytecodes, but otherwise 
the func_* and func_code.co_* attributes match). So what am 
I missing?

Lowering priority - I can live without it easily enough.

But if lambda's won't load, they probably shouldn't dump.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:34:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:34:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E15XQ5q-0006rf-00@usw-sf-web2.sourceforge.net>

Bugs item #425370, was opened at 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:34

Message:
Logged In: YES 
user_id=6380

Testing SSL support is easy in interactive mode, e.g.
urllib.urlopen("https://www.openair.com/index.pl")

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:04

Message:
Logged In: YES 
user_id=12800

I believe it is easy to fix (see attached patch), but I
don't have a way of testing it.  There appears to be no
regression test for SSL support, nor is there documentation,
so I have no idea how to /use/ the SSL support in socket module.

Assigning back to Jeremy to double check the patch.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:18

Message:
Logged In: YES 
user_id=31392

Barry, This is a memory leak/free problem, right? So you 
get it.  Seriously, sounds like this would be easy to fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:49:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:49:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-451597 ] Solaris2.6 core dump in test_struct.py
Message-ID: <E15XQKU-0001jP-00@usw-sf-web1.sourceforge.net>

Bugs item #451597, was opened at 2001-08-16 08:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451597&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: William S. Annis (wsannis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris2.6 core dump in test_struct.py

Initial Comment:
/s/src/python/Python-2.2a1 $
/test_struct.py             <
trying: xcbhilfd
trying: xcBHILfd
trying: @xcbhilfd
trying: @xcBHILfd
trying: <xcbhilfd
trying: <xcBHILfd
trying: >xcbhilfd
trying: >xcBHILfd
trying: =xcbhilfd
trying: =xcBHILfd
trying: !xcbhilfd
trying: !xcBHILfd
'c' 'a' 'a' 'a'
'xc' 'a' '\x00a' '\x00a'
'cx' 'a' 'a\x00' 'a\x00'
's' 'a' 'a' 'a'
'0s' 'helloworld' '' ''
'1s' 'helloworld' 'h' 'h'
'9s' 'helloworld' 'helloworl' 'helloworl'
'10s' 'helloworld' 'helloworld' 'helloworld'
'11s' 'helloworld' 'helloworld\x00' 'helloworld\x00'
'20s' 'helloworld'
'helloworld\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
'helloworld\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
'b' 7 '\x07' '\x07'
'b' -7 '\xf9' '\xf9'
'B' 7 '\x07' '\x07'
'B' 249 '\xf9' '\xf9'
'h' 700 '\x02\xbc' '\xbc\x02'
'h' -700 '\xfdD' 'D\xfd'
'H' 700 '\x02\xbc' '\xbc\x02'
'H' 64836 '\xfdD' 'D\xfd'
'i' 70000000 '\x04,\x1d\x80' '\x80\x1d,\x04'
'i' -70000000 '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'I' 70000000L '\x04,\x1d\x80' '\x80\x1d,\x04'
'I' 4224967296L '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'l' 70000000 '\x04,\x1d\x80' '\x80\x1d,\x04'
'l' -70000000 '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'L' 70000000L '\x04,\x1d\x80' '\x80\x1d,\x04'
'L' 4224967296L '\xfb\xd3\xe2\x80' '\x80\xe2\xd3\xfb'
'f' 2.0 '@\x00\x00\x00' '\x00\x00\x00@'
'd' 2.0 '@\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00@'
'f' -2.0 '\xc0\x00\x00\x00' '\x00\x00\x00\xc0'
'd' -2.0 '\xc0\x00\x00\x00\x00\x00\x00\x00'
'\x00\x00\x00\x00\x00\x00\x00\xc0'
Bus Error(coredump)

When I run ddd on the core file, the error is at 
Python-2.2a1/Modules/structmodule.c:704.  Backtrace:

(gdb) bt
#0  0xef3c38d4 in np_longlong (p=0x15ae64 "",
v=0xeffff508, f=0xef3d5564) at
/s/src/python/Python-2.2a1/Modules/structmodule.c:704
#1  0xef3c2910 in struct_pack (self=0x2, args=0x1e0254)
at
/s/src/python/Python-2.2a1/Modules/structmodule.c:1362
#2  0x2960c in call_cfunction (func=0x15376c,
arg=0x1e0254, kw=0x15ae64) at Python/ceval.c:3073
#3  0x25714 in eval_frame (f=0x17eecc) at
Python/ceval.c:1913
#4  0x26f18 in PyEval_EvalCodeEx (co=0x1e2938,
globals=0x17f018, locals=0x1e186a, args=0x0,
argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0,
closure=0x0) at Python/ceval.c:2518
#5  0x29558 in PyEval_EvalCode (co=0x1e2938,
globals=0xec514, locals=0xec514) at Python/ceval.c:491
#6  0x49018 in run_node (n=0x14b2b8, filename=0x1e2938
"", globals=0xec514, locals=0xec514, flags=0xeffffa5c)
at Python/pythonrun.c:1057
#7  0x48fc4 in run_err_node (n=0x14b2b8,
filename=0x1e2938 "", globals=0xec514, locals=0xec514,
flags=0xeffffa5c) at Python/pythonrun.c:1044
#8  0x48ba8 in PyRun_FileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
start=967956, globals=0xec514, locals=0xec514,
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:1035
#9  0x47628 in PyRun_SimpleFileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:672
#10 0x486f4 in PyRun_AnyFileExFlags (fp=0xdb8f0,
filename=0xeffffc41 "Lib/test/test_struct.py",
closeit=1, flags=0xeffffa5c) at Python/pythonrun.c:482
#11 0x1e81c in Py_Main (argc=2, argv=0xeffffb44) at
Modules/main.c:320
#12 0x1e1e4 in main (argc=2, argv=0xeffffb44) at
Modules/python.c:10

----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 09:49

Message:
Logged In: YES 
user_id=21627

This appears to be a duplicate of #442520, which was fixed
in structmodule.c 2.49. I'm closing this as a duplicate. 
If you can, please try the current CVS, or just replace your
structmodule.c with the one from the current CVS
(downloadable via SF cvsweb). 
In case the test still fails, please submit a new bug
report, pointing to this one, and pointing out that the bug
has not been fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451597&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:53:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:53:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15XQOD-00077P-00@usw-sf-web2.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

>Category: Extension Modules
Group: Platform-specific
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:53

Message:
Logged In: YES 
user_id=12800

I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024).  This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.  

selectmodule.c 2.54 has the change.

The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs.  Assigning back to
Tim for verification on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 13:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 01:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 17:54:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 09:54:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-451630 ] os.spawnv doc are slim
Message-ID: <E15XQPz-0001ok-00@usw-sf-web1.sourceforge.net>

Bugs item #451630, was opened at 2001-08-16 09:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451630&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.spawnv doc are slim

Initial Comment:
The library reference for the spawnv and spawnve
functions say to refer to the visual C++ documentation
for the meaning of the mode flags (P_WAIT, etc.).  The
doc strings in the code itself are more helpful,
explaining what the modes mean.  I'd like to see the
info in the doc strings make it into the library reference.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451630&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:01:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:01:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-451295 ] HTTPS bugs in urllib2
Message-ID: <E15XQWV-0001vd-00@usw-sf-web1.sourceforge.net>

Bugs item #451295, was opened at 2001-08-15 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451295&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: HTTPS bugs in urllib2

Initial Comment:
1. In AbstractBasicAuthHandler.retry_http_basic_auth()-
 if an HTTP error, other than 401, happens, 
authentication is disabled because 
self.__current_realm is not set to None

2. In HTTPRedirectHandler.http_error_302()- if an 
authenticated file is redirected, the old request 
header is discarded and, therefore, so is the 
authentication information.  If there is a new 
challenge, HTTP error 401 results, 
self.__current_realm is still set and authentication
is thereafter disabled.

I discovered these bugs while testing with a secure 
web site.  I made the following fixes (standard Unix 
diff format) and can be reached via email at 
bcox@semio.com:

bug #1-
631,633c649,660
<             resp = self.parent.open(req)
<             self.__current_realm = None
<             return resp
---
>             try:
>                 resp = self.parent.open(req)
>                 self.__current_realm = None
>                 return resp
> 			# prevent other HTTP errors 
from disabling authentication
>             except HTTPError, e:
>                 if e.code != 401:
>                     self.__current_realm = None
>                 raise
>             except (URLError, socket.error), e:
>                 self.__current_realm = None
>                 raise

bug #2-
447c460,465
<         new = Request(newurl, req.get_data())
---
> 
> 		# forgetting about the current state 
is not a good idea.
> 		# If this is an authenticated URL, 
then discarding the state
> 		# (i.e. the headers) will disable 
further authentication
> 
>         new = Request(newurl, req.get_data(), 
req.headers)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451295&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:02:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:02:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-449991 ] xml.dom.pulldom exception for integers
Message-ID: <E15XQXK-0001wS-00@usw-sf-web1.sourceforge.net>

Bugs item #449991, was opened at 2001-08-10 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449991&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin v. Lіwis (loewis)
Summary: xml.dom.pulldom exception for integers

Initial Comment:
>>> xml.dom.minidom.parseString(str)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.0/xml/dom/minidom.py", line 
475, in parseString
    return _doparse(pulldom.parseString, args, kwargs)
  File "/usr/lib/python2.0/xml/dom/minidom.py", line 
465, in _doparse
    toktype, rootNode = events.getEvent()
  File "/usr/lib/python2.0/xml/dom/pulldom.py", line 
187, in getEvent
    self.parser.feed(buf)
  File "/usr/lib/python2.0/xml/sax/expatreader.py", 
line 81, in feed
    self._parser.Parse(data, isFinal)
  File "/usr/lib/python2.0/xml/sax/expatreader.py", 
line 160, in start_element_ns
    AttributesNSImpl(newattrs, {}))
  File "/usr/lib/python2.0/xml/dom/pulldom.py", line 
36, in startElementNS
    tagName = self._current_context[uri] + ":" + 
localname
TypeError: bad operand type(s) for +


This happened for Python 2.0. For Python <current> the 
line may be different

Suggested fix:

On the offending line, use "str()" to force conversion 
(inquisition ;-))





----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-11 00:48

Message:
Logged In: YES 
user_id=21627

Can you give the exact document that caused this problem? 
I'm tempted to close this as "Works for me", since I've 
never seen that problem before, and can't imagine what may 
have caused it.

In case you are reading your report once more: It would 
help enormously if you'd leave some contact address for 
questions.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449991&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:08:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:08:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-451622 ] xdrlib Packer performance-bug
Message-ID: <E15XQde-00022X-00@usw-sf-web1.sourceforge.net>

Bugs item #451622, was opened at 2001-08-16 09:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451622&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: xdrlib Packer performance-bug

Initial Comment:
xrdlib.py's Packer class's pack_whatever functions all 
work by self.__buf = self.__buf + something.  If a 
Packer is used to pack many data items, this leads to 
degraded (quadratic) performance, like always when a 
big string is built up by such concatenation of small 
ones.  Suggested fix: have a self.__aubuf auxiliary 
list set to [] on __init__; change each concatenation 
to __buf into self.__aubuf.append(something); in 
method get_buffer, update the __buf "just in time" via 
self.__buf += ''.join(self.__aubuf), then of course 
self.__aubuf = [], before returning self.__buf to the 
caller.

This may be fixed in other ways of course, but the 
suggested fix seems very simple and safe.


Alex


----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 10:08

Message:
Logged In: YES 
user_id=21627

Instead of reinventing the wheel, I decided to use
cStringIO/StringIO to accumulate the bytes.
Committed as xdrlib 1.13.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451622&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:27:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:27:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XQve-0002Ku-00@usw-sf-web1.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:48:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:48:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-451638 ] [2.2a] delitem undefined for dictionary
Message-ID: <E15XRFU-0007rk-00@usw-sf-web2.sourceforge.net>

Bugs item #451638, was opened at 2001-08-16 10:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451638&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Guido van Rossum (gvanrossum)
Summary: [2.2a] delitem undefined for dictionary

Initial Comment:
Hi,

Header pretty much says what the problem is.

It's also undefined for list. The following code 
should illustrate it clearly enough


>>> class d2(dictionary):
...     def __setitem__(self, key, value):
...         if value==0:
...             del self[key]
...         else:
...             dictionary.__setitem__(self, key, 
value)
...
>>> d = d2()
>>> d.update({'a': 5})
>>> d
{'a': 5}
>>> d['a'] = 10
>>> d
{'a': 10}
>>> d['a'] = 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in __setitem__
SystemError: NULL object passed to Py_BuildValue
>>>



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451638&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:57:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:57:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-451638 ] [2.2a] delitem undefined for dictionary
Message-ID: <E15XROW-0007zk-00@usw-sf-web2.sourceforge.net>

Bugs item #451638, was opened at 2001-08-16 10:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451638&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Guido van Rossum (gvanrossum)
Summary: [2.2a] delitem undefined for dictionary

Initial Comment:
Hi,

Header pretty much says what the problem is.

It's also undefined for list. The following code 
should illustrate it clearly enough


>>> class d2(dictionary):
...     def __setitem__(self, key, value):
...         if value==0:
...             del self[key]
...         else:
...             dictionary.__setitem__(self, key, 
value)
...
>>> d = d2()
>>> d.update({'a': 5})
>>> d
{'a': 5}
>>> d['a'] = 10
>>> d
{'a': 10}
>>> d['a'] = 0
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in __setitem__
SystemError: NULL object passed to Py_BuildValue
>>>



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 10:57

Message:
Logged In: YES 
user_id=6380

This is a duplicate of bug 442791. It's fixed in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451638&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 18:57:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 10:57:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E15XROt-0002oO-00@usw-sf-web1.sourceforge.net>

Bugs item #425370, was opened at 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 10:57

Message:
Logged In: YES 
user_id=12800

Ah, or https://sf.net :)

Maybe add this as a test case to test_socket but don't bomb
out if that host isn't responding or reachable?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:34

Message:
Logged In: YES 
user_id=6380

Testing SSL support is easy in interactive mode, e.g.
urllib.urlopen("https://www.openair.com/index.pl")

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:04

Message:
Logged In: YES 
user_id=12800

I believe it is easy to fix (see attached patch), but I
don't have a way of testing it.  There appears to be no
regression test for SSL support, nor is there documentation,
so I have no idea how to /use/ the SSL support in socket module.

Assigning back to Jeremy to double check the patch.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:18

Message:
Logged In: YES 
user_id=31392

Barry, This is a memory leak/free problem, right? So you 
get it.  Seriously, sounds like this would be easy to fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 19:33:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 11:33:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XRxe-0003Nw-00@usw-sf-web1.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 20:19:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 12:19:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-451598 ] mimetypes.py needs a test
Message-ID: <E15XSfv-00048X-00@usw-sf-web1.sourceforge.net>

Bugs item #451598, was opened at 2001-08-16 08:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451598&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: mimetypes.py needs a test

Initial Comment:
The mimetypes.py module needs a regression test.  The
test should be independent of the user's environment.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-16 12:19

Message:
Logged In: YES 
user_id=3066

Lib/test/test_mimetypes.py has been added.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451598&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 20:35:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 12:35:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XSvI-0004PV-00@usw-sf-web1.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 20:37:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 12:37:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XSxO-0000wR-00@usw-sf-web2.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:37

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 20:52:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 12:52:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XTBY-0001AB-00@usw-sf-web2.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 12:52

Message:
Logged In: YES 
user_id=6380

It might be more productive to find out why it didn't work
as advertised.  I've only heard reports of one kind of
failure for the linuxaudiodev module: with some
hardware/driver combinations it plays the first second or so
of the sound file and then stops with an exception. The
failure you are experiencing is different. Until we've
figured out what went wrong on your box, I see no reason to
do either of the things you propose. (Besides, nobody reads
README files. :-)

As a workaround, su root followed by chmod 0 /dev/audio does
wonders. :-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:37

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 21:16:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 13:16:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] make test caused machine hangup
Message-ID: <E15XTZb-00054U-00@usw-sf-web1.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 13:16

Message:
Logged In: NO 

I would look into this further, but unfortunately (or
fortunately depending on your point of view) the machine in
question is being used operationally for turbulence
forecasting. We're using Python to glue the system together.
If the machine is down for routine maintenance, I'll check
into this problem.

Strangely enough, there's at least one person one reads
README files :-)

Gerry Wiener
gerry@ucar.edu

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 12:52

Message:
Logged In: YES 
user_id=6380

It might be more productive to find out why it didn't work
as advertised.  I've only heard reports of one kind of
failure for the linuxaudiodev module: with some
hardware/driver combinations it plays the first second or so
of the sound file and then stops with an exception. The
failure you are experiencing is different. Until we've
figured out what went wrong on your box, I see no reason to
do either of the things you propose. (Besides, nobody reads
README files. :-)

As a workaround, su root followed by chmod 0 /dev/audio does
wonders. :-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:37

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 21:30:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 13:30:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-441580 ] can't import readline in 2.1.1c1
Message-ID: <E15XTmc-0001fG-00@usw-sf-web2.sourceforge.net>

Bugs item #441580, was opened at 2001-07-15 21:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: can't import readline in 2.1.1c1

Initial Comment:
I get the following error for 2.1.1c1 built on SuSE 
Linux 7.1 , gcc 2.95.2 :

>>> import readline
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: undefined symbol: BC

Needless to say, this makes the interactive session 
interesting as readline is not imported on startup. 
Temporary fix for me is to use readline.so from 2.0 - 
it seems to work fine in 2.1.1c1.

Chuck


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-16 13:30

Message:
Logged In: YES 
user_id=11375

OK, I'll apply it to the CVS tree, then.  Thanks for 
trying it out!



----------------------------------------------------------------------

Comment By: Charles Harris (charris208)
Date: 2001-08-12 18:02

Message:
Logged In: YES 
user_id=271679

The patch worked for me. Thanks...Chuck


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-10 12:54

Message:
Logged In: YES 
user_id=11375

Try the patch I've now attached to the bug; does it fix 
the problem?



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-07-19 07:33

Message:
Logged In: YES 
user_id=35752

I believe that linking with ncurses is the right thing
to do if ncurses is available.  However, there are probably
systems out there that don't have ncurses but have termcap.
setup.py could decide what to link readline with based on
the HAVE_NCURSES_H define.

Andrew is better at wrangling setup.py so I'm assigning to
him.


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:25

Message:
Logged In: YES 
user_id=34209

I'm sorry, I'm not going to fix this one for 2.1.1... I need
some feedback and more than a little testing on other
platforms before I'll check in a patch that adds -lncurses
to the library list for readline.

We can fix it for 2.1.2, if necessary, and 2.2, but someone
with setup.py clue needs to look at this... Neil has shown
such before, so assigning to him :)



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-16 17:27

Message:
Logged In: NO 

Ok, I looked at the Setup file for 2.0 from SuSE. They had

readline readline.c -lreadline -lncurses #-ltermcap 

whereas 2.1.1c1 had

readline readline.c -lreadline -ltermcap

I made the change, recompiled, and everything is dandy.

Chuck 


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-16 08:11

Message:
Logged In: YES 
user_id=34209

Did this work in Python 2.1(.0) ? Nothing readline-specific
changed in 2.1.1c1... It looks like setup.py is using the
wrong libraries to link with. When you enable readline.so in
2.0's Setup file, do you edit the list of include/library
paths or libraries linked with ?

I don't have a SuSe installation to test with, unfortunately.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441580&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 21:41:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 13:41:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-437984 ] package name truncation to 50 chars.
Message-ID: <E15XTxm-0005U2-00@usw-sf-web1.sourceforge.net>

Bugs item #437984, was opened at 2001-07-02 11:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470

>Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: chris tignor (ctignor)
Assigned to: Barry Warsaw (bwarsaw)
Summary: package name truncation to 50 chars.

Initial Comment:
Truncation of package names to 50 characters once
represented as strings becomes extremely confusing for
development purposes, even more so when as it exists as
an undocumented event. I request full package names be
represented.  Thank-you.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 13:41

Message:
Logged In: YES 
user_id=12800

I don't think a fixed buffer size is necessary.  I'm
checking in a version that calculates the buf size needed on
the fly.  Thus module reprs will be accurate instead of
truncated.  The extra malloc/free overhead shouldn't be
important in a repr function.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 14:12

Message:
Logged In: YES 
user_id=31392

The code that prints these repr() has a constant size
buffer.  What constant would make you happy?


----------------------------------------------------------------------

Comment By: chris tignor (ctignor)
Date: 2001-07-06 14:36

Message:
Logged In: YES 
user_id=255620

here is an exmaple:

from com.ezways.data_mining.form_tools import
TransitFormInputElement
transitForm =
TransitFormInputElement.TransitFormInputElement()
print transitForm

# below is what prints, no such thing (module/package/class)
as TransitFormInput anywhere on the system
<com.ezways.data_mining.form_tools.TransitFormInput.TransitFormInputElement
instance at 0x81e2e44>

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:05

Message:
Logged In: YES 
user_id=31392

Can you include a more specific description of the problem 
you are having?  An example would go a long way.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=437984&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 21:54:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 13:54:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-404274 ] Linking error on AIX (Python 1.5.2)
Message-ID: <E15XU9h-0005fp-00@usw-sf-web1.sourceforge.net>

Bugs item #404274, was opened at 2001-02-26 04:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404274&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rene Liebscher (rliebscher)
Assigned to: A.M. Kuchling (akuchling)
Summary: Linking error on AIX (Python 1.5.2)

Initial Comment:
The patch from 1.32 to 1.33 of file sysconfig.py
removes some special actions for AIX and BeOS
concerning the paths to the linker scripts.

On Python 1.5.2 these parts are still needed, 
because it doesn't have this new style of Makefile
( LDSHARED and BLDSHARED )

The old version (1.5.2) has no BLDSHARED so if is not
found you could execute the old code to stay
compatible.

Or you declare that Distutils is not suited for
versions <2.X.


Error message (PyOpenGL build):
../././Modules/ld_so_aix cc
build/temp.aix-3-000769244C00-1.5/_openglmodule.o
-L/usr/local/lib -L/usr/X11/lib -L/usr/X11R6/lib
-L/usr/lib -lGL -lX11 -lXext -o
build/lib.aix-3-000769244C00-1.5/OpenGL/dynload/aix4/_opengl.so
unable to execute ../././Modules/ld_so_aix: No such
file or directory
error: command '../././Modules/ld_so_aix' failed with
exit status 1


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-16 13:54

Message:
Logged In: YES 
user_id=11375

It's too early to drop 1.5.2 support.  (When that's done, 
the Distutils version will probably be bumped to 1.1.)

I've attached a patch that brings back the old code.
With this patch, does it work with 1.5.2 again


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-02-28 20:55

Message:
Logged In: YES 
user_id=3066

Greg, you're the distutils guru...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=404274&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 21:56:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 13:56:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-409331 ] distutils does not support ObjC
Message-ID: <E15XUC6-0008Ol-00@usw-sf-web3.sourceforge.net>

Bugs item #409331, was opened at 2001-03-16 22:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470

Category: Distutils
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils does not support ObjC

Initial Comment:
Via this patch....

Index: unixccompiler.py
=======================================
============================
RCS file: /cvsroot/python/python/dist/src/Lib/
distutils/unixccompiler.py,v
retrieving revision 1.32
diff -r1.32 unixccompiler.py
70c70
<     src_extensions = [".c",".C",".cc",".cxx",".cpp"]
---
>     src_extensions = 
[".c",".C",".cc",".cxx",".cpp",".m"]


... I added ".m" as the list of suffixes to compile as 
C source on Mac OS X.  This worked just fine and 
allowed the PyObjC module to compile via a 
normal distutils based setup.py script.

I suspect that there may need to be flags?

In general, the whole makesetup mechanism 
should be coupled with distutils because 
makesetup has a bunch more knowledge about 
the specifics of dealing with certain source file 
types!???!!

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2001-08-16 13:56

Message:
Logged In: YES 
user_id=11375

A similar patch from Steve Majewski was accepted a while 
ago; in fact I believe it made into Python 2.1.1.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-03-17 22:21

Message:
Logged In: YES 
user_id=31435

Assigned to Greg Ward and changed Category to Distutils.

----------------------------------------------------------------------

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-16 23:00

Message:
Logged In: YES 
user_id=103811

That  was submitted by me [bbum@codefab.com] in 
case anywhere needs to followup.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=409331&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:21:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:21:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-425325 ] Logs from Purify and Insure(?)
Message-ID: <E15XUa8-0006Ax-00@usw-sf-web1.sourceforge.net>

Bugs item #425325, was opened at 2001-05-18 14:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Robert Minsk (rminsk)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Logs from Purify and Insure(?)

Initial Comment:
While trying to debug a memory corruption problem I may
have run across a problem in Objects/tupleobject.c. 
Line 363 reads:

for (i = o->ob_size; --i >= 0; ) {

Should it be?

for (i = o->ob_size - 1; --i >= 0; ) {

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 14:21

Message:
Logged In: YES 
user_id=12800

I'm going to close this bug because Insure/Purify reports
tend to go out of date fairly quickly, especially when the C
code undergoes as radical changes as descr-branch.  We've
got Insure and I try to routinely run it on the codebase to
find memory problems.

What is much more helpful than Purify/Insure output is
reproducible code samples that illustrate a memory problem
or leak.  The smaller and more self contained the sample is
the better (i.e. it's better to highlight one leak than
100's).  Feel free to assign any such future leak/memory
bugs to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 19:19

Message:
Logged In: YES 
user_id=31435

Changed "Summary" line to better reflect the current state, 
and reassigned to Barry.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 17:24

Message:
Logged In: YES 
user_id=132786

I just ran the code thru insure++ and you may want to look
at some of the errors...
Some of the 0 size rallocs/mallocs may be causing problems. 
The **FREE_DANGLING** may also be serious.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:53

Message:
Logged In: YES 
user_id=132786

Upon futher investigation this may be a bug in the optimizer
from the SGI 7.3.1.2m compilers.  I'm still checking....

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 15:14

Message:
Logged In: YES 
user_id=31435

I'm afraid we're both hallucinating, so reduced the 
priority again.  The  "--i >= 0" is executed before the 
loop begins, so the first value of i is in fact o->ob_size-
1.

So the question shifts to what Purify thinks is wrong.

----------------------------------------------------------------------

Comment By: Robert Minsk (rminsk)
Date: 2001-05-18 15:07

Message:
Logged In: YES 
user_id=132786

I discovered this using purify.  I am running purify on all
the python test code right now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-18 14:53

Message:
Logged In: YES 
user_id=31435

Zoomed the priority and assigned to me.  Good eye!  The 
same bug appears in listobject.c too.  I'll review all the 
xxx_traverse methods while I'm at it -- cut-&-paste bugs 
are deadly.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425325&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:22:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:22:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-451630 ] os.spawnv doc are slim
Message-ID: <E15XUb6-0006CG-00@usw-sf-web1.sourceforge.net>

Bugs item #451630, was opened at 2001-08-16 09:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451630&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.spawnv doc are slim

Initial Comment:
The library reference for the spawnv and spawnve
functions say to refer to the visual C++ documentation
for the meaning of the mode flags (P_WAIT, etc.).  The
doc strings in the code itself are more helpful,
explaining what the modes mean.  I'd like to see the
info in the doc strings make it into the library reference.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-16 14:22

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libos.tex revision 1.63.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451630&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:25:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:25:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E15XUdV-0006Fm-00@usw-sf-web1.sourceforge.net>

Bugs item #420476, was opened at 2001-05-01 09:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420476&group_id=5470

>Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 'make test' failures: AIX 4.2

Initial Comment:
Successfully built and installed Python 2.1 on AIX 
4.2.  However, 3 regression tests failed.  The output 
from 'make test' (edited for brevity) is shown below:

make test
...successful tests deleted...
test___all__
test test___all__ failed -- tty has no __all__ 
attribute
...successful tests deleted...
test_coercion
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_coercion
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + 4.0 = 6.0
2 += 4.0 => 6.0
2 - 4.0 = -2.0
2 -= 4.0 => -2.0
2 * 4.0 = 8.0
2 *= 4.0 => 8.0
2 / 4.0 = 0.5
2 /= 4.0 => 0.5
2 ** 4.0 = 16.0
2 **= 4.0 => 16.0
2 % 4.0 = 2.0
2 %= 4.0 => 2.0
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + (2+0j) = (4+0j)
2 += (2+0j) => (4+0j)
2 - (2+0j) = 0j
2 -= (2+0j) => 0j
2 * (2+0j) = (4+0j)
2 *= (2+0j) => (4+0j)
2 / (2+0j) =
*******************************************************
***************
Then ...
We expected (repr): '(1+0j)'
But instead we got: '(1-0j)'
test test_coercion failed -- Writing: '(1-0j)', 
expected: '(1+0j)'
...successful tests deleted...
test_pty
test test_pty failed -- Tail of expected stdout 
unseen: 'y pet fish, Eric.\n'
...successful tests deleted...
test_zlib
test test_zlib skipped --  No module named zlib
112 tests OK.
3 tests failed: test___all__ test_coercion test_pty
22 tests skipped: test_al test_bsddb test_cd test_cl 
test_dl test_gdbm test_gl test_gzip test_imgfile 
test_largefile test_linuxaudio
dev test_minidom test_nis test_openpty test_pyexpat 
test_sax test_sunaudiodev test_sundry test_winreg 
test_winsound test_zipfile test_zlib
make: 1254-004 The error code from the last command is 
1.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 14:25

Message:
Logged In: YES 
user_id=12800

Sorry, I've no clue about test_pty so I'm reassigning back
to Tim for all that math gibberish.

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-06-14 04:18

Message:
Logged In: YES 
user_id=119770

If you have the IBM C compiler, the magic flag is
-qfloat=nomaf. This should probably be documented in
Misc/AIX-NOTES.

According to the C for AIX manual:
  The nomaf option is provided for cases where it is
necessary to exactly duplicate the double results of an
implmeentation that does not have multiply-add operations.
The nomaf option prevents the compiler from generating any
multiply-add operations. Not using multiply-add operations
decreases accuracy and performance but strictly conforms to
the IEEE standard for double-precision arithmetic.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 11:27

Message:
Logged In: YES 
user_id=31435

test___all__ failures are always spurious (due to 
incomplete module objects left behind in sys.modules for 
other reasons -- in this case presumably related to the 
test_pty failure).

The test_coerce failure is a +0 versus -0 IEEE-754 thing.  
Platforms that produce -0 here are not computing the 
correct sign bit for (+0)-(+0) (according to the 754 
rules).  First make sure you're using whatever gibberish 
your platform C requires to produce 754-conforming code.  
If it still fails, and the HW supports any sort of fused 
multiply+add or multiply+subtract instructions, tell the 
compiler not to use them.  If it still fails, we're in for 
long and tedious platform-specific debugging work.

Assigned to Barry in case he has a clue about test_pty (I 
don't).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420476&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:40:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:40:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E15XUsX-0006Yx-00@usw-sf-web1.sourceforge.net>

Bugs item #420476, was opened at 2001-05-01 09:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420476&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Python 2.1 'make test' failures: AIX 4.2

Initial Comment:
Successfully built and installed Python 2.1 on AIX 
4.2.  However, 3 regression tests failed.  The output 
from 'make test' (edited for brevity) is shown below:

make test
...successful tests deleted...
test___all__
test test___all__ failed -- tty has no __all__ 
attribute
...successful tests deleted...
test_coercion
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_coercion
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + 4.0 = 6.0
2 += 4.0 => 6.0
2 - 4.0 = -2.0
2 -= 4.0 => -2.0
2 * 4.0 = 8.0
2 *= 4.0 => 8.0
2 / 4.0 = 0.5
2 /= 4.0 => 0.5
2 ** 4.0 = 16.0
2 **= 4.0 => 16.0
2 % 4.0 = 2.0
2 %= 4.0 => 2.0
2 + 2 = 4
2 += 2 => 4
2 - 2 = 0
2 -= 2 => 0
2 * 2 = 4
2 *= 2 => 4
2 / 2 = 1
2 /= 2 => 1
2 ** 2 = 4
2 **= 2 => 4
2 % 2 = 0
2 %= 2 => 0
2 + (2+0j) = (4+0j)
2 += (2+0j) => (4+0j)
2 - (2+0j) = 0j
2 -= (2+0j) => 0j
2 * (2+0j) = (4+0j)
2 *= (2+0j) => (4+0j)
2 / (2+0j) =
*******************************************************
***************
Then ...
We expected (repr): '(1+0j)'
But instead we got: '(1-0j)'
test test_coercion failed -- Writing: '(1-0j)', 
expected: '(1+0j)'
...successful tests deleted...
test_pty
test test_pty failed -- Tail of expected stdout 
unseen: 'y pet fish, Eric.\n'
...successful tests deleted...
test_zlib
test test_zlib skipped --  No module named zlib
112 tests OK.
3 tests failed: test___all__ test_coercion test_pty
22 tests skipped: test_al test_bsddb test_cd test_cl 
test_dl test_gdbm test_gl test_gzip test_imgfile 
test_largefile test_linuxaudio
dev test_minidom test_nis test_openpty test_pyexpat 
test_sax test_sunaudiodev test_sundry test_winreg 
test_winsound test_zipfile test_zlib
make: 1254-004 The error code from the last command is 
1.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-16 14:40

Message:
Logged In: YES 
user_id=31435

Closed for lack of followup (Anonymous hasn't responded in 
> 3 months).

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 14:25

Message:
Logged In: YES 
user_id=12800

Sorry, I've no clue about test_pty so I'm reassigning back
to Tim for all that math gibberish.

----------------------------------------------------------------------

Comment By: The Written Word (china) (tww-china)
Date: 2001-06-14 04:18

Message:
Logged In: YES 
user_id=119770

If you have the IBM C compiler, the magic flag is
-qfloat=nomaf. This should probably be documented in
Misc/AIX-NOTES.

According to the C for AIX manual:
  The nomaf option is provided for cases where it is
necessary to exactly duplicate the double results of an
implmeentation that does not have multiply-add operations.
The nomaf option prevents the compiler from generating any
multiply-add operations. Not using multiply-add operations
decreases accuracy and performance but strictly conforms to
the IEEE standard for double-precision arithmetic.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-05-11 11:27

Message:
Logged In: YES 
user_id=31435

test___all__ failures are always spurious (due to 
incomplete module objects left behind in sys.modules for 
other reasons -- in this case presumably related to the 
test_pty failure).

The test_coerce failure is a +0 versus -0 IEEE-754 thing.  
Platforms that produce -0 here are not computing the 
correct sign bit for (+0)-(+0) (according to the 754 
rules).  First make sure you're using whatever gibberish 
your platform C requires to produce 754-conforming code.  
If it still fails, and the HW supports any sort of fused 
multiply+add or multiply+subtract instructions, tell the 
compiler not to use them.  If it still fails, we're in for 
long and tedious platform-specific debugging work.

Assigned to Barry in case he has a clue about test_pty (I 
don't).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420476&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:58:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:58:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E15XVA6-0002x6-00@usw-sf-web2.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 01:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-16 14:58

Message:
Logged In: YES 
user_id=31435

Back to Barry for re-testing on Linux:  I checked in 
another version that refuses to add 3 to FD_SETSIZE 
anymore.  Fortune favors the bold.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:53

Message:
Logged In: YES 
user_id=12800

I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024).  This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.  

selectmodule.c 2.54 has the change.

The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs.  Assigning back to
Tim for verification on Windows.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 13:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 05:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 01:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 22:59:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 14:59:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-451556 ] bad tags in HTML documentation
Message-ID: <E15XVBB-0000ja-00@usw-sf-web3.sourceforge.net>

Bugs item #451556, was opened at 2001-08-16 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad tags in HTML documentation

Initial Comment:
just grabbed the HTML versions of the 2.1.1 
documentation, and found a couple of rather 
interesting HTML tags in there:

<character>
<cdata>
<command>
<tex2html_cross_ref_visible_mark>
<tex2html_ampersand_mark>

can/should this be fixed?

(to find the culprits, run tidy on the files, and look 
for Error lines.  or use grep...)

</F>

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-16 14:59

Message:
Logged In: YES 
user_id=3066

Fixed the first three (<cdata>, <character>, and <command>) by adding them to the table they were missing from in Doc/perl/python.perl revision 1.108.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 23:19:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 15:19:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-451773 ] new-style objects not weak-referencable
Message-ID: <E15XVUK-0003DK-00@usw-sf-web2.sourceforge.net>

Bugs item #451773, was opened at 2001-08-16 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style objects not weak-referencable

Initial Comment:
Objects using the new-style class types are not weakly referencable:

>>> import weakref
>>> class MyClass(object):
...    pass
...
>>> o = MyClass()
>>> weakref.ref(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'MyClass' objects are not weakly referencable


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470


From noreply@sourceforge.net  Thu Aug 16 23:33:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 15:33:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-438083 ] uu module allows hostile paths
Message-ID: <E15XViB-0007Qi-00@usw-sf-web1.sourceforge.net>

Bugs item #438083, was opened at 2001-07-02 17:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: uu module allows hostile paths

Initial Comment:
hello,

the uu module does not appear to do any checking
on the file name included in the uuencoded data.
as far as i can see, it allows absolute paths and 
will happily overwrite anything.

you can pass file objects to it, but
then the information about the file name is lost.

i've attached a sketchy patch.

   -- erno@iki.fi

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 15:33

Message:
Logged In: YES 
user_id=12800

I think I want to do this a little differently.  I'm not
psyched about the proliferation of arguments (although
warnings is nice -- I called it quiet in my long ago hacked
copy and will probably keep that in the checked in version).

Here's what I propose: for decode() out_file can be a file
pointer, a file name, 1, or None.  If it is a file
pointer/name, that is used just like now.  If it is None,
the header path is used, but if the file exists and
exception is thrown.  If it is 1, then no exception is
thrown if the file exists.  This flag means "overwrite
regardless".

Although its a bit ugly to overload the out_file parameter,
I think it's better than adding yet another argument.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 00:26:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 16:26:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-451841 ] python-mode indentation bug
Message-ID: <E15XWXL-0008Hq-00@usw-sf-web1.sourceforge.net>

Bugs item #451841, was opened at 2001-08-16 16:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451841&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode indentation bug

Initial Comment:
In test_uu.py, python-mode starts indenting weirdly
towards the bottom.  I think it's a bug in XEmacs'
21.4's buffer-syntactic-context


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451841&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 02:00:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 16 Aug 2001 18:00:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15XY0E-0001H8-00@usw-sf-web1.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 08:21:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 00:21:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15Xdwt-0007WF-00@usw-sf-web3.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 08:52:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 00:52:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows extension info needs update
Message-ID: <E15XeR1-0007tn-00@usw-sf-web3.sourceforge.net>

Bugs item #225003, was opened at 2000-12-08 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Extension manual: Windows extension info needs update

Initial Comment:
The section on building extensions on Windows needs to be updated.  A single section, shared for Unix & Windows, needs to point out the distutils approach and point to the appropriate manual.

Information about linking, DLLs/shared libraries, and use of C++ needs to be reviewed and updated.

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2001-08-17 00:52

Message:
Logged In: YES 
user_id=60314

Yes, I fully agree -- the information in the manual at 
http://python.sourceforge.net/devel-docs/ext/win-
cookbook.html is positively wrong, and one of the major 
causes of help requests in my experience -- people look for 
inexistent http://starship.python.net/crew/da/compile/, 
download the sources to get a pyconfig.h they don't need 
and look for a PC\pyconfig.h that doesn't exist, and get 
tied into knots writing a Setup file.  Seems a very serious 
situation to me.

While we wait to do it 'just right', couldn't at least the 
present erroneous text be replaced with some temporary 
pointer e.g. to some of the various posts on the subject 
(cfr http://groups.google.com/groups?
as_q=setup.py&as_uauthors=alex%20martelli for many 
examples, or my apparently popular recipe at 
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/6650
9, or...?) -- I'll be happy to write/rewrite this stuff 
with whatever mods you require, Fred, except that I can't 
seem to use the 'official' way to write Python docs (LaTex 
etc etc -- I thought a Linux box would make it easy but i'm 
still having problems setting it up, sigh).

Let me know if I can be of help in any way, but I think 
that, particularly now with the nice new material in 
chapter 2, it's a positive ill to leave chapter 4 as it is 
now...:-(


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 11:55:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 03:55:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15XhHP-0001TO-00@usw-sf-web1.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:55

Message:
Logged In: YES 
user_id=6380

Whoa.  Interesting. Which Linux version is this?

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 14:13:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 06:13:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15XjRY-0003TO-00@usw-sf-web3.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 06:13

Message:
Logged In: YES 
user_id=21627

This started in glibc 2.2, I believe, so it would appear in
Redhat 7, SuSE 7, etc.
To see the problem, you have to ./configure with
CFLAGS="-D_FILE_OFFSET_BITS=64" OPT="-O2 $(CFLAGS)"; see
pyconfig.h.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:55

Message:
Logged In: YES 
user_id=6380

Whoa.  Interesting. Which Linux version is this?

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 16:25:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 08:25:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-450510 ] results of build on Mac OS X 10.0.4
Message-ID: <E15XlUw-0005kF-00@usw-sf-web1.sourceforge.net>

Bugs item #450510, was opened at 2001-08-13 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: results of build on Mac OS X 10.0.4

Initial Comment:
I simply wanted to post my list of compiler warnings
and so on, as maybe these are things that need to be
addressed/fixed, or maybe not :)

-John Buell

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-17 08:25

Message:
Logged In: NO 

Okay, since posting my .txt file failed miserably the other
day (darn Netscape 6.1 preview ;), I'm going to cut and
paste a couple of the warnings I got building yesterday.
None are "doozies", it WILL build and install.

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from Include/pymactoolbox.h:19,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
Python/mactoolboxglue.c:97: warning: function declaration
isn't a prototype

./Modules/signalmodule.c:93: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:217: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:219: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:230: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:337: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:341: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:360: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:362: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:561: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:569: warning: function declaration
isn't a prototype

/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:240:
warnin
g: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:
In functio
n `fake_getaddrinfo':
/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:370:
warnin
g: suggest explicit braces to avoid ambiguous `else'
In file included from
/Users/jbuell/Documents/Python/python/dist/src/Modules/soc
ketmodule.c:240:
/Users/jbuell/Documents/Python/python/dist/src/Modules/getnameinfo.c:
At top lev
el:
/Users/jbuell/Documents/Python/python/dist/src/Modules/getnameinfo.c:86:
warning
: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:
In functi
on `PySocket_socket':
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:2146:
warn
ing: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:
In functi
on `PySocket_fromfd':
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:2184:
warn
ing: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:
In function 
`dbm_subscript':
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104:
warning:
 implicit declaration of function `dbm_error'
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105:
warning:
 implicit declaration of function `dbm_clearerr'
/Users/jbuell/Documents/Python/python/dist/src/Modules/nismodule.c:
In function 
`nis_cat':
/Users/jbuell/Documents/Python/python/dist/src/Modules/nismodule.c:159:
warning:
 assignment from incompatible pointer type

In file included from /System/Library/Fra
meworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCor
e.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/gestaltmodule.c:28:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/gestaltmodule.c:39:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/gestaltmodule.c:67:
w
arning: function declaration isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/macosmodule.c:28:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/icgluemodule.c:33:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:173:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:193:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:214:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:236:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:262:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:282:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:303:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:324:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:344:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:365:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:391:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:416:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:446:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:521:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:529:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:574:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:601:
w
arning: function declaration isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/macfsmodule.c:26:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/../Python/getapplbycreator.c:49:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

If anyone wants to see my complete log of this build, e-mail
me personally: dadaist@mac.com

-John Buell

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-14 18:31

Message:
Logged In: YES 
user_id=45365

Ah, thanks! I had noticed the saveFP and restFP errors suddenly popping up but I didn't know where they came from.

I'll fix this shortly, but depending on platform (I assume the '-shared' option wasn't added for nothing, so it'll be needed on some other platform, probably).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-14 10:48

Message:
Logged In: NO 

I had to make a change to setup.py to get some of the
modules to build correctly (even after Jack's changes in
cvs 8/13).  I think there is an interaction with the 
-bundle and -shared ld flags.

--Bill Noon

Index: setup.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.47
diff -r1.47 setup.py
144c144
<             args['linker_so'] = linker_so + ' -shared'
---
>             args['linker_so'] = linker_so + ''


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:23:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:23:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-452144 ] How to install some stuff to /usr/sbin
Message-ID: <E15XmPf-000674-00@usw-sf-web3.sourceforge.net>

Bugs item #452144, was opened at 2001-08-17 09:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470

Category: Distutils
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Nelson (jnelson)
Assigned to: A.M. Kuchling (akuchling)
Summary: How to install some stuff to /usr/sbin

Initial Comment:
I'd like behavior identical to "scripts" but want
certain files to go to /usr/sbin instead of /usr/bin

How can I accomplish this?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452144&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:52:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:52:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] linuxaudiodev caused machine hangup
Message-ID: <E15Xmrg-0006W7-00@usw-sf-web3.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
>Summary: linuxaudiodev caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 13:16

Message:
Logged In: NO 

I would look into this further, but unfortunately (or
fortunately depending on your point of view) the machine in
question is being used operationally for turbulence
forecasting. We're using Python to glue the system together.
If the machine is down for routine maintenance, I'll check
into this problem.

Strangely enough, there's at least one person one reads
README files :-)

Gerry Wiener
gerry@ucar.edu

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 12:52

Message:
Logged In: YES 
user_id=6380

It might be more productive to find out why it didn't work
as advertised.  I've only heard reports of one kind of
failure for the linuxaudiodev module: with some
hardware/driver combinations it plays the first second or so
of the sound file and then stops with an exception. The
failure you are experiencing is different. Until we've
figured out what went wrong on your box, I see no reason to
do either of the things you propose. (Besides, nobody reads
README files. :-)

As a workaround, su root followed by chmod 0 /dev/audio does
wonders. :-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:37

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:53:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:53:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-452154 ] globaling a variable twice issues warn
Message-ID: <E15Xmrt-00077k-00@usw-sf-web1.sourceforge.net>

Bugs item #452154, was opened at 2001-08-17 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Nobody/Anonymous (nobody)
Summary: globaling a variable twice issues warn

Initial Comment:
The following code generates a warning:

def foo():
    global dammit
    dammit = 5
    global dammit

test.py:1: SyntaxWarning: name 'dammit' is assigned to
before global declaration  def foo():

One would argue that this should still issue a warning,
but the warning it raises is a bit confusing
(especially when the two global statements are 100
lines apart).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:55:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:55:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-450543 ] round() needs a special method name
Message-ID: <E15Xmtl-0000QH-00@usw-sf-web2.sourceforge.net>

Bugs item #450543, was opened at 2001-08-13 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: round() needs a special method name

Initial Comment:
Special methods may be defined to override the builtin
functions int(), float(), etc.  However I see no way to
override the builtin function round().

I am defining a class library for manipulation of
int/float/char/etc. sequences.  My class FloatSequence
defines the method __int__ which returns an instance of
IntSequence, and so on.  For example:
int(FloatSequence(1.0, 2.4)) returns IntSequence(1,2).

However I cannot define a method __round__ in my
FloatSequence class to return an IntSequence.  Calling
round(FloatSequence(1.0, 2.3)) results in the error:

AttributeError: FloatSequence instance has no attribute
'__float__'

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:55

Message:
Logged In: YES 
user_id=6380

Would calling float() instead of round() work?  That's what
the __float__ special method is for.  Adding a new special
method is  a large amount of work, and this seems a pretty
esoteric situation, so I'm not sure it's a good idea to
accept this request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:57:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:57:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15XmwP-0006aG-00@usw-sf-web3.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Tim Peters (tim_one)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:58:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:58:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-452154 ] globaling a variable twice issues warn
Message-ID: <E15Xmx1-0007Cd-00@usw-sf-web1.sourceforge.net>

Bugs item #452154, was opened at 2001-08-17 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 3
Submitted By: Andrew Csillag (drew_csillag)
>Assigned to: Jeremy Hylton (jhylton)
Summary: globaling a variable twice issues warn

Initial Comment:
The following code generates a warning:

def foo():
    global dammit
    dammit = 5
    global dammit

test.py:1: SyntaxWarning: name 'dammit' is assigned to
before global declaration  def foo():

One would argue that this should still issue a warning,
but the warning it raises is a bit confusing
(especially when the two global statements are 100
lines apart).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:58:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:58:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-452154 ] globaling a variable twice issues warn
Message-ID: <E15Xmx9-0006bC-00@usw-sf-web3.sourceforge.net>

Bugs item #452154, was opened at 2001-08-17 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470

Category: Parser/Compiler
>Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Jeremy Hylton (jhylton)
Summary: globaling a variable twice issues warn

Initial Comment:
The following code generates a warning:

def foo():
    global dammit
    dammit = 5
    global dammit

test.py:1: SyntaxWarning: name 'dammit' is assigned to
before global declaration  def foo():

One would argue that this should still issue a warning,
but the warning it raises is a bit confusing
(especially when the two global statements are 100
lines apart).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 17:59:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 09:59:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-443238 ] Perm. in ../lib/python2.2/lib-dynload
Message-ID: <E15XmyK-0007Dn-00@usw-sf-web1.sourceforge.net>

Bugs item #443238, was opened at 2001-07-20 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Perm. in ../lib/python2.2/lib-dynload 

Initial Comment:
"make install" does not set the permissions for all *.so to a+r. Instead
u+rwx is set. All other files in the lib/python2.2 folder are fine.

Env. Linux 2.4.5 i386

Andreas

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:59

Message:
Logged In: YES 
user_id=6380

Andrew, can you look into this?

----------------------------------------------------------------------

Comment By: Allan Digiby (just_gnu_it)
Date: 2001-07-22 01:10

Message:
Logged In: YES 
user_id=277768

For a more detailed view, check out:

443490 || 2.2 Install on Linux/Mod Install Error

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443238&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:13:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:13:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-450543 ] round() needs a special method name
Message-ID: <E15XnBm-0007SR-00@usw-sf-web1.sourceforge.net>

Bugs item #450543, was opened at 2001-08-13 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 1
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: round() needs a special method name

Initial Comment:
Special methods may be defined to override the builtin
functions int(), float(), etc.  However I see no way to
override the builtin function round().

I am defining a class library for manipulation of
int/float/char/etc. sequences.  My class FloatSequence
defines the method __int__ which returns an instance of
IntSequence, and so on.  For example:
int(FloatSequence(1.0, 2.4)) returns IntSequence(1,2).

However I cannot define a method __round__ in my
FloatSequence class to return an IntSequence.  Calling
round(FloatSequence(1.0, 2.3)) results in the error:

AttributeError: FloatSequence instance has no attribute
'__float__'

----------------------------------------------------------------------

>Comment By: Tessa Lau (tlau)
Date: 2001-08-17 10:13

Message:
Logged In: YES 
user_id=112896

I agree that it's pretty esoteric, and if adding a special
method is a lot of work, then I retract this bug report. 
Conceptually, I thought of round() as a unary operator, and
so it would have been nice to have it be overridable like
the other operators.  I also don't see how float() could be
used instead of round(); I want to convert a float to an int
by rounding off the decimal portion.  Why does round() call
the __float__ special method?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:55

Message:
Logged In: YES 
user_id=6380

Would calling float() instead of round() work?  That's what
the __float__ special method is for.  Adding a new special
method is  a large amount of work, and this seems a pretty
esoteric situation, so I'm not sure it's a good idea to
accept this request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:22:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:22:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-451556 ] bad tags in HTML documentation
Message-ID: <E15XnKB-0007b9-00@usw-sf-web1.sourceforge.net>

Bugs item #451556, was opened at 2001-08-16 06:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bad tags in HTML documentation

Initial Comment:
just grabbed the HTML versions of the 2.1.1 
documentation, and found a couple of rather 
interesting HTML tags in there:

<character>
<cdata>
<command>
<tex2html_cross_ref_visible_mark>
<tex2html_ampersand_mark>

can/should this be fixed?

(to find the culprits, run tidy on the files, and look 
for Error lines.  or use grep...)

</F>

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-17 10:22

Message:
Logged In: YES 
user_id=3066

Fixed the <tex2html_ampersand_mark> (and protected against
the same problem for <tex2html_percent_mark>) in
Doc/perl/SynopsisTable.pm revision 1.8.

The cross_ref_mark will be harder.  ;-(

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-16 14:59

Message:
Logged In: YES 
user_id=3066

Fixed the first three (<cdata>, <character>, and <command>) by adding them to the table they were missing from in Doc/perl/python.perl revision 1.108.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451556&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:21:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:21:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-450543 ] round() needs a special method name
Message-ID: <E15XnJC-0000lG-00@usw-sf-web2.sourceforge.net>

Bugs item #450543, was opened at 2001-08-13 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470

Category: Python Interpreter Core
>Group: None
>Status: Closed
>Resolution: Rejected
Priority: 1
Submitted By: Tessa Lau (tlau)
Assigned to: Nobody/Anonymous (nobody)
Summary: round() needs a special method name

Initial Comment:
Special methods may be defined to override the builtin
functions int(), float(), etc.  However I see no way to
override the builtin function round().

I am defining a class library for manipulation of
int/float/char/etc. sequences.  My class FloatSequence
defines the method __int__ which returns an instance of
IntSequence, and so on.  For example:
int(FloatSequence(1.0, 2.4)) returns IntSequence(1,2).

However I cannot define a method __round__ in my
FloatSequence class to return an IntSequence.  Calling
round(FloatSequence(1.0, 2.3)) results in the error:

AttributeError: FloatSequence instance has no attribute
'__float__'

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 10:21

Message:
Logged In: YES 
user_id=6380

Ah, I misread.  __float__ won't work.

But still, round() is the wrong operator to use: while it
indeed returns a rounded value, it does not return an 'int'
-- it returns a float with an integral value (subtle
difference).

I would suggest that rather than abusing the built-in
functions int() etc., your class should define its own
non-special methods to return values other than real Python
ints. The int() function really should return an int at all
times. You are violating this, so apparently the caller
knows that the argument is an instance of your class -- so
they should be able to know to call a method that your class
defines.

I'm closing the request.

----------------------------------------------------------------------

Comment By: Tessa Lau (tlau)
Date: 2001-08-17 10:13

Message:
Logged In: YES 
user_id=112896

I agree that it's pretty esoteric, and if adding a special
method is a lot of work, then I retract this bug report. 
Conceptually, I thought of round() as a unary operator, and
so it would have been nice to have it be overridable like
the other operators.  I also don't see how float() could be
used instead of round(); I want to convert a float to an int
by rounding off the decimal portion.  Why does round() call
the __float__ special method?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:55

Message:
Logged In: YES 
user_id=6380

Would calling float() instead of round() work?  That's what
the __float__ special method is for.  Adding a new special
method is  a large amount of work, and this seems a pretty
esoteric situation, so I'm not sure it's a good idea to
accept this request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450543&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:25:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:25:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-441712 ] Exception using passive ftp with OS 390
Message-ID: <E15XnNa-0007el-00@usw-sf-web1.sourceforge.net>

Bugs item #441712, was opened at 2001-07-16 08:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441712&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Henrik Weber (hweber)
Assigned to: Nobody/Anonymous (nobody)
Summary: Exception using passive ftp with OS 390

Initial Comment:
Machines equipped with OS 390 (IBM mainframes) 
sometimes use a product called TCPaccess, built by a 
company called Interlink. Among other things this 
includes a FTP server.

Starting with Python 2.1 ftplib tries to switch to 
passive mode when one uses a command like dir. The 
syntax of the response of the TCPacess FTP server is 
not what ftplib expects, so an exception is raised. 
This is the traceback:

Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
  File "c:\programme\python21\lib\ftplib.py", line 
420, in dir
    self.retrlines(cmd, func)
  File "c:\programme\python21\lib\ftplib.py", line 
352, in retrlines
    conn = self.transfercmd(cmd)
  File "c:\programme\python21\lib\ftplib.py", line 
296, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "c:\programme\python21\lib\ftplib.py", line 
273, in ntransfercmd
    host, port = parse227(self.sendcmd('PASV'))
  File "c:\programme\python21\lib\ftplib.py", line 
514, in parse227
    if left < 0: raise error_proto, resp
error_proto: 227 Entering passive mode    
25,64,88,88,16,7


Function parse227, which raises the exception, expects 
the address and port in brackets, which the server 
doesn't deliver in this case. This causes the function 
to raise the exception shown. Passive mode is not the 
default in versions prior to Python 2.1 so the problem 
didn't show before, although versions prior to 2.1 
would have reacted the same way when trying to use 
passive mode. Although the fault is on the side of the 
server the function can easily be changed to accept 
this kind of syntax as well, which would make life 
easier for people who are trying to interface to that 
kind of machine:

diff -u ftplib.py c:/tmp/ftplib.py
--- ftplib.py   Sun Apr  8 23:24:52 2001
+++ c:/tmp/ftplib.py    Mon Jul 16 14:16:14 2001
 import os
 import sys
 import string
+import re
 
 # Import SOCKS module if it exists, else standard 
socket module socket
 try:
@@ -510,12 +511,10 @@
     if resp[:3] != '227':
         raise error_reply, resp
-    left = resp.find('(')
-    if left < 0: raise error_proto, resp
-    right = resp.find(')', left + 1)
-    if right < 0:
-        raise error_proto, resp # should 
contain '(h1,h2,h3,h4,p1,p2)'
-    numbers = resp[left+1:right].split(',')
+    tuple = re.search(r'\d{1,3},\d{1,3},\d{1,3},\d
{1,3},\d{1,3},\d{1,3}', resp).group()
+    if not tuple:
+        raise error_proto, resp
+    numbers = tuple.split(',')
     if len(numbers) != 6:
         raise error_proto, resp
     host = '.'.join(numbers[:4])


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 10:25

Message:
Logged In: YES 
user_id=6380

I've checked something along these lines in as ftplib.py rev
1.57.

Please, next time don't include context diffs in your
description.  Use the file upload (don't forget the
checkbox).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441712&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:29:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:29:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-438931 ] ftplib crash
Message-ID: <E15XnQe-0007hl-00@usw-sf-web1.sourceforge.net>

Bugs item #438931, was opened at 2001-07-05 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib crash

Initial Comment:
I've found a rather horrible problem when using ftplib.
I'm running python2.1 and linux kernel 2.4.4

I haven't had a chance to check this out on any other
machines, I don't want to bring down a server testing this.

This code makes my system hang when I try to upload a
file of 4 megs or 100 megs. It works for 22 bytes (my
other test file):

def copyDepot(self, depot):
        import ftplib, stat
        depot.mFullPath = "/tmp/" + depot.mFile
        ftp = ftplib.FTP(self.mHost)
        ftp.login(self.mUser,self.mPass)
        f = open(depot.mLocalPath, 'r+')
        ftp.storbinary("STOR " + depot.mFullPath, f, 8192)
        size = ftp.size(depot.mFullPath)
        lsize = os.stat(depot.mLocalPath)[stat.ST_SIZE]
        ftp.quit()
        print "Remote Size: ",size
        print "Local Size: ",lsize
        if size != os.stat(depot.mLocalPath)[stat.ST_SIZE]:
            raise "Size does not match!"

Any ideas? Has anybody heard of something like this
happening? What would you suggest I do to fix it if its
not python?


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 10:29

Message:
Logged In: YES 
user_id=6380

Haven't heard back in over a month. Closing this now.

I suspect this was a case of binary vs. text mode on either
the client
or the server.

Notice that the code uses mode 'r+' which doesn't make
sense,
suggesting a newbie at work.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-08 14:09

Message:
Logged In: YES 
user_id=21627

Can you analyze in more detail as to how exactly the two 
files differ (e.g. finding a byte offset and a few bytes 
around the first difference)?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:29:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:29:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-438931 ] ftplib crash
Message-ID: <E15XnR3-00072C-00@usw-sf-web3.sourceforge.net>

Bugs item #438931, was opened at 2001-07-05 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470

Category: Python Library
>Group: Irreproducible
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib crash

Initial Comment:
I've found a rather horrible problem when using ftplib.
I'm running python2.1 and linux kernel 2.4.4

I haven't had a chance to check this out on any other
machines, I don't want to bring down a server testing this.

This code makes my system hang when I try to upload a
file of 4 megs or 100 megs. It works for 22 bytes (my
other test file):

def copyDepot(self, depot):
        import ftplib, stat
        depot.mFullPath = "/tmp/" + depot.mFile
        ftp = ftplib.FTP(self.mHost)
        ftp.login(self.mUser,self.mPass)
        f = open(depot.mLocalPath, 'r+')
        ftp.storbinary("STOR " + depot.mFullPath, f, 8192)
        size = ftp.size(depot.mFullPath)
        lsize = os.stat(depot.mLocalPath)[stat.ST_SIZE]
        ftp.quit()
        print "Remote Size: ",size
        print "Local Size: ",lsize
        if size != os.stat(depot.mLocalPath)[stat.ST_SIZE]:
            raise "Size does not match!"

Any ideas? Has anybody heard of something like this
happening? What would you suggest I do to fix it if its
not python?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 10:29

Message:
Logged In: YES 
user_id=6380

Haven't heard back in over a month. Closing this now.

I suspect this was a case of binary vs. text mode on either
the client
or the server.

Notice that the code uses mode 'r+' which doesn't make
sense,
suggesting a newbie at work.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-07-08 14:09

Message:
Logged In: YES 
user_id=21627

Can you analyze in more detail as to how exactly the two 
files differ (e.g. finding a byte offset and a few bytes 
around the first difference)?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438931&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:33:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:33:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-433854 ] Wrong sys.path in weird situation
Message-ID: <E15XnVD-0007ln-00@usw-sf-web1.sourceforge.net>

Bugs item #433854, was opened at 2001-06-17 00:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433854&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Wont Fix
>Priority: 3
Submitted By: Nicholas Riley (nriley)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Wrong sys.path in weird situation

Initial Comment:
I swear, this was my normal setup! :-)  Python 2.1 on IRIX 6.5.10.

% echo $PYTHONPATH
/home/reed/njriley/usr/lib/python2.1/site-packages
% echo $PATH
/home/reed/njriley/bin/sgi:/home/reed/njriley/bin:/usr/bin/X11:/usr/local/bin:/local/bin:/usr/dcs/software/unsupported/bin:/usr/bsd:/usr/sbin:/usr/bin:/bin:/usr/etc:/etc
% python
Python 2.1 (#2, Jun 17 2001, 01:43:04) [C] on irix6
Type "copyright", "credits" or "license" for more information.
>>> import sys; print sys.path
['', '/home/reed/njriley/usr/lib/python2.1/site-packages', '/home/reed/njriley/encap/python-2.1/lib/python2.1', '/home/reed/njriley/encap/python-2.1/lib/python2.1/plat-irix6', '/home/reed/njriley/encap/python-2.1/lib/python2.1/lib-tk', '/home/reed/njriley/encap/python-2.1/lib/python2.1/lib-dynload']
>>> ^D
% ls -d /home/reed/njriley/encap
gls: /home/reed/njriley/encap: No such file or directory

So, how did it get there?  This way:

lrwx--x--x   1 njriley  reed            7 Jun 17 01:55 bin -> usr/bin/
lrwxr-xr-x   1 njriley  reed           30 Jun 17 01:46 bin/python -> ../encap/python-2.1/bin/python*

If I replace ~/bin with ~/usr/bin in my PATH, everything is fine.  Python is trying to resolve the second symlink before resolving the first one, thereby causing a problem.

--Nicholas

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 10:33

Message:
Logged In: YES 
user_id=6380

Wow.  I *think* I understand what's happening.

I don't think it's worth fixing though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433854&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 18:58:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 10:58:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-452154 ] globaling a variable twice issues warn
Message-ID: <E15Xnsu-0008AV-00@usw-sf-web1.sourceforge.net>

Bugs item #452154, was opened at 2001-08-17 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Jeremy Hylton (jhylton)
Summary: globaling a variable twice issues warn

Initial Comment:
The following code generates a warning:

def foo():
    global dammit
    dammit = 5
    global dammit

test.py:1: SyntaxWarning: name 'dammit' is assigned to
before global declaration  def foo():

One would argue that this should still issue a warning,
but the warning it raises is a bit confusing
(especially when the two global statements are 100
lines apart).


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-17 10:58

Message:
Logged In: YES 
user_id=31392

When you see the warning, you should remove the global 
declaration that comes after the assignment.  It doesn't 
seem worthwhile to add extra complexity to the compiler to 
handle this.

Maybe the function is too long if the two global decls are 
100 lines apart <0.9 wink>.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 19:11:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 11:11:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-452154 ] globaling a variable twice issues warn
Message-ID: <E15Xo5r-0007cC-00@usw-sf-web3.sourceforge.net>

Bugs item #452154, was opened at 2001-08-17 09:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470

Category: Parser/Compiler
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 3
Submitted By: Andrew Csillag (drew_csillag)
Assigned to: Jeremy Hylton (jhylton)
Summary: globaling a variable twice issues warn

Initial Comment:
The following code generates a warning:

def foo():
    global dammit
    dammit = 5
    global dammit

test.py:1: SyntaxWarning: name 'dammit' is assigned to
before global declaration  def foo():

One would argue that this should still issue a warning,
but the warning it raises is a bit confusing
(especially when the two global statements are 100
lines apart).


----------------------------------------------------------------------

>Comment By: Andrew Csillag (drew_csillag)
Date: 2001-08-17 11:11

Message:
Logged In: YES 
user_id=67436

I kinda agree that it's probably not worthwile to change the
compiler to handle this as it's probably a rare thing to
have happen.  The main reason I had the second global
statement is that I del'd the global'd variable in between
and I wasn't sure if the global would stick.  I guess I know
tha I don't have to worry about it now. :)

Thanks


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-17 10:58

Message:
Logged In: YES 
user_id=31392

When you see the warning, you should remove the global 
declaration that comes after the assignment.  It doesn't 
seem worthwhile to add extra complexity to the compiler to 
handle this.

Maybe the function is too long if the two global decls are 
100 lines apart <0.9 wink>.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452154&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 19:51:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 11:51:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XoiT-0001zY-00@usw-sf-web2.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:51

Message:
Logged In: YES 
user_id=6380

I figured it out.

In save_global(), I now try to import the module and then
extract the name from the module; this must give us the same
object. If it doesn't, raise PicklingError.

Checked in as pickle.py rev 1.50.  I can't close this yet
because cPickle needs
a similar patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:31

Message:
Logged In: YES 
user_id=6380

I guess what you're missing is that pickling a function
doesn't pickle the bytecode! It pickles the name instead. So
a reference to "foo.bar" is pickled as "foo.bar", and the
unpickler imports bar from foo.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-16 09:03

Message:
Logged In: YES 
user_id=4923

Hmm. In the (simplistic) case I was trying, I can't see any 
significant difference between the lambda and the 
equivalent function (names differ, and the func has 2 
appended & apparently unreachable bytecodes, but otherwise 
the func_* and func_code.co_* attributes match). So what am 
I missing?

Lowering priority - I can live without it easily enough.

But if lambda's won't load, they probably shouldn't dump.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 19:57:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 11:57:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-451773 ] new-style objects not weak-referencable
Message-ID: <E15XooK-0000dU-00@usw-sf-web1.sourceforge.net>

Bugs item #451773, was opened at 2001-08-16 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style objects not weak-referencable

Initial Comment:
Objects using the new-style class types are not weakly referencable:

>>> import weakref
>>> class MyClass(object):
...    pass
...
>>> o = MyClass()
>>> weakref.ref(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'MyClass' objects are not weakly referencable


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:57

Message:
Logged In: YES 
user_id=6380

This is a little tricker than I thought.

I don't want to enable weak-referencing for the 'object'
type, because that would add a weak reference slot to every
type (even list, dictionary etc.).

So I have to add a weakref slot at the same time that I add
the __dict__.  But then types using __slots__ are not
weak-referenceable.

Ideally, weak-referenceability might be a user option,
default on for types with a __dict__ but default of for
types that use __slots__ only.

Fred, would it be a safety issue if the list of weak
references were made available as a __weakrefs__ special
slot (if present)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 20:28:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 12:28:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-451773 ] new-style objects not weak-referencable
Message-ID: <E15XpIY-00017J-00@usw-sf-web1.sourceforge.net>

Bugs item #451773, was opened at 2001-08-16 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style objects not weak-referencable

Initial Comment:
Objects using the new-style class types are not weakly referencable:

>>> import weakref
>>> class MyClass(object):
...    pass
...
>>> o = MyClass()
>>> weakref.ref(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'MyClass' objects are not weakly referencable


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-17 12:28

Message:
Logged In: YES 
user_id=3066

Would it be possible to make weak-referencability a
completely separate mixin class?  I don't know enough about
the mechanics of the new material to understand the issues.

I don't think there are any problems with exposing an
__weakrefs__ attribute; the value should be the same as
returned by weakref.getweakrefs().  It should be a new list
on every reference.

Perhaps you can explain the issues here on Monday.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:57

Message:
Logged In: YES 
user_id=6380

This is a little tricker than I thought.

I don't want to enable weak-referencing for the 'object'
type, because that would add a weak reference slot to every
type (even list, dictionary etc.).

So I have to add a weakref slot at the same time that I add
the __dict__.  But then types using __slots__ are not
weak-referenceable.

Ideally, weak-referenceability might be a user option,
default on for types with a __dict__ but default of for
types that use __slots__ only.

Fred, would it be a safety issue if the list of weak
references were made available as a __weakrefs__ special
slot (if present)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 20:55:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 12:55:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-438083 ] uu module allows hostile paths
Message-ID: <E15XpiR-0002ou-00@usw-sf-web2.sourceforge.net>

Bugs item #438083, was opened at 2001-07-02 17:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: uu module allows hostile paths

Initial Comment:
hello,

the uu module does not appear to do any checking
on the file name included in the uuencoded data.
as far as i can see, it allows absolute paths and 
will happily overwrite anything.

you can pass file objects to it, but
then the information about the file name is lost.

i've attached a sketchy patch.

   -- erno@iki.fi

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-17 12:55

Message:
Logged In: YES 
user_id=12800

On second thought, I think it's fine to unconditionally
raise an exception if the suggested file already exists. 
Adding a dir argument to override doesn't seem useful since
accepting filenames for in_file and out_file is deprecated
(see the current module documentation).  Thus, the way to
avoid such an exception is to pass in a file-like object
that the application has already opened.

I'm going to change uu.py so that it always raises an
exception in this case.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 15:33

Message:
Logged In: YES 
user_id=12800

I think I want to do this a little differently.  I'm not
psyched about the proliferation of arguments (although
warnings is nice -- I called it quiet in my long ago hacked
copy and will probably keep that in the checked in version).

Here's what I propose: for decode() out_file can be a file
pointer, a file name, 1, or None.  If it is a file
pointer/name, that is used just like now.  If it is None,
the header path is used, but if the file exists and
exception is thrown.  If it is 1, then no exception is
thrown if the file exists.  This flag means "overwrite
regardless".

Although its a bit ugly to overload the out_file parameter,
I think it's better than adding yet another argument.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=438083&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 21:33:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 13:33:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-451773 ] new-style objects not weak-referencable
Message-ID: <E15XqIx-00027i-00@usw-sf-web1.sourceforge.net>

Bugs item #451773, was opened at 2001-08-16 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: new-style objects not weak-referencable

Initial Comment:
Objects using the new-style class types are not weakly referencable:

>>> import weakref
>>> class MyClass(object):
...    pass
...
>>> o = MyClass()
>>> weakref.ref(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'MyClass' objects are not weakly referencable


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 13:33

Message:
Logged In: YES 
user_id=6380

I've found a way to add it.  Read the checkin message.

Question: why is the field called 'tp_weaklistoffset'?  It
doesn't seem to be a list.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-17 12:28

Message:
Logged In: YES 
user_id=3066

Would it be possible to make weak-referencability a
completely separate mixin class?  I don't know enough about
the mechanics of the new material to understand the issues.

I don't think there are any problems with exposing an
__weakrefs__ attribute; the value should be the same as
returned by weakref.getweakrefs().  It should be a new list
on every reference.

Perhaps you can explain the issues here on Monday.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:57

Message:
Logged In: YES 
user_id=6380

This is a little tricker than I thought.

I don't want to enable weak-referencing for the 'object'
type, because that would add a weak reference slot to every
type (even list, dictionary etc.).

So I have to add a weakref slot at the same time that I add
the __dict__.  But then types using __slots__ are not
weak-referenceable.

Ideally, weak-referenceability might be a user option,
default on for types with a __dict__ but default of for
types that use __slots__ only.

Fred, would it be a safety issue if the list of weak
references were made available as a __weakrefs__ special
slot (if present)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451773&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:12:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:12:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-452220 ] __class__ assignment
Message-ID: <E15XqvC-0001Yl-00@usw-sf-web3.sourceforge.net>

Bugs item #452220, was opened at 2001-08-17 14:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452220&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 2
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __class__ assignment

Initial Comment:
When safe assignment to x.__class__ should be
supported.

It's safe when the struct layout of the old and new
class is compatinle.

A sufficient safety condition is that the struct sizes
are the same and there's a shared ancestor that also
has the same size. (varitems, GC support and
dict/weakref slots may complicate matters).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452220&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:14:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:14:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-452221 ] __dynamic__ should be on by default
Message-ID: <E15XqwK-0001Ze-00@usw-sf-web3.sourceforge.net>

Bugs item #452221, was opened at 2001-08-17 14:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452221&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 2
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __dynamic__ should be on by default

Initial Comment:
Problem: it's twice as slow! :-(

Static classes are about as fast as classic classes,
currently.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452221&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:15:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:15:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-452222 ] New features need syntax
Message-ID: <E15XqxJ-0001aI-00@usw-sf-web3.sourceforge.net>

Bugs item #452222, was opened at 2001-08-17 14:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452222&group_id=5470

Category: Type/class unification
Group: Feature Request
Status: Open
Resolution: None
Priority: 1
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: New features need syntax

Initial Comment:
Some new features, e.g. class and static methods,
__slots__, __metaclass__, __dynamic__ need syntactic
sugar.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452222&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:36:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:36:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-452230 ] future division isn't propagated
Message-ID: <E15XrIK-00038U-00@usw-sf-web1.sourceforge.net>

Bugs item #452230, was opened at 2001-08-17 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: future division isn't propagated

Initial Comment:
When I first saw this, I thought it was a bug in the 
PEP 264 patch.  Then I thought it was because 
PyEval_MergeCompilerFlags hadn't been taught about 
CO_FUTURE_DIVISION.  But I just repaired (and checked 
in) the latter, so that's not it either (although that 
was a cause of related bugs).  If it's not more 
obvious to you than it is to me, assign it back to me 
and I'll get back to it later.

C:\Code\python\PCbuild>python
Python 2.2a1+ (#21, Aug 17 2001, 17:16:14) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> from __future__ import division
>>> 1/2
0.5
>>> eval("1/2")
0
>>>

The same thing happens if you run it from file:

from __future__ import division
print 1/2
print eval("1/2")

That prints "0.5" and "0".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:41:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:41:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-452230 ] future division isn't propagated
Message-ID: <E15XrMT-0004D7-00@usw-sf-web2.sourceforge.net>

Bugs item #452230, was opened at 2001-08-17 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: future division isn't propagated

Initial Comment:
When I first saw this, I thought it was a bug in the 
PEP 264 patch.  Then I thought it was because 
PyEval_MergeCompilerFlags hadn't been taught about 
CO_FUTURE_DIVISION.  But I just repaired (and checked 
in) the latter, so that's not it either (although that 
was a cause of related bugs).  If it's not more 
obvious to you than it is to me, assign it back to me 
and I'll get back to it later.

C:\Code\python\PCbuild>python
Python 2.2a1+ (#21, Aug 17 2001, 17:16:14) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> from __future__ import division
>>> 1/2
0.5
>>> eval("1/2")
0
>>>

The same thing happens if you run it from file:

from __future__ import division
print 1/2
print eval("1/2")

That prints "0.5" and "0".


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 14:41

Message:
Logged In: YES 
user_id=6380

Looks to me like builtin_eval() doesn't do the necessary
dance to pass in any compiler flags -- it uses the old API,
PyRun_String().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:45:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:45:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15XrQn-0001zU-00@usw-sf-web3.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-17 14:45

Message:
Logged In: YES 
user_id=4923

Patch # 452239 is my attempt to patch cPickle.c to match 
Guido's patch to pickle.py.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:51

Message:
Logged In: YES 
user_id=6380

I figured it out.

In save_global(), I now try to import the module and then
extract the name from the module; this must give us the same
object. If it doesn't, raise PicklingError.

Checked in as pickle.py rev 1.50.  I can't close this yet
because cPickle needs
a similar patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:31

Message:
Logged In: YES 
user_id=6380

I guess what you're missing is that pickling a function
doesn't pickle the bytecode! It pickles the name instead. So
a reference to "foo.bar" is pickled as "foo.bar", and the
unpickler imports bar from foo.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-16 09:03

Message:
Logged In: YES 
user_id=4923

Hmm. In the (simplistic) case I was trying, I can't see any 
significant difference between the lambda and the 
equivalent function (names differ, and the func has 2 
appended & apparently unreachable bytecodes, but otherwise 
the func_* and func_code.co_* attributes match). So what am 
I missing?

Lowering priority - I can live without it easily enough.

But if lambda's won't load, they probably shouldn't dump.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 22:57:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 14:57:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-442813 ] 2.2a1: list.__getitem__ and index<0
Message-ID: <E15Xrcr-0003RM-00@usw-sf-web1.sourceforge.net>

Bugs item #442813, was opened at 2001-07-19 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter Dіrwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: 2.2a1: list.__getitem__ and index<0

Initial Comment:
list.__getitem__ doesn't handle negative indizes when 
called directly:
>>> x = [1]
>>> list.__getitem__(x, -1)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IndexError: list index out of range

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 14:57

Message:
Logged In: YES 
user_id=6380

Fixed in typeobject.c rev. 2.42.

----------------------------------------------------------------------

Comment By: Walter Dіrwald (doerwalter)
Date: 2001-08-02 09:30

Message:
Logged In: YES 
user_id=89016

BTW, __setslice__  has the same problem:
>>> x = [1,2,3,4]
>>> x.__setslice__(-2,-1, [5])
>>> x
[5, 1, 2, 3, 4]


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-20 13:33

Message:
Logged In: YES 
user_id=6380

This is deeper than it seems.

The list object  never interprets negative indices -- that's
all done under the covers of the implementation in
PySequence_GetItem().

So list.__getitem__(), which is a very thin wrapper around
the list object's tp_as_sequence->sq_item function
(list_item in listobject.c), also doesn't interpret negative
indices.

But because __getitem__ is ambiguous (it can be a sequence
or a mapping operation, with slightly different semantics),
when you define a subclass that implements __getitem__, and
you pass an instance of that subclass a negative index, the
special handling of negative indices is skipped, so a[-1]
ends up calling a.__getitem__(-1).

This is not good.  I'll have to think about a way out of
this dilemma. Moving the negative index handling into the
objects is an option, but this might break with 3rd party
sequence objects. Doing the negative index handling twice
(once in PySequence_GetItem() and again in the object) is
bad, because it changes the semantics of very large negative
indices.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442813&group_id=5470


From noreply@sourceforge.net  Fri Aug 17 23:46:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 15:46:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-452252 ] __iadd__ sets object to None
Message-ID: <E15XsOB-00043d-00@usw-sf-web1.sourceforge.net>

Bugs item #452252, was opened at 2001-08-17 15:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452252&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Shipman (shipman)
Assigned to: Nobody/Anonymous (nobody)
Summary: __iadd__ sets object to None

Initial Comment:
Here's my version info:

ActivePython 2.1, build 211 (ActiveState)
based on Python 2.1 (#1, Jun 15 2001, 02:52:41) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2

If I overload `+=' in a class using an __iadd__
method, the object is replaced by None.  Here's
a script that demonstrates the problem:

=====================================================
#!/usr/local/bin/python
#--
# iadd:  See if __iadd__ actually works
#--

class C:
    def __init__ ( self, value ):
        self.value  =  value

    def __str__ ( self ):
        return "C<%s>" % self.value

    def __repr__ ( self ):
        return str(self)

    def __iadd__ ( self, x ):
        self.value  =  self.value + x

# - - - - -   m a i n   - - - - -

c = C(37)
print "Before:", c

c += 10
print "Add 10:", c
=====================================================

And here's the output I get:

=====================================================
Before: C<37>
Add 10: None
=====================================================


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452252&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 00:06:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 16:06:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-452230 ] future division isn't propagated
Message-ID: <E15Xsh8-0002yf-00@usw-sf-web3.sourceforge.net>

Bugs item #452230, was opened at 2001-08-17 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: future division isn't propagated

Initial Comment:
When I first saw this, I thought it was a bug in the 
PEP 264 patch.  Then I thought it was because 
PyEval_MergeCompilerFlags hadn't been taught about 
CO_FUTURE_DIVISION.  But I just repaired (and checked 
in) the latter, so that's not it either (although that 
was a cause of related bugs).  If it's not more 
obvious to you than it is to me, assign it back to me 
and I'll get back to it later.

C:\Code\python\PCbuild>python
Python 2.2a1+ (#21, Aug 17 2001, 17:16:14) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> from __future__ import division
>>> 1/2
0.5
>>> eval("1/2")
0
>>>

The same thing happens if you run it from file:

from __future__ import division
print 1/2
print eval("1/2")

That prints "0.5" and "0".


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:06

Message:
Logged In: YES 
user_id=31435

Fixed and Closed (Guido's observation was spot on):

Lib/test/test_binop.py; new revision: 1.2
Python/bltinmodule.c; new revision: 2.229


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 14:41

Message:
Logged In: YES 
user_id=6380

Looks to me like builtin_eval() doesn't do the necessary
dance to pass in any compiler flags -- it uses the old API,
PyRun_String().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452230&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 00:20:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 16:20:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15XsuM-000392-00@usw-sf-web3.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 02:27:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 18:27:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-452252 ] __iadd__ sets object to None
Message-ID: <E15XutE-0006JF-00@usw-sf-web1.sourceforge.net>

Bugs item #452252, was opened at 2001-08-17 15:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452252&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: John Shipman (shipman)
Assigned to: Nobody/Anonymous (nobody)
Summary: __iadd__ sets object to None

Initial Comment:
Here's my version info:

ActivePython 2.1, build 211 (ActiveState)
based on Python 2.1 (#1, Jun 15 2001, 02:52:41) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2

If I overload `+=' in a class using an __iadd__
method, the object is replaced by None.  Here's
a script that demonstrates the problem:

=====================================================
#!/usr/local/bin/python
#--
# iadd:  See if __iadd__ actually works
#--

class C:
    def __init__ ( self, value ):
        self.value  =  value

    def __str__ ( self ):
        return "C<%s>" % self.value

    def __repr__ ( self ):
        return str(self)

    def __iadd__ ( self, x ):
        self.value  =  self.value + x

# - - - - -   m a i n   - - - - -

c = C(37)
print "Before:", c

c += 10
print "Add 10:", c
=====================================================

And here's the output I get:

=====================================================
Before: C<37>
Add 10: None
=====================================================


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 18:27

Message:
Logged In: YES 
user_id=6380

You must return None.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452252&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 02:38:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 17 Aug 2001 18:38:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15Xv4P-0004lQ-00@usw-sf-web3.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Guido van Rossum (gvanrossum)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-17 18:38

Message:
Logged In: YES 
user_id=44345

I've backed out the check for a maximum in my copy.
All it has now is the _note change.  I'll check that
in anytime you say so and resubmit the other change with
the optional constructor argument Tim mentioned and a
doc update.  Tim, do you have a preferred name, say,
"strict_maximum"?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 10:30:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 02:30:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-411508 ] httplib does not support user/pass
Message-ID: <E15Y2RP-0001ga-00@usw-sf-web3.sourceforge.net>

Bugs item #411508, was opened at 2001-03-26 18:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411508&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: JAmes Atwill (idcmp)
Assigned to: Greg Stein (gstein)
Summary: httplib does not support user/pass 

Initial Comment:
_set_hostport looks for the first ':' it finds and
takes the text after it as the port.  This doesn't work
if the user supplies a username/password combination.

For example:

  
http://user:pass@hostname.org:8080/directory/filename.html

There is no mechanism for easily including the
username/password unless the calling object mangles the
headers itself.  This means every project that uses
httplib needs to implement authentication itself, over
and over and over again.


----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2001-08-18 02:30

Message:
Logged In: YES 
user_id=6501

Marking this as Closed/Rejected again.

To repeat: the HTTPConnection is the wrong layer for 
authentication support. Callers should not be passing 
user/pass information as part of the host/port.

Further, it is impossible for the HTTPConnection to support 
user/pass. It is unaware of the request that was made. If a 
401 (Authorization Required) is returned by the server, 
then the connection object has no way to resubmit the 
request (with the appropriate credentials).

Authentication will be handled elsewhere, which will be 
part of Python 2.2. (module name and PEP # is TBD)

----------------------------------------------------------------------

Comment By: JAmes Atwill (idcmp)
Date: 2001-04-07 11:11

Message:
Logged In: YES 
user_id=2329

Then whatever method that parses the URL is not properly
stripping away the user:pass@ part from the URL before
passing it to _set_hostport.

Seperating authentication in this mechanism (meaning
everyone has to do the same thing) makes it impossible to do
authentication through things like xmlrpclib without a lot
of black voodoo magic as the protocol is purposely hidden
from you.

The added complexity cancels out the bonus of having an
xmlrpclib.

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-04-07 07:07

Message:
Logged In: YES 
user_id=6501

1) _set_hostport takes a host/port, NOT a URL.

2) Authentication is for a higher level than the 
HTTPConnection object. The latter is simply to enable 
HTTP/1.1 functionality. Most features can layer on top of 
that as a subclass, or as a class which uses/delegates to a 
connection.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411508&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 11:22:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 03:22:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E15Y3F7-0002GU-00@usw-sf-web3.sourceforge.net>

Bugs item #405939, was opened at 2001-03-04 21:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405939&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Ernie Sasaki (esasaki)
Assigned to: Greg Stein (gstein)
Summary: HTTPConnection Host hdr wrong w/ proxy

Initial Comment:
The HTTPConnection class' putrequest() method is 
incorrect if self._http_vsn == 11 and a proxy is in 
use.

Currently the following is done in httplib.py revision 
1.33:

if self.port == HTTP_PORT:
    self.putheader('Host', self.host)
else:
    self.putheader('Host', "%s:%s" % (self.host, 
self.port))

However if a proxy is in use, self.host is the proxy 
address, and url contains the "realhost" which should 
be in the Host header. (urllib does the right thing 
here but it uses the HTTP class and not 
HTTPConnection. It doesn't see this problem because 
then HTTP/1.0 is used and no Host header is sent 
automatically.)

Instead the following is correct:

match = httpRE.search(url)
if match:
    self.putheader('Host', match.group(1))
else:
    if self.port == HTTP_PORT:
        self.putheader('Host', self.host)
    else:
	self.putheader('Host', "%s:%s" % (self.host, 
self.port))

where:

httpRE = re.compile(r'(?i)http://([^/]+)')


----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2001-08-18 03:22

Message:
Logged In: YES 
user_id=6501

This looks good. Note that RFC 2616 says the Host header 
should reflect the host of the "original URL" (which I 
presume means without any proxy consideration).

I plan to optimize the provided code a bit, but will 
otherwise follow that pattern. Look for the result in 2.2a3 
(will probably miss 2.2a2).

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-03-05 15:44

Message:
Logged In: YES 
user_id=21627

1 and 2 are probably good reasons why httplib should follow.
3 is no option, since RFC 2616 states that a client MUST
send a Host header in a 1.1 request, even though a server
MUST ignore it if an absolute URI is present; otherwise I'd
agree that it would be best not to send any at all.

As for 4, I agree that the proxy can change the Request-URI.
However, to conform to http 1.1, I think it also needs to
update the Host: header accordingly.

I'd like to get some report on actual problems caused by
this bug. If so, what is the specific proxy software being
used, etc.

On user/password issue: So far, httplib does not deal with
the request URI at all. The issue is how to process an
absoluteURI that contains a userinfo. It would be clearly
wrong to copy the userinfo into the Host: header, as your
code would do. What is not clear to me is whether RFC 2616
allows userinfo to be present in a Request-URI.

----------------------------------------------------------------------

Comment By: Ernie Sasaki (esasaki)
Date: 2001-03-05 12:31

Message:
Logged In: YES 
user_id=139439

Well, my not very good answers are (notwithstanding your 
quote):

1). This is what Netscape 4.7 does.

2). This is what urllib's open_http does.

3). I rather you didn't send a Host header at all rather 
than a wrong one.  It just makes no sense to me to give the 
origin server a Host header that relates to the proxy's 
address. How would the virtual host mechanism (mentioned in 
the section you quote) ever work thru a proxy then?? You 
need the concept of a host different from what is specified 
in the Request-URI.

4). I speculate (with only secondhand evidence) that a 
proxy can change the absoluteURI to an absolute path when 
passing it on to the origin server. In that case, the Host 
header would indeed determine the host.

As far as the patch being incomplete: In no part of httplib 
does any special handling of an embedded user/password 
appear. It is assumed that you'll take care of sending the 
Authorization header yourself.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-03-05 00:39

Message:
Logged In: YES 
user_id=21627

Why is that a bug? RFC 2616, section 5.2, states

# If Request-URI is an absoluteURI, the host is part of the 
# Request-URI. Any Host header field value in the request 
# MUST be ignored.

So in the presence of an absolute URI, the Host: field does
not matter. It is certainly nicer to fill in the right Host:
field, but I'd like to understand the problem before
applying a fix. Your patch is incomplete, IMO: it does not
deal with the user/password part in the URL.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=405939&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 18:44:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 10:44:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-443600 ] overload of the slicing operator
Message-ID: <E15YA99-0001JM-00@usw-sf-web2.sourceforge.net>

Bugs item #443600, was opened at 2001-07-22 13:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Markus Daniel (spacy73)
Assigned to: Guido van Rossum (gvanrossum)
Summary: overload of the slicing operator

Initial Comment:
It's impossible to overload the slicing operator
to take two float-values.


PythonWin 2.1 (#15, Apr 23 2001, 18:00:35) [MSC 32 bit 
(Intel)] on win32.
>>> class a:
... 	def __getitem__(self, index):
... 		print repr(index)
... 
>>> 
>>> aa=a()
>>> 
>>> aa[1.5]
1.5
>>> 
>>> aa[1.5:2.5]
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: slice indices must be integers
>>>
>>> aa[1.5:2.5:3.5]
slice(1.5, 2.5, 3.5)
>>> 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 10:44

Message:
Logged In: YES 
user_id=6380

Turns out it wasn't so bad. :-)

Fixed in CVS, ceval.c:2.269.  This will be in 2.2a2.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 19:41

Message:
Logged In: YES 
user_id=6380

It's complicated because the internal APIs are all busted, and "fixing" them might cause
backwards compatibilities, i.e. break existing 3rd party extensions.

This has been broken for a long time.  I agree that it ought to be fixed,
but not at the cost of backwards incompatibility, and I don't give it high priority.

Maybe we can define completely new C APIs that do this right
and then define the old ones just as b/w compatibility APIs.

But part of it is that we can't change the specs for calls into extension types,
because we don't know that the types would support the new rules.
This can be fixed by asking the types to specify some flag bit in their tp_flags field,
but it all gets very complicated -- for little gain, IMO.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-06 13:57

Message:
Logged In: YES 
user_id=31392

No idea what the right thing to do here.  BDFL?

You can do aa[slice(1.5, 2.5)], so I don't see why you
shouldn't be able to do aa[1.5:2.5].


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443600&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 18:55:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 10:55:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15YAJN-0003Qh-00@usw-sf-web1.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 10:55

Message:
Logged In: YES 
user_id=6380

Skip, go ahead and check in the logging change.

I must be insufficiently familiar with usage patterns of
semaphores to appreciate the motivation for the maximum
check. Offhand, a subclass seems a good idea.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-17 18:38

Message:
Logged In: YES 
user_id=44345

I've backed out the check for a maximum in my copy.
All it has now is the _note change.  I'll check that
in anytime you say so and resubmit the other change with
the optional constructor argument Tim mentioned and a
doc update.  Tim, do you have a preferred name, say,
"strict_maximum"?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 21:36:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 13:36:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15YCpN-0001F7-00@usw-sf-web3.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-18 13:36

Message:
Logged In: YES 
user_id=31435

Guido, in my experience semaphores are most often used when 
you have a fixed and known-in-advance number of a shared 
resource.  Like (say) 8 printers.  Then you init a 
semaphore to 8, and its current value is meant always to 
reflect the # of printers available.  Thus in the absence 
of printers popping into existence by magic, "0 <= 
current_value <= 8" is an invariant of correct usage.

OTOH, perhaps new printers may get installed over the life 
of a program run.  In that case the printer installer may 
well want to do a V without having done a P first, and so 
increase the maximum -- but then it would still be a logic 
bug if the program ever exceeded the new maximum.

BoundedSemaphore may be a good subclass name?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 10:55

Message:
Logged In: YES 
user_id=6380

Skip, go ahead and check in the logging change.

I must be insufficiently familiar with usage patterns of
semaphores to appreciate the motivation for the maximum
check. Offhand, a subclass seems a good idea.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-17 18:38

Message:
Logged In: YES 
user_id=44345

I've backed out the check for a maximum in my copy.
All it has now is the _note change.  I'll check that
in anytime you say so and resubmit the other change with
the optional constructor argument Tim mentioned and a
doc update.  Tim, do you have a preferred name, say,
"strict_maximum"?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 22:09:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 14:09:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15YDLt-0001dj-00@usw-sf-web3.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 14:09

Message:
Logged In: YES 
user_id=6380

I see. BoundedSemaphore is perfect. But there needs to be an
example in the docs that shows what it's good for.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-18 13:36

Message:
Logged In: YES 
user_id=31435

Guido, in my experience semaphores are most often used when 
you have a fixed and known-in-advance number of a shared 
resource.  Like (say) 8 printers.  Then you init a 
semaphore to 8, and its current value is meant always to 
reflect the # of printers available.  Thus in the absence 
of printers popping into existence by magic, "0 <= 
current_value <= 8" is an invariant of correct usage.

OTOH, perhaps new printers may get installed over the life 
of a program run.  In that case the printer installer may 
well want to do a V without having done a P first, and so 
increase the maximum -- but then it would still be a logic 
bug if the program ever exceeded the new maximum.

BoundedSemaphore may be a good subclass name?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 10:55

Message:
Logged In: YES 
user_id=6380

Skip, go ahead and check in the logging change.

I must be insufficiently familiar with usage patterns of
semaphores to appreciate the motivation for the maximum
check. Offhand, a subclass seems a good idea.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-17 18:38

Message:
Logged In: YES 
user_id=44345

I've backed out the check for a maximum in my copy.
All it has now is the _note change.  I'll check that
in anytime you say so and resubmit the other change with
the optional constructor argument Tim mentioned and a
doc update.  Tim, do you have a preferred name, say,
"strict_maximum"?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sat Aug 18 22:23:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 14:23:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-451547 ] pickle / cPickle can't load lambdas
Message-ID: <E15YDYs-0006Os-00@usw-sf-web1.sourceforge.net>

Bugs item #451547, was opened at 2001-08-16 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Gordon B. McMillan (gmcm)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle / cPickle can't load lambdas

Initial Comment:
pickle and cPickle will happily dump a lambda, but on 
load, both report:
SystemError: Failed to import class <lambda> from 
module __main__

Seen on Py 2.1 & 1.5.2

>>> f = lambda x: x in (1,2,3)
>>> o = cPickle.dumps(f)
>>> f2 = cPickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
SystemError: Failed to import class <lambda> from 
module __main__
>>> o = pickle.dumps(f)
>>> f2 = pickle.loads(o)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python21\lib\pickle.py", line 951, in loads
    return Unpickler(file).load()
  File "c:\python21\lib\pickle.py", line 567, in load
    dispatch[key](self)
  File "c:\python21\lib\pickle.py", line 780, in 
load_global
    klass = self.find_class(module, name)
  File "c:\python21\lib\pickle.py", line 790, in 
find_class
    raise SystemError, \
SystemError: Failed to import class <lambda> from 
module __main__



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 14:23

Message:
Logged In: YES 
user_id=6380

I applied Gordon's patch, so this can be closed now.


----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-17 14:45

Message:
Logged In: YES 
user_id=4923

Patch # 452239 is my attempt to patch cPickle.c to match 
Guido's patch to pickle.py.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 11:51

Message:
Logged In: YES 
user_id=6380

I figured it out.

In save_global(), I now try to import the module and then
extract the name from the module; this must give us the same
object. If it doesn't, raise PicklingError.

Checked in as pickle.py rev 1.50.  I can't close this yet
because cPickle needs
a similar patch.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:31

Message:
Logged In: YES 
user_id=6380

I guess what you're missing is that pickling a function
doesn't pickle the bytecode! It pickles the name instead. So
a reference to "foo.bar" is pickled as "foo.bar", and the
unpickler imports bar from foo.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2001-08-16 09:03

Message:
Logged In: YES 
user_id=4923

Hmm. In the (simplistic) case I was trying, I can't see any 
significant difference between the lambda and the 
equivalent function (names differ, and the func has 2 
appended & apparently unreachable bytecodes, but otherwise 
the func_* and func_code.co_* attributes match). So what am 
I missing?

Lowering priority - I can live without it easily enough.

But if lambda's won't load, they probably shouldn't dump.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 08:11

Message:
Logged In: YES 
user_id=6380

I think I'll have to close this with a won't fix, or "then
don't do that" resolution.

The problem is that whenever a function or class is pickled,
pickle must accept on blind faith that it can also be
unpickled. How would you check that this is indeed the case?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451547&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 01:45:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 17:45:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-452747 ] Unpickable dictionary subclasses
Message-ID: <E15YGic-0006KJ-00@usw-sf-web2.sourceforge.net>

Bugs item #452747, was opened at 2001-08-18 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Unpickable dictionary subclasses

Initial Comment:
Any class which extends either the dictionary or list 
types in Python 2.2a1 is both unpickable by both the 
pickle module and cPickle, and is uncopyable by the 
copy module.

Oh, and I'll use this opportunity to thank Guido and 
everyone who's ever worked on Python for making a 
programming language which is absolutely wonderful to 
program in. :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 05:28:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 21:28:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-443614 ] enhancement for threading._Semaphore
Message-ID: <E15YKBu-0003wd-00@usw-sf-web1.sourceforge.net>

Bugs item #443614, was opened at 2001-07-22 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: enhancement for threading._Semaphore

Initial Comment:
The threading._Semaphore class subclasses
threading._Verbose
but takes no advantage of this, never calling
self._note.  In
addition, it seems to me that most of the time it would
be
a bug if a semaphore is released more times than it is
acquired.  The attached patch adds to calls to
self._note
similar to those in threading._RLock adds a new
instance
variable, __initial_value, and adds an assert to
_Semaphore.release to compare the current value of the
semaphore with its initial value.

If it is felt that the semantic change to the
_Semaphore
class caused by the addition of the assert statement
would
break code, I recommend that  _Semaphore be subclassed
with the release method overridden to include the
assert
check.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-18 21:28

Message:
Logged In: YES 
user_id=44345

threading.py v 1.15 contains the logging change.  I will
submit a separate patch that adds a BoundedSemaphore class.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 14:09

Message:
Logged In: YES 
user_id=6380

I see. BoundedSemaphore is perfect. But there needs to be an
example in the docs that shows what it's good for.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-18 13:36

Message:
Logged In: YES 
user_id=31435

Guido, in my experience semaphores are most often used when 
you have a fixed and known-in-advance number of a shared 
resource.  Like (say) 8 printers.  Then you init a 
semaphore to 8, and its current value is meant always to 
reflect the # of printers available.  Thus in the absence 
of printers popping into existence by magic, "0 <= 
current_value <= 8" is an invariant of correct usage.

OTOH, perhaps new printers may get installed over the life 
of a program run.  In that case the printer installer may 
well want to do a V without having done a P first, and so 
increase the maximum -- but then it would still be a logic 
bug if the program ever exceeded the new maximum.

BoundedSemaphore may be a good subclass name?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 10:55

Message:
Logged In: YES 
user_id=6380

Skip, go ahead and check in the logging change.

I must be insufficiently familiar with usage patterns of
semaphores to appreciate the motivation for the maximum
check. Offhand, a subclass seems a good idea.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-17 18:38

Message:
Logged In: YES 
user_id=44345

I've backed out the check for a maximum in my copy.
All it has now is the _note change.  I'll check that
in anytime you say so and resubmit the other change with
the optional constructor argument Tim mentioned and a
doc update.  Tim, do you have a preferred name, say,
"strict_maximum"?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-17 16:20

Message:
Logged In: YES 
user_id=31435

Guido, the comment in threading._Semaphore makes clear that 
you deliberately didn't want a maximum, so a question for 
you is whether you think differently now.  Since my old 
Sempahore class did have a maximum, it's clear what I 
thought <wink>.

In any case it's hard to approve of changing semantics 
now.  Skip should check in the logging (that can't be 
controversial -- I hope), and split the semantic change 
into a different patch.

A new optional argument on the constructor saying whether 
or not you want a maximum would be backward compatible.  
Both kinds of semaphores can be useful, but I'm not sure 
*so* useful that it justifies two distinct classes (even if 
one is a subclass of the other).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 09:57

Message:
Logged In: YES 
user_id=6380

Looks good to me.

Tim, do you approve of this?  If so, assign to Skip for
checkin.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443614&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 06:47:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 22:47:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-452832 ] object.__new__ too dangerous
Message-ID: <E15YLRB-00017e-00@usw-sf-web2.sourceforge.net>

Bugs item #452832, was opened at 2001-08-18 22:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__new__ too dangerous

Initial Comment:
object.__new__(type) or object.__new__(dictionary)
creates insufficiently initialized objects. Not clear
what to do about that -- this is supposed to be called
only from a subclass constructor, but how do I verify
that?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 07:01:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 23:01:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15YLeo-0005E8-00@usw-sf-web1.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 07:07:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 23:07:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-452832 ] object.__new__ too dangerous
Message-ID: <E15YLkL-0005Ij-00@usw-sf-web1.sourceforge.net>

Bugs item #452832, was opened at 2001-08-18 22:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__new__ too dangerous

Initial Comment:
object.__new__(type) or object.__new__(dictionary)
creates insufficiently initialized objects. Not clear
what to do about that -- this is supposed to be called
only from a subclass constructor, but how do I verify
that?


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-18 23:07

Message:
Logged In: YES 
user_id=44345

(Just thinking out loud before I trundle off to bed...)

Can you call (the equivalent of) sys._getframe, then from
there work your way back to a method object and check that
the method is named __init__ and that its first argument is
an instance of a subclass of object?  Sounds messy.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 07:35:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 23:35:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-452747 ] New-style classes can't be pickled
Message-ID: <E15YMBN-0001ce-00@usw-sf-web2.sourceforge.net>

Bugs item #452747, was opened at 2001-08-18 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: New-style classes can't be pickled

Initial Comment:
Any class which extends either the dictionary or list 
types in Python 2.2a1 is both unpickable by both the 
pickle module and cPickle, and is uncopyable by the 
copy module.

Oh, and I'll use this opportunity to thank Guido and 
everyone who's ever worked on Python for making a 
programming language which is absolutely wonderful to 
program in. :)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 23:35

Message:
Logged In: YES 
user_id=6380

Thanks <blush> :-)

Regarding your bug, it's more general than what you describe
even: any class derived from object except certain built-in
classes are unpicklable.

I have to think about this --  part of my brain says that
this is how it should be, and that you can register your
constructor with copy_reg to make your type picklable, and
another part of my brain says that it should be supported
one way or another.

Changed the subject to reflect the problem better.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452747&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 07:58:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 18 Aug 2001 23:58:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-452832 ] object.__new__ too dangerous
Message-ID: <E15YMXa-0008Tw-00@usw-sf-web3.sourceforge.net>

Bugs item #452832, was opened at 2001-08-18 22:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: object.__new__ too dangerous

Initial Comment:
object.__new__(type) or object.__new__(dictionary)
creates insufficiently initialized objects. Not clear
what to do about that -- this is supposed to be called
only from a subclass constructor, but how do I verify
that?


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-18 23:58

Message:
Logged In: YES 
user_id=6380

Fortunately, I figured a better check. Read the code I added
to tp_new_wrapper().

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-18 23:07

Message:
Logged In: YES 
user_id=44345

(Just thinking out loud before I trundle off to bed...)

Can you call (the equivalent of) sys._getframe, then from
there work your way back to a method object and check that
the method is named __init__ and that its first argument is
an instance of a subclass of object?  Sounds messy.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452832&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 17:34:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 09:34:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-452973 ] Tcl event loop callback woes
Message-ID: <E15YVWy-0007ap-00@usw-sf-web3.sourceforge.net>

Bugs item #452973, was opened at 2001-08-19 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Egnor (egnor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tcl event loop callback woes

Initial Comment:
I have C code which handles I/O and needs an event
dispatcher.  It is running in the context of a Python
GUI application, and uses the Tcl event loop, using
Tcl_CreateFileHandler and friends.  The C code gets
callbacks from the Tcl event loop fine, but when it
attempts to call into the Python application from one
of these callbacks, things go wrong.

- Tkinter has released the GIL and hidden the current
thread state.  I can work around this by re-acquiring
the GIL from the callback and creating a new thread state.

- When the callback is invoked, Tkinter's tcl_lock is
held.  If the Python code invoked from the callback
ultimately calls some other Tkinter function, the
tcl_lock is still held, and deadlock results.  The only
way to work around this is to use a single-threaded
Python build.

- If the Python code returns an error, there's no way
to stop the event loop to report the error up. 
Tkinter's error-reporting mechanisms are inaccessible.

In general, Tkinter has a lot of infrastructure for
managing callbacks from the Tcl event loop.  If a third
party C library wants to use the same event loop, that
infrastructure is unavailable, and it is very difficult
to work with Python.

Unfortunately, short of using threads (which have their
own problems), there's no other alternative for an
external C library to do I/O without blocking the GUI.
 I've seen several problem reports from people trying
to do exactly this, though they almost never figure out
all of what's going on, and nobody else ever has any
good advice to offer.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 22:32:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 14:32:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15YaBC-0002z8-00@usw-sf-web1.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 23:59:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 15:59:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-453111 ] C API Reference bugs
Message-ID: <E15YbXk-0003vO-00@usw-sf-web3.sourceforge.net>

Bugs item #453111, was opened at 2001-08-19 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453111&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: C API Reference bugs

Initial Comment:
1. PyTuple_GET_SIZE is not documented.
2. Paragraph about PyDict_Copy contains odd sentence:
"Empties an existing dictionary of all key-value pairs".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453111&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 23:47:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 15:47:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-453099 ] select in asyncore not defensive
Message-ID: <E15YbLh-0005Ry-00@usw-sf-web2.sourceforge.net>

Bugs item #453099, was opened at 2001-08-19 15:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: select in asyncore not defensive

Initial Comment:
The poll method in asyncore.py does not wrap the
select.select call on line 86 in a try/except block to
test for EINTR/EWOULDBLOCK and then try the select call
again. This was brought to my attention during the
perusal of the Zope-dev list. Seems like the person who
originally reported the symptom did not open a bug so I
thought I would.

Platform: SunOS 5.8/Sparc
Python version: 2.1.1
Zope version: 2.4.0

Thanks.

Here is the mail from a person on the Zope-dev mailing
list:

I am moving this thread over from the zope list in the
hope that someone here may have more insight into the
nature of this problem, and perhaps how to go about 
better diagnosing/fixing the problem.

To sum up:  Under apparently random circumstances and 
rather mild amounts of traffic, Zope is crashing and
printing the Traceback below to the console. This is
Zope-2.4.0, Python-2.1.1 on SunOS 5.8/Sparc.

Traceback (most recent call last):
  File "/u01/zope/Zope-2.4.0-src/z2.py", line 774, in ?
   asyncore.loop()
  File "/u01/zope//lib/python2.1/asyncore.py", line
194, in loop
    poll_fun (timeout, map)
  File "/u01/zope//lib/python2.1/asyncore.py", line 86,
in poll
    r,w,e = select.select (r,w,e, timeout)
  select.error: (4, 'Interrupted system call')



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-19 15:47

Message:
Logged In: NO 

Sorry, the user's email is jziniti@speakeasy.org.

EWOULDBLOCK was reported by that user for a different method
in asyncore called accept though it seems that EWOULDBLOCK
is being handled correctly in accept. It seems that the user
did add the try/except block around the select call on line
86 which resulted in later call to accept() throwing
EWOULDBLOCK. The trace is as follows:

system.error 4((4, 'Interrupted system call'))
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <__repr__ (self) failed for
object at dee7bc (addr='/tmp/zope.soc')>
(exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/FCGIServer.py|handle_accept|697])
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <__repr__ (self) failed for
object at dec4bc
(addr='/u01/zope/Zope-2.4.0-src/var/pcgi.soc')>
(exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/PCGIServer.py|handle_accept|380])
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <FTPServer listening :8021 at
debcec> (exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/FTPServer.py|handle_accept|694])
------
2001-08-16T13:16:01 PROBLEM(100) ZServer warning: server
accept() threw EWOULDBLOCK
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <select-trigger (pipe) at 248024>
(exceptions.OSError:[Errno 11] Resource temporarily
unavailable [/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|389]
[/u01/zope/Zope-2.4.0-src/ZServer/medusa/thread/select_trigger.py|handle_read|77]
[/u01/zope/lib/python2.1/asyncore.py|recv|341]
[/u01/zope/lib/python2.1/asyncore.py|recv|523])


Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 21:41:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 13:41:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-453059 ] Nasty bug in HTMLParser.py
Message-ID: <E15YZNv-0003yQ-00@usw-sf-web2.sourceforge.net>

Bugs item #453059, was opened at 2001-08-19 13:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nasty bug in HTMLParser.py

Initial Comment:
If you feed the following string to an HTMLParser
parser, you get _very_ weird results:

'one & two & three &three; &blagh ;'

What I would expect would be:

 - call to handle_data(data='one & two & three ')

 - call to handle_entityref(name='three')

 - call to handle_data(data=' &blagh ;')

What you actually get is:

 - call to handle_data(data='one ')

 - call to handle_data(data='one ')

...which is very wrong :-S

Now, I'm not sure of the validity of the associated
HTML*, but if it's invalid, I would have thought
exceptions would be thrown rather than the above result.

In any case, I have a module that demonstrates this
problem which is available from:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/squishdot/stripogram/

It has a testsuite that runs with Zope's testrunner.py
and I just added a test to demonstrate this problem.

Any help would be very much appreciated...

Chris

* The string 'one & two & three &three; &blagh ;'
displays exactly as is in Mozilla, IE and Netscape, of
course that doesn't mean the W3C will like it ;-) I'd
prefer to go with the majority rather than being
'right' on this one.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470


From noreply@sourceforge.net  Sun Aug 19 23:24:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 15:24:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-453099 ] select in asyncore not defensive
Message-ID: <E15Yazj-0005BK-00@usw-sf-web2.sourceforge.net>

Bugs item #453099, was opened at 2001-08-19 15:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: select in asyncore not defensive

Initial Comment:
The poll method in asyncore.py does not wrap the
select.select call on line 86 in a try/except block to
test for EINTR/EWOULDBLOCK and then try the select call
again. This was brought to my attention during the
perusal of the Zope-dev list. Seems like the person who
originally reported the symptom did not open a bug so I
thought I would.

Platform: SunOS 5.8/Sparc
Python version: 2.1.1
Zope version: 2.4.0

Thanks.

Here is the mail from a person on the Zope-dev mailing
list:

I am moving this thread over from the zope list in the
hope that someone here may have more insight into the
nature of this problem, and perhaps how to go about 
better diagnosing/fixing the problem.

To sum up:  Under apparently random circumstances and 
rather mild amounts of traffic, Zope is crashing and
printing the Traceback below to the console. This is
Zope-2.4.0, Python-2.1.1 on SunOS 5.8/Sparc.

Traceback (most recent call last):
  File "/u01/zope/Zope-2.4.0-src/z2.py", line 774, in ?
   asyncore.loop()
  File "/u01/zope//lib/python2.1/asyncore.py", line
194, in loop
    poll_fun (timeout, map)
  File "/u01/zope//lib/python2.1/asyncore.py", line 86,
in poll
    r,w,e = select.select (r,w,e, timeout)
  select.error: (4, 'Interrupted system call')



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 01:47:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 17:47:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15YdDy-0005Dq-00@usw-sf-web3.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 03:34:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 19:34:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15Yety-0007z4-00@usw-sf-web2.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Tim Peters (tim_one)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-19 19:34

Message:
Logged In: YES 
user_id=31435

Thanks, Skip!  I assigned this back to me (no time this 
instant; will get back to it later tonight).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 06:24:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 22:24:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15YhXe-0008Rx-00@usw-sf-web3.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-19 22:24

Message:
Logged In: YES 
user_id=31435

Noting that C99 *requires* fpos_t values to hold all the 
info in an mbstate_t, in addition to stream position info.  
So we have to expect others to follow glibc in this, and 
eventually everyone.  fpos_t cannot resolve to an array 
type, but anything else is fair (in particular it need not 
map to an integral type -- and probably won't anymore).

We have to give up belief that fpos_t is a number, because 
it's not.  We can believe that ftell returns a number, 
because it does <wink> -- but ftell isn't suitable for 
large file support.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 06:13

Message:
Logged In: YES 
user_id=21627

This started in glibc 2.2, I believe, so it would appear in
Redhat 7, SuSE 7, etc.
To see the problem, you have to ./configure with
CFLAGS="-D_FILE_OFFSET_BITS=64" OPT="-O2 $(CFLAGS)"; see
pyconfig.h.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:55

Message:
Logged In: YES 
user_id=6380

Whoa.  Interesting. Which Linux version is this?

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 06:35:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 19 Aug 2001 22:35:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-453208 ] 64-bit zip problems
Message-ID: <E15Yhj1-0001U8-00@usw-sf-web1.sourceforge.net>

Bugs item #453208, was opened at 2001-08-19 22:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453208&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: 64-bit zip problems

Initial Comment:
This is from c.l.py.  There's not enough info (e.g., 
which OS, which compiler, which Python), but in case 
anyone is wondering what to do with their IA64 box ...

From: John Wiegley
Sent: Thursday, August 16, 2001 6:14 PM
To: python-list@python.org
Subject: Problem with zipfile between 32-bit and 64-bit

Using the test script below, run it once on an Intel
32-bit platform.  This produces test.zip, which
extracts hello.py.

Then take the test script and test.zip to an ia64
platform, and run it again.  The file it extracts has
0 bytes.

I've run into other problems between ia32 and ia64,
such as bad checksums, and was wondering if anyone
knew anything about this?

Thanks,
  John Wiegley <johnw@gnu.org>

----[ file: ziptest.py ]-------------------------------
---------------
import os
import zipfile
import string

if not os.path.exists('test.zip'):
    zip = zipfile.ZipFile('test.zip', 'w')
    zip.write('ziptest.py', 'hello.py')
    zip.close()

zip = zipfile.ZipFile('test.zip', 'r')
if hasattr(zip, 'namelist'):
    files = zip.namelist()
else:
    files = zip.listdir()

for file in files:
    file = apply(os.path.join, string.split
(file, '\'))

    data = open(file, 'wb')
    print "unarchiving", file
    data.write(zip.read(file))
    data.close()


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453208&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 08:35:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 00:35:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15Yjb4-0003Fg-00@usw-sf-web1.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Tim Peters (tim_one)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:35

Message:
Logged In: YES 
user_id=31435

Deleted the old patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 19:34

Message:
Logged In: YES 
user_id=31435

Thanks, Skip!  I assigned this back to me (no time this 
instant; will get back to it later tonight).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 08:46:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 00:46:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15YjlI-0001iy-00@usw-sf-web3.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:46

Message:
Logged In: YES 
user_id=31435

Cool!  Accepted for the code changes, and back to Skip for 
checkin.  Reassign to Fred for doc changes, if you want.

I would like to see the docs clarified on one point.  When 
it says

"""
ensures that its current value never exceeds its initial 
value
"""

I have no idea what "ensures" means.  Would be better to 
tell the plain truth, i.e. that the release() method 
specifically raises ValueError specifically in such cases; 
a reader could easily imagine, e.g., that instead a 
BoundedSemaphore "ensures" this condition by blocking until 
someone else does an acquire (which would be symmetric with 
acquire() blocking at *its* limit until someone does a 
release(), so isn't an implausible guess).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:35

Message:
Logged In: YES 
user_id=31435

Deleted the old patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 19:34

Message:
Logged In: YES 
user_id=31435

Thanks, Skip!  I assigned this back to me (no time this 
instant; will get back to it later tonight).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 09:16:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 01:16:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-453059 ] Nasty bug in HTMLParser.py
Message-ID: <E15YkEe-0003Z9-00@usw-sf-web2.sourceforge.net>

Bugs item #453059, was opened at 2001-08-19 13:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nasty bug in HTMLParser.py

Initial Comment:
If you feed the following string to an HTMLParser
parser, you get _very_ weird results:

'one & two & three &three; &blagh ;'

What I would expect would be:

 - call to handle_data(data='one & two & three ')

 - call to handle_entityref(name='three')

 - call to handle_data(data=' &blagh ;')

What you actually get is:

 - call to handle_data(data='one ')

 - call to handle_data(data='one ')

...which is very wrong :-S

Now, I'm not sure of the validity of the associated
HTML*, but if it's invalid, I would have thought
exceptions would be thrown rather than the above result.

In any case, I have a module that demonstrates this
problem which is available from:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/squishdot/stripogram/

It has a testsuite that runs with Zope's testrunner.py
and I just added a test to demonstrate this problem.

Any help would be very much appreciated...

Chris

* The string 'one & two & three &three; &blagh ;'
displays exactly as is in Mozilla, IE and Netscape, of
course that doesn't mean the W3C will like it ;-) I'd
prefer to go with the majority rather than being
'right' on this one.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 10:26:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 02:26:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-453059 ] Nasty bug in HTMLParser.py
Message-ID: <E15YlKE-0004ui-00@usw-sf-web1.sourceforge.net>

Bugs item #453059, was opened at 2001-08-19 13:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nasty bug in HTMLParser.py

Initial Comment:
If you feed the following string to an HTMLParser
parser, you get _very_ weird results:

'one & two & three &three; &blagh ;'

What I would expect would be:

 - call to handle_data(data='one & two & three ')

 - call to handle_entityref(name='three')

 - call to handle_data(data=' &blagh ;')

What you actually get is:

 - call to handle_data(data='one ')

 - call to handle_data(data='one ')

...which is very wrong :-S

Now, I'm not sure of the validity of the associated
HTML*, but if it's invalid, I would have thought
exceptions would be thrown rather than the above result.

In any case, I have a module that demonstrates this
problem which is available from:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/squishdot/stripogram/

It has a testsuite that runs with Zope's testrunner.py
and I just added a test to demonstrate this problem.

Any help would be very much appreciated...

Chris

* The string 'one & two & three &three; &blagh ;'
displays exactly as is in Mozilla, IE and Netscape, of
course that doesn't mean the W3C will like it ;-) I'd
prefer to go with the majority rather than being
'right' on this one.




----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2001-08-20 02:26

Message:
Logged In: YES 
user_id=24723

Here's the patch to fix it:

28,29c28,29
< entityref =
re.compile('&([a-zA-Z][-.a-zA-Z0-9]*)[^a-zA-Z0-9]')
< charref =
re.compile('&#(?:[0-9]+|[xX][0-9a-fA-F]+)[^0-9a-fA-F]')
---
> entityref = re.compile('&([a-zA-Z][-.a-zA-Z0-9]*);')
> charref = re.compile('&#(?:[0-9]+|[xX][0-9a-fA-F]+);')
213,214d212
<                     if rawdata[k-1] != ';':
<                         k = k-1
222,223d219
<                     if rawdata[k-1] != ';':
<                         k = k-1


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 14:21:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 06:21:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15Yozi-0008US-00@usw-sf-web1.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 06:21

Message:
Logged In: YES 
user_id=6380

OK, so we need to add separate getpos() and setpos() methods
that return an opaque wrapper for an fpos_t. That sounds
like serious work, plus it will require changing Python apps
that use seek and tell.

So I think we shold *also* continue to search for a way to
use a 64-bit seek offset for Python's seek() and tell()
methods -- I'm presuming this is hidden *somewhere* in the
fpos_t still, since the underlying OS certainly uses
lseek64(). If there's no way to extract it out of the
fpos_t, I propose to call lseek64() directly (after using a
fflush()) on the file descriptor.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 22:24

Message:
Logged In: YES 
user_id=31435

Noting that C99 *requires* fpos_t values to hold all the 
info in an mbstate_t, in addition to stream position info.  
So we have to expect others to follow glibc in this, and 
eventually everyone.  fpos_t cannot resolve to an array 
type, but anything else is fair (in particular it need not 
map to an integral type -- and probably won't anymore).

We have to give up belief that fpos_t is a number, because 
it's not.  We can believe that ftell returns a number, 
because it does <wink> -- but ftell isn't suitable for 
large file support.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 06:13

Message:
Logged In: YES 
user_id=21627

This started in glibc 2.2, I believe, so it would appear in
Redhat 7, SuSE 7, etc.
To see the problem, you have to ./configure with
CFLAGS="-D_FILE_OFFSET_BITS=64" OPT="-O2 $(CFLAGS)"; see
pyconfig.h.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:55

Message:
Logged In: YES 
user_id=6380

Whoa.  Interesting. Which Linux version is this?

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 14:50:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 06:50:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15YpS7-0008CV-00@usw-sf-web2.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 06:50

Message:
Logged In: YES 
user_id=44345

Thanks.  I made a change to the docs that should better
reflect how BoundedSemaphore objects behave in the face
of errors, and am assigning to Fred for doc review (new
class and a simple example). I uploaded a new version of
threading.diff (and deleted the old one this time).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:46

Message:
Logged In: YES 
user_id=31435

Cool!  Accepted for the code changes, and back to Skip for 
checkin.  Reassign to Fred for doc changes, if you want.

I would like to see the docs clarified on one point.  When 
it says

"""
ensures that its current value never exceeds its initial 
value
"""

I have no idea what "ensures" means.  Would be better to 
tell the plain truth, i.e. that the release() method 
specifically raises ValueError specifically in such cases; 
a reader could easily imagine, e.g., that instead a 
BoundedSemaphore "ensures" this condition by blocking until 
someone else does an acquire (which would be symmetric with 
acquire() blocking at *its* limit until someone does a 
release(), so isn't an implausible guess).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:35

Message:
Logged In: YES 
user_id=31435

Deleted the old patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 19:34

Message:
Logged In: YES 
user_id=31435

Thanks, Skip!  I assigned this back to me (no time this 
instant; will get back to it later tonight).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 17:46:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 09:46:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-420851 ] Missing docs for iteration support.
Message-ID: <E15YsBv-0002UR-00@usw-sf-web2.sourceforge.net>

Bugs item #420851, was opened at 2001-05-02 13:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing docs for iteration support.

Initial Comment:
Documentation is needed for the iteration support.  At this time, the following things are missing docs:

- iter() function
- {}.iteritems(), .iterkeys(), .itervalues()
- tp_iter/tp_iternext
- __iter__() (ref. manual -- "Object Customization")

If you can think of other aspects of this that I've missed, please note them as comments on this bug report so I can address these (or at least keep track of these) in a single place.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 09:46

Message:
Logged In: YES 
user_id=12800

Setting to priority 6 so that it won't hold up the 2.2a2
release.  Although it would be good to have these docs,
remember that priorities >= 7 must be fixed before the
release can happen.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-25 06:52

Message:
Logged In: YES 
user_id=3066

Docs for {}.iteritems(), {}.iterkeys(), and {}.itervalues()
checked in as Doc/lib/libstdtypes.tex revision 1.59.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 17:56:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 09:56:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-453111 ] C API Reference bugs
Message-ID: <E15YsMD-0002eO-00@usw-sf-web2.sourceforge.net>

Bugs item #453111, was opened at 2001-08-19 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453111&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kirill Simonov (kirill_simonov)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: C API Reference bugs

Initial Comment:
1. PyTuple_GET_SIZE is not documented.
2. Paragraph about PyDict_Copy contains odd sentence:
"Empties an existing dictionary of all key-value pairs".

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-20 09:56

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/api/api.tex revision 1.141.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453111&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 17:57:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 09:57:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-453099 ] select in asyncore not defensive
Message-ID: <E15YsMu-0002fI-00@usw-sf-web2.sourceforge.net>

Bugs item #453099, was opened at 2001-08-19 15:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: select in asyncore not defensive

Initial Comment:
The poll method in asyncore.py does not wrap the
select.select call on line 86 in a try/except block to
test for EINTR/EWOULDBLOCK and then try the select call
again. This was brought to my attention during the
perusal of the Zope-dev list. Seems like the person who
originally reported the symptom did not open a bug so I
thought I would.

Platform: SunOS 5.8/Sparc
Python version: 2.1.1
Zope version: 2.4.0

Thanks.

Here is the mail from a person on the Zope-dev mailing
list:

I am moving this thread over from the zope list in the
hope that someone here may have more insight into the
nature of this problem, and perhaps how to go about 
better diagnosing/fixing the problem.

To sum up:  Under apparently random circumstances and 
rather mild amounts of traffic, Zope is crashing and
printing the Traceback below to the console. This is
Zope-2.4.0, Python-2.1.1 on SunOS 5.8/Sparc.

Traceback (most recent call last):
  File "/u01/zope/Zope-2.4.0-src/z2.py", line 774, in ?
   asyncore.loop()
  File "/u01/zope//lib/python2.1/asyncore.py", line
194, in loop
    poll_fun (timeout, map)
  File "/u01/zope//lib/python2.1/asyncore.py", line 86,
in poll
    r,w,e = select.select (r,w,e, timeout)
  select.error: (4, 'Interrupted system call')



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 09:57

Message:
Logged In: YES 
user_id=12800

Assigning to Jeremy.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-19 15:47

Message:
Logged In: NO 

Sorry, the user's email is jziniti@speakeasy.org.

EWOULDBLOCK was reported by that user for a different method
in asyncore called accept though it seems that EWOULDBLOCK
is being handled correctly in accept. It seems that the user
did add the try/except block around the select call on line
86 which resulted in later call to accept() throwing
EWOULDBLOCK. The trace is as follows:

system.error 4((4, 'Interrupted system call'))
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <__repr__ (self) failed for
object at dee7bc (addr='/tmp/zope.soc')>
(exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/FCGIServer.py|handle_accept|697])
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <__repr__ (self) failed for
object at dec4bc
(addr='/u01/zope/Zope-2.4.0-src/var/pcgi.soc')>
(exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/PCGIServer.py|handle_accept|380])
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <FTPServer listening :8021 at
debcec> (exceptions.TypeError:unpack non-sequence
[/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|383]
[/u01/zope/Zope-2.4.0-src/ZServer/FTPServer.py|handle_accept|694])
------
2001-08-16T13:16:01 PROBLEM(100) ZServer warning: server
accept() threw EWOULDBLOCK
------
2001-08-16T13:16:01 ERROR(200) ZServer uncaptured python
exception, closing channel <select-trigger (pipe) at 248024>
(exceptions.OSError:[Errno 11] Resource temporarily
unavailable [/u01/zope/lib/python2.1/asyncore.py|poll|101]
[/u01/zope/lib/python2.1/asyncore.py|handle_read_event|389]
[/u01/zope/Zope-2.4.0-src/ZServer/medusa/thread/select_trigger.py|handle_read|77]
[/u01/zope/lib/python2.1/asyncore.py|recv|341]
[/u01/zope/lib/python2.1/asyncore.py|recv|523])


Thanks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453099&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 18:02:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 10:02:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-452973 ] Tcl event loop callback woes
Message-ID: <E15YsRE-0002jP-00@usw-sf-web2.sourceforge.net>

Bugs item #452973, was opened at 2001-08-19 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Egnor (egnor)
>Assigned to: Fredrik Lundh (effbot)
Summary: Tcl event loop callback woes

Initial Comment:
I have C code which handles I/O and needs an event
dispatcher.  It is running in the context of a Python
GUI application, and uses the Tcl event loop, using
Tcl_CreateFileHandler and friends.  The C code gets
callbacks from the Tcl event loop fine, but when it
attempts to call into the Python application from one
of these callbacks, things go wrong.

- Tkinter has released the GIL and hidden the current
thread state.  I can work around this by re-acquiring
the GIL from the callback and creating a new thread state.

- When the callback is invoked, Tkinter's tcl_lock is
held.  If the Python code invoked from the callback
ultimately calls some other Tkinter function, the
tcl_lock is still held, and deadlock results.  The only
way to work around this is to use a single-threaded
Python build.

- If the Python code returns an error, there's no way
to stop the event loop to report the error up. 
Tkinter's error-reporting mechanisms are inaccessible.

In general, Tkinter has a lot of infrastructure for
managing callbacks from the Tcl event loop.  If a third
party C library wants to use the same event loop, that
infrastructure is unavailable, and it is very difficult
to work with Python.

Unfortunately, short of using threads (which have their
own problems), there's no other alternative for an
external C library to do I/O without blocking the GUI.
 I've seen several problem reports from people trying
to do exactly this, though they almost never figure out
all of what's going on, and nobody else ever has any
good advice to offer.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 10:02

Message:
Logged In: YES 
user_id=12800

For lack of a volunteer or better victim... er, assigning to /F

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:30:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:30:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15YtoT-0005NE-00@usw-sf-web1.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:32:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:32:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15Ytqj-0002c7-00@usw-sf-web3.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 11:32

Message:
Logged In: NO 

Also if there is a simple way in useing the product to do 
this my apolgies. I looked at all the literature I could 
find and scoured the menus .. I couldn't figure it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:32:38 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:32:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-452973 ] Tcl event loop callback woes
Message-ID: <E15Ytqo-0002cL-00@usw-sf-web3.sourceforge.net>

Bugs item #452973, was opened at 2001-08-19 09:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Egnor (egnor)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Tcl event loop callback woes

Initial Comment:
I have C code which handles I/O and needs an event
dispatcher.  It is running in the context of a Python
GUI application, and uses the Tcl event loop, using
Tcl_CreateFileHandler and friends.  The C code gets
callbacks from the Tcl event loop fine, but when it
attempts to call into the Python application from one
of these callbacks, things go wrong.

- Tkinter has released the GIL and hidden the current
thread state.  I can work around this by re-acquiring
the GIL from the callback and creating a new thread state.

- When the callback is invoked, Tkinter's tcl_lock is
held.  If the Python code invoked from the callback
ultimately calls some other Tkinter function, the
tcl_lock is still held, and deadlock results.  The only
way to work around this is to use a single-threaded
Python build.

- If the Python code returns an error, there's no way
to stop the event loop to report the error up. 
Tkinter's error-reporting mechanisms are inaccessible.

In general, Tkinter has a lot of infrastructure for
managing callbacks from the Tcl event loop.  If a third
party C library wants to use the same event loop, that
infrastructure is unavailable, and it is very difficult
to work with Python.

Unfortunately, short of using threads (which have their
own problems), there's no other alternative for an
external C library to do I/O without blocking the GUI.
 I've seen several problem reports from people trying
to do exactly this, though they almost never figure out
all of what's going on, and nobody else ever has any
good advice to offer.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 11:32

Message:
Logged In: YES 
user_id=6380

Unassigning -- /F is a black hole. :-(

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 10:02

Message:
Logged In: YES 
user_id=12800

For lack of a volunteer or better victim... er, assigning to /F

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452973&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:40:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:40:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15Yty0-0002kC-00@usw-sf-web3.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Mark Hammond (mhammond)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 11:40

Message:
Logged In: YES 
user_id=6380

Reassigned to Mark Hammond, since he is the author of
Pythonwin.  But since Pythonwin is not part of core Python,
I doubt that this request should be in the core Python bug
tracker.

(I also disagree with the request -- normally, file transfer
programs take care of the CRLF to NL translation.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 11:32

Message:
Logged In: NO 

Also if there is a simple way in useing the product to do 
this my apolgies. I looked at all the literature I could 
find and scoured the menus .. I couldn't figure it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:49:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:49:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-452836 ] BoundedSemaphore class
Message-ID: <E15Yu7B-0002sM-00@usw-sf-web3.sourceforge.net>

Bugs item #452836, was opened at 2001-08-18 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: BoundedSemaphore class

Initial Comment:
Per Guido's request, here's a simple BoundedSemaphore
class, including doc update (and simple example)
as well as a rudimentary test_threading.py which
draws heavily from test_thread.py.

Assigned to Tim, since he's probably the most likely
person to check the BoundedSemaphore code.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-20 11:49

Message:
Logged In: YES 
user_id=3066

Documentation checked in as Doc/lib/libthreading.tex
revision 1.10.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 06:50

Message:
Logged In: YES 
user_id=44345

Thanks.  I made a change to the docs that should better
reflect how BoundedSemaphore objects behave in the face
of errors, and am assigning to Fred for doc review (new
class and a simple example). I uploaded a new version of
threading.diff (and deleted the old one this time).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:46

Message:
Logged In: YES 
user_id=31435

Cool!  Accepted for the code changes, and back to Skip for 
checkin.  Reassign to Fred for doc changes, if you want.

I would like to see the docs clarified on one point.  When 
it says

"""
ensures that its current value never exceeds its initial 
value
"""

I have no idea what "ensures" means.  Would be better to 
tell the plain truth, i.e. that the release() method 
specifically raises ValueError specifically in such cases; 
a reader could easily imagine, e.g., that instead a 
BoundedSemaphore "ensures" this condition by blocking until 
someone else does an acquire (which would be symmetric with 
acquire() blocking at *its* limit until someone does a 
release(), so isn't an implausible guess).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 00:35

Message:
Logged In: YES 
user_id=31435

Deleted the old patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 19:34

Message:
Logged In: YES 
user_id=31435

Thanks, Skip!  I assigned this back to me (no time this 
instant; will get back to it later tonight).

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-19 17:47

Message:
Logged In: YES 
user_id=44345

I got rid of the assert and just test the value, raising
ValueError if it's out of whack.  Actually, there was
another bug before as well.  I shouldn't have been testing
self.__value, but self._Semaphore__value.  In the
test_threading.py file I wrote for some reason I called
Semaphore instead of BoundedSemaphore.  That's also been
fixed.

I modelled the name of self.__initial_value after
self.__value, but have changed it to only have a single
leading underscore.

Skip



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 14:32

Message:
Logged In: YES 
user_id=31435

Back to Skip.

+ Think of a way to do this without using "assert":  
BoundedSempahore doesn't do its job under -O as-is, because 
asserts vanish, and UnreliableBoundedSemaphore would be an 
unwieldy class name <wink>.

+ Consider renaming __initial_value to _initial_value; 
there's no reason to hide this from subclasses, right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=452836&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:52:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:52:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15Yu9x-0002vt-00@usw-sf-web3.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-20 11:52

Message:
Logged In: YES 
user_id=31435

Reassigning to Mark Hammond.  Anonymous, you should direct 
this request to ActiveState -- PythonWin isn't part of the 
core distribution.

IDLE is happy to open files with plain \n endings on 
Windows, but if you write such a file out again, they're 
transformed to \r\n endings.  That's "normal behavior" for 
any tool built on C text-mode I/O when run on Windows.

Note that I'm a Python developer, and do most of my work on 
Windows.  It doesn't matter, because the developers share 
files via CVS, and CVS automatically converts line ends 
appropriately on each platform that does a checkout.

Also note the crlf.py and lfcr.py tools in Tools\scripts\.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 11:40

Message:
Logged In: YES 
user_id=6380

Reassigned to Mark Hammond, since he is the author of
Pythonwin.  But since Pythonwin is not part of core Python,
I doubt that this request should be in the core Python bug
tracker.

(I also disagree with the request -- normally, file transfer
programs take care of the CRLF to NL translation.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 11:32

Message:
Logged In: NO 

Also if there is a simple way in useing the product to do 
this my apolgies. I looked at all the literature I could 
find and scoured the menus .. I couldn't figure it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 19:55:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 11:55:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-442526 ] lang ref:  Unicode literals undocumented
Message-ID: <E15YuDA-0002yZ-00@usw-sf-web3.sourceforge.net>

Bugs item #442526, was opened at 2001-07-18 11:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: lang ref:  Unicode literals undocumented

Initial Comment:
I'm not really sure who *should* be writing the section
on Unicode literals, but it needs to be done sooner
rather than later.

This is section 2.4.3 in the language reference,
"Unicode literals," in Doc/ref/ref2.tex.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-20 11:55

Message:
Logged In: YES 
user_id=3066

Added description of the rules for string prefixes in
Doc/ref/ref2.tex revision 1.30.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-20 08:33

Message:
Logged In: YES 
user_id=3066

OK, the "String literals" section already takes care of most of the discussion of both raw and Unicode strings, but the grammar productions don't accomodate any use of prefixes for strings.  That needs to be added.  The unnecessary section 2.4.3 is removed in Doc/ref/ref2.tex revision 1.28.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=442526&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:11:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:11:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-433234 ] Problems building under HP-UX 11.0
Message-ID: <E15YvOf-00044H-00@usw-sf-web3.sourceforge.net>

Bugs item #433234, was opened at 2001-06-14 13:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433234&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Ivan Munoz (imbunche)
>Assigned to: Martin v. Lіwis (loewis)
Summary: Problems building under HP-UX 11.0

Initial Comment:
My system:
HP-UX dev1 B.11.00 A 9000/782 2015744842 two-user
license

I'm using gcc, gcc version 2.95.2 19991024 (release)


Trying to compile Python 2.1 I ran into a number of
problems.

After the customary configure; make I get the following
error while making the modules

ld: DP relative code in file
build/temp.hp-ux-B.11.00-9000/782-2.1/_weakref.o -
shared library must be position
independent.  Use +z or +Z to recompile.
WARNING: building of extension "_weakref" failed:
command 'ld' failed with exit status 1

The error message is the same for all extensions.

I fixed it by defining in the Makefile
CFLAGSFORSHARED=-fpic

tried again ... better but:

gcc  -Wl,-E -Wl,+s
-Wl,+b/home/imunoz/local/hp/lib/python2.1/lib-dynload
-o python \
                Modules/python.o \
                libpython2.1.a -lnsl -ldld  -lpthread  
-lm  
/usr/bin/ld: Data Linkage Table (+z) overflow in file
libpython2.1.a(exceptions.o) - use +Z option to
recompile
collect2: ld returned 1 exit status
make: *** [python] Error 1

Then I changed -fpic by -fPIC and voila! (tip found
thanx to a google search).

still problems when generating the module's shared
libraries. Fixed by:
Makefile:301
# Build the shared modules
sharedmods: $(PYTHON)
PY_CFLAGS=	$(CFLAGS) $(CFLAGSFORSHARED) -fPIC
	PYTHONPATH= ./$(PYTHON) $(srcdir)/setup.py build

This last step I don't understand but Python won't make
the modules without it.


Finally got Python 2.1 in HP-UX 11. Does anyone knows a
better way?


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-20 13:11

Message:
Logged In: YES 
user_id=35752

Assigned to Martin as I think he knowns more about shared
libraries than I do.  I think for gcc that -fPIC should
be supplied if shared libraries are being built.  So,
CFLAGSFORSHARED should include -fPIC.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=433234&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:19:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:19:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-451890 ] Building with Large File Support fails
Message-ID: <E15YvVv-0007Bl-00@usw-sf-web1.sourceforge.net>

Bugs item #451890, was opened at 2001-08-16 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: Nobody/Anonymous (nobody)
Summary: Building with Large File Support fails

Initial Comment:
(At least) on Linux, building 2.2-HEAD fails when 
building with Large File Support. In 
Objects/fileobject.c function _portable_ftell line 
262.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-20 13:19

Message:
Logged In: YES 
user_id=31435

By itself, adding opaque getpos/setpos sounds pretty easy 
(BTW, f{get,set}pos are std in C99).

Returning a usable 64-bit integer remains a x-platform 
mess.  The C99 rationale sez f{get,set}pos are the intended 
way to work with large files, but they provide no way to 
break the abstraction (Jeremy & I both looked in vain -- 
there is no defined way to extract the stream position from 
an fpos_t object, neither to do arithmetic on one).

On Windows, f{get,set}pos are (currently) the only way to 
get a 64-bit stream position from the MS C library (and MS 
doesn't (currently) mix that in with a state encoding; the 
Win32 API has other ways to deal with this).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 06:21

Message:
Logged In: YES 
user_id=6380

OK, so we need to add separate getpos() and setpos() methods
that return an opaque wrapper for an fpos_t. That sounds
like serious work, plus it will require changing Python apps
that use seek and tell.

So I think we shold *also* continue to search for a way to
use a 64-bit seek offset for Python's seek() and tell()
methods -- I'm presuming this is hidden *somewhere* in the
fpos_t still, since the underlying OS certainly uses
lseek64(). If there's no way to extract it out of the
fpos_t, I propose to call lseek64() directly (after using a
fflush()) on the file descriptor.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-19 22:24

Message:
Logged In: YES 
user_id=31435

Noting that C99 *requires* fpos_t values to hold all the 
info in an mbstate_t, in addition to stream position info.  
So we have to expect others to follow glibc in this, and 
eventually everyone.  fpos_t cannot resolve to an array 
type, but anything else is fair (in particular it need not 
map to an integral type -- and probably won't anymore).

We have to give up belief that fpos_t is a number, because 
it's not.  We can believe that ftell returns a number, 
because it does <wink> -- but ftell isn't suitable for 
large file support.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 06:13

Message:
Logged In: YES 
user_id=21627

This started in glibc 2.2, I believe, so it would appear in
Redhat 7, SuSE 7, etc.
To see the problem, you have to ./configure with
CFLAGS="-D_FILE_OFFSET_BITS=64" OPT="-O2 $(CFLAGS)"; see
pyconfig.h.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-17 03:55

Message:
Logged In: YES 
user_id=6380

Whoa.  Interesting. Which Linux version is this?

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-17 00:21

Message:
Logged In: YES 
user_id=21627

This fails because in glibc, fpos_t contains an mb_state 
field, so that on restoring the file position, the 
multibyte encoding state of the file can be restored.

I see two solutions here:
- Python could give up the guarantee that the ftell result 
is a number, and return an object that embeds the fpos_t.
- Python could give up that guarantee that ftell/fseek 
works in all cases, and only use ftell(o), which should 
always return a number (atleast in Posix). If that 
approach is taken, an additional fgetpos/fsetpos call may 
be appropriate.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451890&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:32:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:32:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-450245 ] Error in parsing future stmts
Message-ID: <E15YvjD-0007Pg-00@usw-sf-web1.sourceforge.net>

Bugs item #450245, was opened at 2001-08-12 00:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450245&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Jeremy Hylton (jhylton)
Summary: Error in parsing future stmts

Initial Comment:
This 2-line program:

from __future__ import nested_scopes
from __future__ import generators

yields a bogus:

SyntaxError: from __future__ imports must occur at the 
beginning of the file

PEP 236 says:

"""
The only lines that can appear before a 
future_statement are:

+ The module docstring (if any).
+ Comments.
+ Blank lines.
+ Other future_statements.
"""

Note the last point.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-20 13:32

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.11 of future.c


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-12 13:32

Message:
Logged In: YES 
user_id=31435

Just adding a note to see whether I get email as a result.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450245&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:38:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:38:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit
Message-ID: <E15YvoJ-0005qW-00@usw-sf-web2.sourceforge.net>

Bugs item #453489, was opened at 2001-08-20 13:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using deiconify() hangs on exit

Initial Comment:
If you run the following script, and iconize the 
window before the after() timer, it'll restore and 
raise the window as it should, but then you can't 
exit.  You have to kill winoldap with ctrl+alt+del and 
wait.

I ran into this trying to write a portable jabber 
client using tkinter.

This is with 2.1.1 on Windows 98.  Does it every 
time.  May be related to bug #216289.

from Tkinter import *
import sys

def foo():
   print 'foo'
   sys.stdout.flush()
   root.deiconify()
   print 'bar'
   sys.stdout.flush()

root=Tk()
Button(root, text='Quit', command=root.quit).pack()
root.after(5000, foo)
root.mainloop()


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:41:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:41:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-429570 ] GC objects are tracked prematurely
Message-ID: <E15Yvrf-0007Z1-00@usw-sf-web1.sourceforge.net>

Bugs item #429570, was opened at 2001-06-02 04:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429570&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ernst Jan Plugge (rmc)
Assigned to: Neil Schemenauer (nascheme)
Summary: GC objects are tracked prematurely

Initial Comment:
Under certain circumstances, the Python Garbage 
Collector tracks objects that haven't yet been added 
to the GC chain. This causes hard to debug segfaults 
when GC occurs.

I've reduced the problem to this simple case: a simple 
extension module with one extension type that holds a 
reference to another object. The single module method 
creates two objects, lets them point to eachother, and 
returns one of them. This creates a cycle to be broken 
by the GC.

In the attached source, the second PyObject_GC_Init() 
call is done after the references have been set up. If 
called in a 'while 1: a = trouble.createT( "foo" )' 
loop, it segfaults as soon as a GC cycle is performed 
while the method is still setting up the objects.

If the PyObject_GC_Init() call is moved up to 
immediately after the obj field is set to Py_None, no 
segfault occurs.

I believe this should not happen because one should be 
free to mess with tracked objects as long as they 
haven't been added to the GC chain. If it is in fact 
working as designed, this should be documented.

I'm using Python 2.1 on Linux/Intel. 2.0 has the same 
problem, but it shows in slightly different places. 
2.1 made it easier to create this simple minimal case.

It took a few long, frustrating days to track this one 
down, because it didn't show up until the module was 
up to about 20000 twisty lines of code, all 
interconnected... :-(



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-20 13:41

Message:
Logged In: YES 
user_id=35752

The API document says:

  Any container which may be referenced from another object
  reachable by the collector must itself be tracked by the
  collector [...]

Can I close this bug or should the documentation be yet
more explict?  Note that this restriction is lifted by my
"GC API cleanup" patch (i.e. it's okay to have an object
with the GC flag set that is reachable from a tracked
object but is not itself tracked).


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-06-02 23:06

Message:
Logged In: YES 
user_id=31435

Assigned to Neil.  The docs should at least be more 
explicit about that when a container C is added to the GC 
list via PyObject_GC_Init(), all objects reachable from C 
then and until PyObject_GC_Fini() is called must either (a) 
not participate in GC at all, or (b) themselves have been 
PyObject_GC_Init()'ed before becoming reachable from C.

It looks like this particular case would not have blown up 
if, in _PyGC_Insert, op were added to generation0 *before* 
checking to see whether collection should run.  Think 
that's more robust?  Well, maybe in a case where A 
references B references A, but if the cycle being created 
were longer than that this style of programming would still 
lead to problems.

Ernst, independent of all that, when doing

x = y;

get into the rigid habit of incref'ing y before decref'ing 
x.  Sooner or later they're going to point to the same 
object without you realizing it, and then decref'ing x 
first can leave y pointing at trash.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429570&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 21:51:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 13:51:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E15Yw11-0007jC-00@usw-sf-web1.sourceforge.net>

Bugs item #425370, was opened at 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 13:51

Message:
Logged In: YES 
user_id=12800

Assigning this back to me.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 10:57

Message:
Logged In: YES 
user_id=12800

Ah, or https://sf.net :)

Maybe add this as a test case to test_socket but don't bomb
out if that host isn't responding or reachable?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:34

Message:
Logged In: YES 
user_id=6380

Testing SSL support is easy in interactive mode, e.g.
urllib.urlopen("https://www.openair.com/index.pl")

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:04

Message:
Logged In: YES 
user_id=12800

I believe it is easy to fix (see attached patch), but I
don't have a way of testing it.  There appears to be no
regression test for SSL support, nor is there documentation,
so I have no idea how to /use/ the SSL support in socket module.

Assigning back to Jeremy to double check the patch.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:18

Message:
Logged In: YES 
user_id=31392

Barry, This is a memory leak/free problem, right? So you 
get it.  Seriously, sounds like this would be easy to fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 22:25:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 14:25:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-453059 ] Nasty bug in HTMLParser.py
Message-ID: <E15YwXf-0006XN-00@usw-sf-web2.sourceforge.net>

Bugs item #453059, was opened at 2001-08-19 13:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nasty bug in HTMLParser.py

Initial Comment:
If you feed the following string to an HTMLParser
parser, you get _very_ weird results:

'one & two & three &three; &blagh ;'

What I would expect would be:

 - call to handle_data(data='one & two & three ')

 - call to handle_entityref(name='three')

 - call to handle_data(data=' &blagh ;')

What you actually get is:

 - call to handle_data(data='one ')

 - call to handle_data(data='one ')

...which is very wrong :-S

Now, I'm not sure of the validity of the associated
HTML*, but if it's invalid, I would have thought
exceptions would be thrown rather than the above result.

In any case, I have a module that demonstrates this
problem which is available from:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/squishdot/stripogram/

It has a testsuite that runs with Zope's testrunner.py
and I just added a test to demonstrate this problem.

Any help would be very much appreciated...

Chris

* The string 'one & two & three &three; &blagh ;'
displays exactly as is in Mozilla, IE and Netscape, of
course that doesn't mean the W3C will like it ;-) I'd
prefer to go with the majority rather than being
'right' on this one.




----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-20 14:25

Message:
Logged In: YES 
user_id=3066

Fixed in Lib/HTMLParser.py revision 1.5.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2001-08-20 02:26

Message:
Logged In: YES 
user_id=24723

Here's the patch to fix it:

28,29c28,29
< entityref =
re.compile('&([a-zA-Z][-.a-zA-Z0-9]*)[^a-zA-Z0-9]')
< charref =
re.compile('&#(?:[0-9]+|[xX][0-9a-fA-F]+)[^0-9a-fA-F]')
---
> entityref = re.compile('&([a-zA-Z][-.a-zA-Z0-9]*);')
> charref = re.compile('&#(?:[0-9]+|[xX][0-9a-fA-F]+);')
213,214d212
<                     if rawdata[k-1] != ';':
<                         k = k-1
222,223d219
<                     if rawdata[k-1] != ';':
<                         k = k-1


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453059&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 22:33:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 14:33:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900
Message-ID: <E15Ywg1-0005DN-00@usw-sf-web3.sourceforge.net>

Bugs item #434143, was opened at 2001-06-18 04:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: calendar module broken for 1900

Initial Comment:
Hi there, this is a 'feature' I met on both 1.5.2 and
2.1.

>>> import calendar
>>> calendar.prcal(1865)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
ValueError: year out of range (00-99, 1900-*)

(note that the documentation only refers to 1970 as a
possible limit, and does not mention how dates in 00-99
range are processed)

Now if I try to get the calendar for year 1900 (which
is supposed to work according to the message
hereabove), I get

>>> calendar.prcal(1900)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

I guess this is low priority. 

Cheers 

Alexandre Fayolle


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 14:33

Message:
Logged In: YES 
user_id=44345

Fred, I'm tossing this over your fence.  All I proposed was
some documentation changes to more clearly identify the
problem.

Skip


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-26 22:14

Message:
Logged In: NO 

I think the limitations actually stem from the time module,
which depends on the platform you're running. Notice what I
get on linux:

>>> import calendar
>>> a = calendar.calendar(1902)
>>> b = calendar.calendar(1901) 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/calendar.py", line 181, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/local/lib/python2.1/calendar.py", line 87, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/local/lib/python2.1/calendar.py", line 80, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/local/lib/python2.1/calendar.py", line 71, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

Investigating further, I tried the following:

>>> from time import gmtime, mktime
>>> gmtime(sys.maxint * -1)
(1901, 12, 13, 20, 45, 53, 4, 347, 0)

Right there that's suspicious - calendar.calendar() breaks
down in the year generated by gmtime(sys.maxint * -1).

It gets a bit weird below that point...

>>> gmtime(sys.maxint * -1 - 1)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> gmtime(sys.maxint * -1 - 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer subtraction
>>>
>>> # OK, now try coercing the argument to a long.
>>> gmtime(sys.maxint * -1 - 2L)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> mktime(gmtime(sys.maxint * -1 - 2L))
-2147465648.0
>>> mktime(gmtime(sys.maxint * -1 - 1000000L))
-2147465648.0

Looks like we've hit a lower limit there.
It would take a competent C programmer (which I am not) to
determine whether anything could be done about this.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2001-07-19 00:09

Message:
Logged In: YES 
user_id=116727

sounds good to me. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-18 13:14

Message:
Logged In: YES 
user_id=44345

I propose sidestepping this issue by fiddling with the
documentation.  See the attached file time.diff.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-06 11:40

Message:
Logged In: YES 
user_id=44345

calendar.py is a *very* old module.  Version 1.1 has a date
of 
13-Oct-90.  The message about the ranges almost certainly
comes from the days when Guido and his pals at CWI were 
developing Python on Macs.  I just tried:

    time.mktime((1900,1,1,0,0,0,0,0,0))

on my iMac and it works.  If the year is 1899 it generates
the
traceback.  A year of 1 is currently interpreted as 2001.

I'm not sure this is worth fixing, other than to document
the
limitations better.  If you want to display calendars
perhaps
you should look at Marc-Andre Lemburg's mx.DateTime
module, which supports a much wider range of dates.

Skip
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 22:39:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 14:39:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-453515 ] filecmp.dircmp case sensitivity bug
Message-ID: <E15Ywls-00007S-00@usw-sf-web1.sourceforge.net>

Bugs item #453515, was opened at 2001-08-20 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rik Kabel (ving)
Assigned to: Nobody/Anonymous (nobody)
Summary: filecmp.dircmp case sensitivity bug

Initial Comment:
(warning: python newbie submission)

Platforms: W2K w/Activestate 2.1.1 (same library source found in 2.0 and 2.11 on NetBSD).

filecmp.dircmp performs incorrect filename comparisons when building lists of common and 
directory-unique files. In particular, it sets a dictionary key to the filename (and value to 1) for 
each file in the right-hand tree, and looks for matching names (has_key). This fails on 
case-insensitive platforms when the names are equivalent except for case.

A simple workaround would be to use os.path.normcase() around the filenames before storing and 
comparing, but this is not case-preserving. Case preservation is to be preferred.

A case-preserving workaround might use os.path.normcase() for the dictionary entry keys, but 
store the unchanged filename as the value, and use that value when constructing the list from the 
dictionary.

-- 
Rik      creating tomorrow's legacy systems, today


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 23:12:57 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 15:12:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] restricted execution allows marshal
Message-ID: <E15YxI1-0007DH-00@usw-sf-web2.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
Summary: restricted execution allows marshal

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 23:26:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 15:26:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-425370 ] socketmodule SSL free calls in wrong order
Message-ID: <E15YxUy-0005w5-00@usw-sf-web3.sourceforge.net>

Bugs item #425370, was opened at 2001-05-18 21:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: socketmodule SSL free calls in wrong order

Initial Comment:
I was examining socketmodule.c and notice the following ordering of 
allocation and deallocation regarding SSL.

    static SSLObject *
    newSSLObject(PySocketSockObject *Sock, char *key_file, char *cert_file)
    {
        ...
        self->ctx = SSL_CTX_new(SSLv23_method()); /* Set up context */
        ...
        self->ssl = SSL_new(self->ctx); /* New ssl struct */
        ...
    }

    static void SSL_dealloc(SSLObject *self)
    {
        ...
        SSL_CTX_free(self->ctx);
        SSL_free(self->ssl);
        ...
    }

Perhaps it works for now, but I think that the order of free() calls in
SSL_dealloc should be reversed.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 15:26

Message:
Logged In: YES 
user_id=12800

Alright, I'm committing this change to the trunk for 2.2a2.
 I've got some mods to regrtest which will allow us to test
or skip SSL socket test depending on a command line switch
(it's a good framework which extends the ideas prototyped in
test_largefile).  I'll use this to double check memory
access with Insure.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 13:51

Message:
Logged In: YES 
user_id=12800

Assigning this back to me.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 10:57

Message:
Logged In: YES 
user_id=12800

Ah, or https://sf.net :)

Maybe add this as a test case to test_socket but don't bomb
out if that host isn't responding or reachable?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 09:34

Message:
Logged In: YES 
user_id=6380

Testing SSL support is easy in interactive mode, e.g.
urllib.urlopen("https://www.openair.com/index.pl")

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 09:04

Message:
Logged In: YES 
user_id=12800

I believe it is easy to fix (see attached patch), but I
don't have a way of testing it.  There appears to be no
regression test for SSL support, nor is there documentation,
so I have no idea how to /use/ the SSL support in socket module.

Assigning back to Jeremy to double check the patch.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 09:18

Message:
Logged In: YES 
user_id=31392

Barry, This is a memory leak/free problem, right? So you 
get it.  Seriously, sounds like this would be easy to fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=425370&group_id=5470


From noreply@sourceforge.net  Mon Aug 20 23:51:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 15:51:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit
Message-ID: <E15YxtI-0001Fd-00@usw-sf-web1.sourceforge.net>

Bugs item #453489, was opened at 2001-08-20 13:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using deiconify() hangs on exit

Initial Comment:
If you run the following script, and iconize the 
window before the after() timer, it'll restore and 
raise the window as it should, but then you can't 
exit.  You have to kill winoldap with ctrl+alt+del and 
wait.

I ran into this trying to write a portable jabber 
client using tkinter.

This is with 2.1.1 on Windows 98.  Does it every 
time.  May be related to bug #216289.

from Tkinter import *
import sys

def foo():
   print 'foo'
   sys.stdout.flush()
   root.deiconify()
   print 'bar'
   sys.stdout.flush()

root=Tk()
Button(root, text='Quit', command=root.quit).pack()
root.after(5000, foo)
root.mainloop()


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 15:51

Message:
Logged In: NO 

Interestingly enough, if you add a print statement after 
the mainloop(), it gets printed, showing the event loop 
exits properly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 03:39:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 19:39:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-453489 ] Using deiconify() hangs on exit
Message-ID: <E15Z1SE-0002F9-00@usw-sf-web2.sourceforge.net>

Bugs item #453489, was opened at 2001-08-20 13:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Using deiconify() hangs on exit

Initial Comment:
If you run the following script, and iconize the 
window before the after() timer, it'll restore and 
raise the window as it should, but then you can't 
exit.  You have to kill winoldap with ctrl+alt+del and 
wait.

I ran into this trying to write a portable jabber 
client using tkinter.

This is with 2.1.1 on Windows 98.  Does it every 
time.  May be related to bug #216289.

from Tkinter import *
import sys

def foo():
   print 'foo'
   sys.stdout.flush()
   root.deiconify()
   print 'bar'
   sys.stdout.flush()

root=Tk()
Button(root, text='Quit', command=root.quit).pack()
root.after(5000, foo)
root.mainloop()


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 19:39

Message:
Logged In: YES 
user_id=6380

I agree that this is likely the same as #216289.

AFAIK it's a Tcl bug and we don't know what to do about it.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 15:51

Message:
Logged In: NO 

Interestingly enough, if you add a print statement after 
the mainloop(), it gets printed, showing the event loop 
exits properly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453489&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 04:47:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 20:47:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-449000 ] re.sub(r'\n', ...) broke
Message-ID: <E15Z2W2-000368-00@usw-sf-web2.sourceforge.net>

Bugs item #449000, was opened at 2001-08-07 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449000&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 6
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fredrik Lundh (effbot)
Summary: re.sub(r'\n', ...) broke

Initial Comment:
Fredrik,

I believe the latest changes to re.sub() broke an
endcase in re.sub().

I used to be able to write r'\n' as a pattern and it
would do the same thing as '\n'.
Now this doesn't work any more; '\n' works but r'\n'
doesn't seem to do anything.

I'm guessing this is an endcase handled wrong in the
most recent checkin ("map re.sub() to string.replace(),
when possible" sounds suspicious to me).  I haven't
verified this hypothesis, but it still works in 2.1.1
and is broken in current CVS.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 20:47

Message:
Logged In: YES 
user_id=6380

Lowered priority -- this won't need to hold up the 2.2a2
release.

(But /F, if you fix it before Wednesday, it may still make
it into 2.2a2.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=449000&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 04:49:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 20:49:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E15Z2Xh-0005m2-00@usw-sf-web1.sourceforge.net>

Bugs item #416526, was opened at 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 20:49

Message:
Logged In: YES 
user_id=6380

/F is unavailable, I don't want this to hold up the 2.2a2
release, so I'm lowering the priority because it doesn't
affect Linux or Windows.

(Remember, no bugs/patches with priority >= 7 should be left
when doing a release.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-06-01 17:41

Message:
Logged In: NO 


>An alternate (and perhaps better) workaround could be
to increase the stack size on Mac OS X.

it's been tried and shot down as a will not fix. :-(

instead of +#elif defined(__APPLE_CC__) perhaps we should use __APPLE__ as per the documentation:

There are two relatively new macros: __APPLE__ and __APPLE_CC__.The former refers to any Apple platform, though at present it is only predefined in Apple's gcc-based Mac OS X and Mac OS X Server compilers. The value of the latter is an integer that corresponds to the version number of the compiler. This should allow one to distinguish, for example, between compilers based on the same version of gcc, but with different bug fixes or features. At present, larger values denote (chronologically) later compilers.

- D



----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:01

Message:
Logged In: YES 
user_id=38376

An alternate (and perhaps better) workaround could be
to increase the stack size on Mac OS X.

But in either case, my plan is to get rid of the recursion
limit in 2.2 (stackless SRE may still run out of memory,
but it shouldn't have to run out of stack).

Cheers /F

----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:52

Message:
Logged In: YES 
user_id=80173

Instead of relying on a compiler variable, we should probably 
set a environment variable as part of the ./configure and use 
that to determine when to reduce the USE_RECURSION_LIMIT.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 05:24:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 20 Aug 2001 21:24:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-440725 ] setup.py does not properly build bsddb
Message-ID: <E15Z360-0006IL-00@usw-sf-web1.sourceforge.net>

Bugs item #440725, was opened at 2001-07-12 09:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: setup.py does not properly build bsddb

Initial Comment:
On my Mandrake system, if the db2-devel RPM is
installed it will compile and link bsddb.o and
bsddb.so,
but importing bsddb fails because the .so wasn't
linked with -ldb2, so the dbopen symbol isn't defined.

The attached context diff solves the problem for me.
Note that it's possible that any or all of libdb3,
libdb2,
or libdb1 are installed.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 21:24

Message:
Logged In: YES 
user_id=44345

okay, Guido said, "go ahead", so I just checked in
setup.py 1.51 with my libdb finding patch.  I've
assigned this patch to myself.  Please feel free
to comment with or without changes to setup.py...


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:54

Message:
Logged In: YES 
user_id=34209

I'm wary of submitting this without a release candidate
before-hand... Consider it postponed for 2.1-maint, unless
we have another release candidate. It's still a good idea
for 2.2, IMHO, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 09:13:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 01:13:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-450510 ] results of build on Mac OS X 10.0.4
Message-ID: <E15Z6f1-0006QE-00@usw-sf-web2.sourceforge.net>

Bugs item #450510, was opened at 2001-08-13 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: results of build on Mac OS X 10.0.4

Initial Comment:
I simply wanted to post my list of compiler warnings
and so on, as maybe these are things that need to be
addressed/fixed, or maybe not :)

-John Buell

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-21 01:13

Message:
Logged In: YES 
user_id=45365

The saveFP/restFP bug has been fixed in the repository. The
warnings have not been fixed yet, so I'll leave the bug
report open.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-17 08:25

Message:
Logged In: NO 

Okay, since posting my .txt file failed miserably the other
day (darn Netscape 6.1 preview ;), I'm going to cut and
paste a couple of the warnings I got building yesterday.
None are "doozies", it WILL build and install.

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from Include/pymactoolbox.h:19,
                 from Python/mactoolboxglue.c:27:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
Python/mactoolboxglue.c:97: warning: function declaration
isn't a prototype

./Modules/signalmodule.c:93: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `signal_signal':
./Modules/signalmodule.c:217: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:219: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:230: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `initsignal':
./Modules/signalmodule.c:337: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:341: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:360: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:362: warning: function declaration
isn't a prototype
./Modules/signalmodule.c: In function `finisignal':
./Modules/signalmodule.c:561: warning: function declaration
isn't a prototype
./Modules/signalmodule.c:569: warning: function declaration
isn't a prototype

/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:240:
warnin
g: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:
In functio
n `fake_getaddrinfo':
/Users/jbuell/Documents/Python/python/dist/src/Modules/getaddrinfo.c:370:
warnin
g: suggest explicit braces to avoid ambiguous `else'
In file included from
/Users/jbuell/Documents/Python/python/dist/src/Modules/soc
ketmodule.c:240:
/Users/jbuell/Documents/Python/python/dist/src/Modules/getnameinfo.c:
At top lev
el:
/Users/jbuell/Documents/Python/python/dist/src/Modules/getnameinfo.c:86:
warning
: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:
In functi
on `PySocket_socket':
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:2146:
warn
ing: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:
In functi
on `PySocket_fromfd':
/Users/jbuell/Documents/Python/python/dist/src/Modules/socketmodule.c:2184:
warn
ing: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:
In function 
`dbm_subscript':
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:104:
warning:
 implicit declaration of function `dbm_error'
/Users/jbuell/Documents/Python/python/dist/src/Modules/dbmmodule.c:105:
warning:
 implicit declaration of function `dbm_clearerr'
/Users/jbuell/Documents/Python/python/dist/src/Modules/nismodule.c:
In function 
`nis_cat':
/Users/jbuell/Documents/Python/python/dist/src/Modules/nismodule.c:159:
warning:
 assignment from incompatible pointer type

In file included from /System/Library/Fra
meworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCor
e.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/gestaltmodule.c:28:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/gestaltmodule.c:39:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/gestaltmodule.c:67:
w
arning: function declaration isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/macosmodule.c:28:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/icgluemodule.c:33:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:173:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:193:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:214:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:236:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:262:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:282:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:303:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:324:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:344:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:365:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:391:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:416:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:446:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:521:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:529:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:574:
w
arning: function declaration isn't a prototype
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules/icgluemodule.c:601:
w
arning: function declaration isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Include
/macglue.h:31,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/macfsmodule.c:26:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

In file included from
/System/Library/Frameworks/CoreServices.framework/Framewor
ks/CarbonCore.framework/Headers/CarbonCore.h:25,
                 from
/System/Library/Frameworks/CoreServices.framework/Headers/
CoreServices.h:22,
                 from
/System/Library/Frameworks/Carbon.framework/Headers/Carbon
.h:21,
                 from
/Users/jbuell/Documents/Python/python/dist/src/Mac/Modules
/../Python/getapplbycreator.c:49:
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:317: warning: function declaration
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framewor
k/Headers/MacTypes.h:318: warning: function declaration
isn't a prototype

If anyone wants to see my complete log of this build, e-mail
me personally: dadaist@mac.com

-John Buell

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-14 18:31

Message:
Logged In: YES 
user_id=45365

Ah, thanks! I had noticed the saveFP and restFP errors suddenly popping up but I didn't know where they came from.

I'll fix this shortly, but depending on platform (I assume the '-shared' option wasn't added for nothing, so it'll be needed on some other platform, probably).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-14 10:48

Message:
Logged In: NO 

I had to make a change to setup.py to get some of the
modules to build correctly (even after Jack's changes in
cvs 8/13).  I think there is an interaction with the 
-bundle and -shared ld flags.

--Bill Noon

Index: setup.py
===================================================================
RCS file: /cvsroot/python/python/dist/src/setup.py,v
retrieving revision 1.47
diff -r1.47 setup.py
144c144
<             args['linker_so'] = linker_so + ' -shared'
---
>             args['linker_so'] = linker_so + ''


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450510&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 12:31:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 04:31:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-453683 ] In 2.2, types are callable
Message-ID: <E15Z9l9-0007sl-00@usw-sf-web3.sourceforge.net>

Bugs item #453683, was opened at 2001-08-21 04:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453683&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: In 2.2, types are callable

Initial Comment:
http://python.sourceforge.net/devel-docs/ref/types.html
lists all the callable types, but it does not mention 
that (in 2.2) type objects themselves are callable (it 
only mentions classes, but it definitely seems it's 
only talking about "classic classes" here).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453683&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 12:37:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 04:37:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-453684 ] In 2.2, types are inheritable, &c
Message-ID: <E15Z9qF-0000S2-00@usw-sf-web2.sourceforge.net>

Bugs item #453684, was opened at 2001-08-21 04:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: In 2.2, types are inheritable, &c

Initial Comment:
http://python.sourceforge.net/devel-
docs/ref/class.html says that "Each item in the 
inheritance list should evaluate to a class object" -- 
no mention of 2.2's highlight, that a type can also be 
there?

Is there any mention anywhere in the 2.2a2 language 
reference manual of 2.2's new features?  Maybe I'm 
missing something, but I can't see any -- iterators, 
generators, __slots__, etc, etc.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 12:39:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 04:39:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-453684 ] In 2.2, types are inheritable, &c
Message-ID: <E15Z9sZ-0004PR-00@usw-sf-web1.sourceforge.net>

Bugs item #453684, was opened at 2001-08-21 04:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: In 2.2, types are inheritable, &c

Initial Comment:
http://python.sourceforge.net/devel-
docs/ref/class.html says that "Each item in the 
inheritance list should evaluate to a class object" -- 
no mention of 2.2's highlight, that a type can also be 
there?

Is there any mention anywhere in the 2.2a2 language 
reference manual of 2.2's new features?  Maybe I'm 
missing something, but I can't see any -- iterators, 
generators, __slots__, etc, etc.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 12:52:12 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 04:52:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-429570 ] GC objects are tracked prematurely
Message-ID: <E15ZA4q-0000eX-00@usw-sf-web2.sourceforge.net>

Bugs item #429570, was opened at 2001-06-02 04:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429570&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ernst Jan Plugge (rmc)
Assigned to: Neil Schemenauer (nascheme)
Summary: GC objects are tracked prematurely

Initial Comment:
Under certain circumstances, the Python Garbage 
Collector tracks objects that haven't yet been added 
to the GC chain. This causes hard to debug segfaults 
when GC occurs.

I've reduced the problem to this simple case: a simple 
extension module with one extension type that holds a 
reference to another object. The single module method 
creates two objects, lets them point to eachother, and 
returns one of them. This creates a cycle to be broken 
by the GC.

In the attached source, the second PyObject_GC_Init() 
call is done after the references have been set up. If 
called in a 'while 1: a = trouble.createT( "foo" )' 
loop, it segfaults as soon as a GC cycle is performed 
while the method is still setting up the objects.

If the PyObject_GC_Init() call is moved up to 
immediately after the obj field is set to Py_None, no 
segfault occurs.

I believe this should not happen because one should be 
free to mess with tracked objects as long as they 
haven't been added to the GC chain. If it is in fact 
working as designed, this should be documented.

I'm using Python 2.1 on Linux/Intel. 2.0 has the same 
problem, but it shows in slightly different places. 
2.1 made it easier to create this simple minimal case.

It took a few long, frustrating days to track this one 
down, because it didn't show up until the module was 
up to about 20000 twisty lines of code, all 
interconnected... :-(



----------------------------------------------------------------------

>Comment By: Ernst Jan Plugge (rmc)
Date: 2001-08-21 04:52

Message:
Logged In: YES 
user_id=151380

The cause of the segfault in my original report is the
collision of two issues: first the fact that, at GC time,
all reachable containers must be tracked, and second the
fact that merely adding an object to the GC chain may
trigger a GC sweep. The latter is counter-intuitive to me at
least; I expected GC to occur only at object allocation
time because the GC module doc mentions that GC is triggered
by the number of allocations exceeding a threshold.

The combination of these two issues is what caused the
problem in the first place, and although I had read the docs
reasonably carefully, I missed the connection. Therefore,
I still think this should be mentioned in the docs. For
example by listing the conditions that may trigger a GC
sweep and referring to that list from the text that
documents the restriction that containers reachable from
tracked objects must also be tracked.
Of course if the restriction has been lifted, the issue has
become academic anyway.



----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2001-08-20 13:41

Message:
Logged In: YES 
user_id=35752

The API document says:

  Any container which may be referenced from another object
  reachable by the collector must itself be tracked by the
  collector [...]

Can I close this bug or should the documentation be yet
more explict?  Note that this restriction is lifted by my
"GC API cleanup" patch (i.e. it's okay to have an object
with the GC flag set that is reachable from a tracked
object but is not itself tracked).


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-06-02 23:06

Message:
Logged In: YES 
user_id=31435

Assigned to Neil.  The docs should at least be more 
explicit about that when a container C is added to the GC 
list via PyObject_GC_Init(), all objects reachable from C 
then and until PyObject_GC_Fini() is called must either (a) 
not participate in GC at all, or (b) themselves have been 
PyObject_GC_Init()'ed before becoming reachable from C.

It looks like this particular case would not have blown up 
if, in _PyGC_Insert, op were added to generation0 *before* 
checking to see whether collection should run.  Think 
that's more robust?  Well, maybe in a case where A 
references B references A, but if the cycle being created 
were longer than that this style of programming would still 
lead to problems.

Ernst, independent of all that, when doing

x = y;

get into the rigid habit of incref'ing y before decref'ing 
x.  Sooner or later they're going to point to the same 
object without you realizing it, and then decref'ing x 
first can leave y pointing at trash.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429570&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 13:49:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 05:49:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-453706 ] sgmllib exception behaviour: policy?
Message-ID: <E15ZAyY-0000VU-00@usw-sf-web3.sourceforge.net>

Bugs item #453706, was opened at 2001-08-21 05:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: sgmllib exception behaviour: policy?

Initial Comment:
the standard python htmlparser produces an exception
from sgmllib while parsing this contruction:

<!spacer type="block" height="25">

in the body of an html file. IДm not sure if this is a
regular HTML Tag, but when netscape renders the page,
it seems to ignore it.

The problem is now, that sgmllib produces an uncaught
exception, and i donДt know how to handle this
exception really intelligent by my program. I like to
have a HTLMParser that never crashes, even if he
sometimes produces not exactly output.

What does the developer team think for that? is this
unimportant for the rest of the world or have i found a
bug that should be fixed? if not, can you give me some
suggestions how to work around this bug in my special
case. 

thanks

Michael

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 14:57:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 06:57:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-453728 ] Tutorial: string lits & cont. lines
Message-ID: <E15ZC1t-0006dW-00@usw-sf-web1.sourceforge.net>

Bugs item #453728, was opened at 2001-08-21 06:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453728&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: string lits & cont. lines

Initial Comment:
The text on string literals and continuation lines
(esp. the example) assumes a good understanding of how
string literals and continuation lines work in C; this
needs to be clarified programmers with no experience in
C-like languages.

(Based on a comment sent to python-docs.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453728&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 20:37:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 12:37:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15ZHLP-0007S3-00@usw-sf-web2.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-21 12:37

Message:
Logged In: NO 

Ok I "respectfully" disagree with the disagreement
>>(I also disagree with the request -- normally, file 
>> transfer
>> programs take care of the CRLF to NL translation.)

At best this could be a workaround. Also keep in mind that 
just because some use file transfer programs does not mean 
I or or others have or want to. I have several options 
where this is not viable. 

i.e
My development deliverables reside on a drive with network 
apliance, so that the source can be gotten to via Unix and 
windows by a mount command. Are you asking me to use file 
transfer programs or some other kludge to bypass this 
system? Esp when the best solution would be NOT to 
introduce the problem in the first place??!!

Also whats the problem with requests for enhancement in the 
form of a bug? This is a great opportunity to enhance the 
IDE so that the users can customize the editor to meet 
thier needs. So pardon me but I disagree with the judment 
call on the value of the bug. 





----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 11:52

Message:
Logged In: YES 
user_id=31435

Reassigning to Mark Hammond.  Anonymous, you should direct 
this request to ActiveState -- PythonWin isn't part of the 
core distribution.

IDLE is happy to open files with plain \n endings on 
Windows, but if you write such a file out again, they're 
transformed to \r\n endings.  That's "normal behavior" for 
any tool built on C text-mode I/O when run on Windows.

Note that I'm a Python developer, and do most of my work on 
Windows.  It doesn't matter, because the developers share 
files via CVS, and CVS automatically converts line ends 
appropriately on each platform that does a checkout.

Also note the crlf.py and lfcr.py tools in Tools\scripts\.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 11:40

Message:
Logged In: YES 
user_id=6380

Reassigned to Mark Hammond, since he is the author of
Pythonwin.  But since Pythonwin is not part of core Python,
I doubt that this request should be in the core Python bug
tracker.

(I also disagree with the request -- normally, file transfer
programs take care of the CRLF to NL translation.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 11:32

Message:
Logged In: NO 

Also if there is a simple way in useing the product to do 
this my apolgies. I looked at all the literature I could 
find and scoured the menus .. I couldn't figure it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Tue Aug 21 20:56:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 12:56:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-453459 ] Allow linefeed as eol in Pythonwin IDE
Message-ID: <E15ZHd5-0004D4-00@usw-sf-web1.sourceforge.net>

Bugs item #453459, was opened at 2001-08-20 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470

Category: Windows
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: Allow linefeed as eol in Pythonwin IDE

Initial Comment:
Currently from what I can tell Pythonwin (which is a 
great editorWindows only)allows \r\n as an end of line 
for editing python files.

This is great for windows .. but if you are mostly 
developing in windows and have to have your code 
support Unix this BITES!

Many editors in windows allow for an option to change 
the end of line (see PFE32 for instance). So I for one 
think it would be great if you could enhance this or 
provide a patch.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-21 12:56

Message:
Logged In: YES 
user_id=6380

Well, you could have explained your use case more clearly.

Anyway, please go petition Mark Hammond at ActiveState.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-21 12:37

Message:
Logged In: NO 

Ok I "respectfully" disagree with the disagreement
>>(I also disagree with the request -- normally, file 
>> transfer
>> programs take care of the CRLF to NL translation.)

At best this could be a workaround. Also keep in mind that 
just because some use file transfer programs does not mean 
I or or others have or want to. I have several options 
where this is not viable. 

i.e
My development deliverables reside on a drive with network 
apliance, so that the source can be gotten to via Unix and 
windows by a mount command. Are you asking me to use file 
transfer programs or some other kludge to bypass this 
system? Esp when the best solution would be NOT to 
introduce the problem in the first place??!!

Also whats the problem with requests for enhancement in the 
form of a bug? This is a great opportunity to enhance the 
IDE so that the users can customize the editor to meet 
thier needs. So pardon me but I disagree with the judment 
call on the value of the bug. 





----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-20 11:52

Message:
Logged In: YES 
user_id=31435

Reassigning to Mark Hammond.  Anonymous, you should direct 
this request to ActiveState -- PythonWin isn't part of the 
core distribution.

IDLE is happy to open files with plain \n endings on 
Windows, but if you write such a file out again, they're 
transformed to \r\n endings.  That's "normal behavior" for 
any tool built on C text-mode I/O when run on Windows.

Note that I'm a Python developer, and do most of my work on 
Windows.  It doesn't matter, because the developers share 
files via CVS, and CVS automatically converts line ends 
appropriately on each platform that does a checkout.

Also note the crlf.py and lfcr.py tools in Tools\scripts\.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 11:40

Message:
Logged In: YES 
user_id=6380

Reassigned to Mark Hammond, since he is the author of
Pythonwin.  But since Pythonwin is not part of core Python,
I doubt that this request should be in the core Python bug
tracker.

(I also disagree with the request -- normally, file transfer
programs take care of the CRLF to NL translation.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-20 11:32

Message:
Logged In: NO 

Also if there is a simple way in useing the product to do 
this my apolgies. I looked at all the literature I could 
find and scoured the menus .. I couldn't figure it out.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453459&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 00:42:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 16:42:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-454030 ] distutils cannot link C++ code with GCC
Message-ID: <E15ZLA8-0007pV-00@usw-sf-web1.sourceforge.net>

Bugs item #454030, was opened at 2001-08-21 16:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Nobody/Anonymous (nobody)
Summary: distutils cannot link C++ code with GCC

Initial Comment:
It is mandatory to link C++ code against -lstdc++ -lm 
when creating an extension.

distutils does not do this in 2.1.1

Here is a setup.py for Python CXX that works around 
the problem, but it would be better for distutils to 
understand enough about C++ to do the right thing. 
THen the code for other compilers could be added. But 
GCC is important enough to do first.

You can get the CXX sources from
http://sourceforge.net/projects/cxx/

from distutils.core import setup, Extension

if os.name == 'posix':
	CXX_libraries = ['stdc++','m']
else:
	CXX_libraries = []


setup(name="pycxx_demo", version="1.0",
	ext_modules=
		[Extension(
			"example",
			sources = [
				"Demo/example.cxx",
				"Demo/python.cxx",
				"Demo/range.cxx",
				"Demo/rangetest.cxx",
			
	"Src/cxx_extensions.cxx",
				"Src/cxxextensions.c",
				"Src/cxxsupport.cxx",
			
	"Src/IndirectPythonInterface.cxx" ],
			include_dirs = [ ".", "Demo" ],
			libraries = CXX_libraries
			)
		]
	)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454030&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 02:52:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 18:52:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900
Message-ID: <E15ZNCC-0001Kr-00@usw-sf-web1.sourceforge.net>

Bugs item #434143, was opened at 2001-06-18 04:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
>Assigned to: Skip Montanaro (montanaro)
Summary: calendar module broken for 1900

Initial Comment:
Hi there, this is a 'feature' I met on both 1.5.2 and
2.1.

>>> import calendar
>>> calendar.prcal(1865)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
ValueError: year out of range (00-99, 1900-*)

(note that the documentation only refers to 1970 as a
possible limit, and does not mention how dates in 00-99
range are processed)

Now if I try to get the calendar for year 1900 (which
is supposed to work according to the message
hereabove), I get

>>> calendar.prcal(1900)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

I guess this is low priority. 

Cheers 

Alexandre Fayolle


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-21 18:52

Message:
Logged In: YES 
user_id=3066

Skip, I think you've got the best solution possible short of
adding "real" calendar and date support to the standard
library.  Please commit your suggested changes and close
this report.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 14:33

Message:
Logged In: YES 
user_id=44345

Fred, I'm tossing this over your fence.  All I proposed was
some documentation changes to more clearly identify the
problem.

Skip


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-26 22:14

Message:
Logged In: NO 

I think the limitations actually stem from the time module,
which depends on the platform you're running. Notice what I
get on linux:

>>> import calendar
>>> a = calendar.calendar(1902)
>>> b = calendar.calendar(1901) 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/calendar.py", line 181, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/local/lib/python2.1/calendar.py", line 87, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/local/lib/python2.1/calendar.py", line 80, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/local/lib/python2.1/calendar.py", line 71, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

Investigating further, I tried the following:

>>> from time import gmtime, mktime
>>> gmtime(sys.maxint * -1)
(1901, 12, 13, 20, 45, 53, 4, 347, 0)

Right there that's suspicious - calendar.calendar() breaks
down in the year generated by gmtime(sys.maxint * -1).

It gets a bit weird below that point...

>>> gmtime(sys.maxint * -1 - 1)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> gmtime(sys.maxint * -1 - 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer subtraction
>>>
>>> # OK, now try coercing the argument to a long.
>>> gmtime(sys.maxint * -1 - 2L)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> mktime(gmtime(sys.maxint * -1 - 2L))
-2147465648.0
>>> mktime(gmtime(sys.maxint * -1 - 1000000L))
-2147465648.0

Looks like we've hit a lower limit there.
It would take a competent C programmer (which I am not) to
determine whether anything could be done about this.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2001-07-19 00:09

Message:
Logged In: YES 
user_id=116727

sounds good to me. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-18 13:14

Message:
Logged In: YES 
user_id=44345

I propose sidestepping this issue by fiddling with the
documentation.  See the attached file time.diff.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-06 11:40

Message:
Logged In: YES 
user_id=44345

calendar.py is a *very* old module.  Version 1.1 has a date
of 
13-Oct-90.  The message about the ranges almost certainly
comes from the days when Guido and his pals at CWI were 
developing Python on Macs.  I just tried:

    time.mktime((1900,1,1,0,0,0,0,0,0))

on my iMac and it works.  If the year is 1899 it generates
the
traceback.  A year of 1 is currently interpreted as 2001.

I'm not sure this is worth fixing, other than to document
the
limitations better.  If you want to display calendars
perhaps
you should look at Marc-Andre Lemburg's mx.DateTime
module, which supports a much wider range of dates.

Skip
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 05:30:06 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 21 Aug 2001 21:30:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-454086 ] distutils/mingw32 links to dbg libs
Message-ID: <E15ZPeY-0003dS-00@usw-sf-web1.sourceforge.net>

Bugs item #454086, was opened at 2001-08-21 21:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gerhard Hфring (ghaering)
Assigned to: A.M. Kuchling (akuchling)
Summary: distutils/mingw32 links to dbg libs

Initial Comment:
When compiling extension modules on Windows with
debugging enabled for the native mode of the GNU
compilers ("--compiler=mingw32 --debug"), distutils
tries to link with the debugging version of the
libraries (python21_d.dll, ...). This may be useful for
Microsoft Visual C++, but for the GNU compilers, it
isn't. GNU tools have a different debugging symbol
format than MS tools, so there's no point in doing this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454086&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 09:30:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 01:30:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-451107 ] re.sub does not replace slahes (2.2a1)
Message-ID: <E15ZTOk-0007yR-00@usw-sf-web3.sourceforge.net>

Bugs item #451107, was opened at 2001-08-15 01:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470

Category: Regular Expressions
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Mihai (muqker)
Assigned to: Fredrik Lundh (effbot)
Summary: re.sub does not replace slahes (2.2a1)

Initial Comment:
Python  2.2a1:
>>> re.findall ('\\', 'a\')
['\']

but

>>> re.sub ('\\', 'b', 'a\')
'a\'
>>>

Python 2.0.1:
>>> re.sub ('\\', 'b', 'a\')
'ab'
>>>

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-22 01:30

Message:
Logged In: YES 
user_id=6380

Closing as duplicate of bug 449000.

This will be fixed in 2.2a2, through a work-around that
disables an optimization that causes this problem -- I hope
a real fix will be available in 2.2a3.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451107&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 13:46:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 05:46:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-434143 ] calendar module broken for 1900
Message-ID: <E15ZXP0-000343-00@usw-sf-web2.sourceforge.net>

Bugs item #434143, was opened at 2001-06-18 04:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Skip Montanaro (montanaro)
Summary: calendar module broken for 1900

Initial Comment:
Hi there, this is a 'feature' I met on both 1.5.2 and
2.1.

>>> import calendar
>>> calendar.prcal(1865)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
ValueError: year out of range (00-99, 1900-*)

(note that the documentation only refers to 1970 as a
possible limit, and does not mention how dates in 00-99
range are processed)

Now if I try to get the calendar for year 1900 (which
is supposed to work according to the message
hereabove), I get

>>> calendar.prcal(1900)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.1/calendar.py", line 160, in
prcal
    print calendar(year, w, l, c),
  File "/usr/lib/python2.1/calendar.py", line 179, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/lib/python2.1/calendar.py", line 85, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/lib/python2.1/calendar.py", line 78, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/lib/python2.1/calendar.py", line 69, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

I guess this is low priority. 

Cheers 

Alexandre Fayolle


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-22 05:46

Message:
Logged In: YES 
user_id=44345

changes checked in and bug closed...


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-21 18:52

Message:
Logged In: YES 
user_id=3066

Skip, I think you've got the best solution possible short of
adding "real" calendar and date support to the standard
library.  Please commit your suggested changes and close
this report.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 14:33

Message:
Logged In: YES 
user_id=44345

Fred, I'm tossing this over your fence.  All I proposed was
some documentation changes to more clearly identify the
problem.

Skip


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-26 22:14

Message:
Logged In: NO 

I think the limitations actually stem from the time module,
which depends on the platform you're running. Notice what I
get on linux:

>>> import calendar
>>> a = calendar.calendar(1902)
>>> b = calendar.calendar(1901) 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/calendar.py", line 181, in
calendar
    cal = monthcalendar(year, amonth)
  File "/usr/local/lib/python2.1/calendar.py", line 87, in
monthcalendar
    day1, ndays = monthrange(year, month)
  File "/usr/local/lib/python2.1/calendar.py", line 80, in
monthrange
    day1 = weekday(year, month, 1)
  File "/usr/local/lib/python2.1/calendar.py", line 71, in
weekday
    secs = mktime((year, month, day, 0, 0, 0, 0, 0, 0))
OverflowError: mktime argument out of range

Investigating further, I tried the following:

>>> from time import gmtime, mktime
>>> gmtime(sys.maxint * -1)
(1901, 12, 13, 20, 45, 53, 4, 347, 0)

Right there that's suspicious - calendar.calendar() breaks
down in the year generated by gmtime(sys.maxint * -1).

It gets a bit weird below that point...

>>> gmtime(sys.maxint * -1 - 1)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> gmtime(sys.maxint * -1 - 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
OverflowError: integer subtraction
>>>
>>> # OK, now try coercing the argument to a long.
>>> gmtime(sys.maxint * -1 - 2L)
(1901, 12, 13, 20, 45, 52, 4, 347, 0)
>>> mktime(gmtime(sys.maxint * -1 - 2L))
-2147465648.0
>>> mktime(gmtime(sys.maxint * -1 - 1000000L))
-2147465648.0

Looks like we've hit a lower limit there.
It would take a competent C programmer (which I am not) to
determine whether anything could be done about this.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2001-07-19 00:09

Message:
Logged In: YES 
user_id=116727

sounds good to me. 

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-18 13:14

Message:
Logged In: YES 
user_id=44345

I propose sidestepping this issue by fiddling with the
documentation.  See the attached file time.diff.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-07-06 11:40

Message:
Logged In: YES 
user_id=44345

calendar.py is a *very* old module.  Version 1.1 has a date
of 
13-Oct-90.  The message about the ranges almost certainly
comes from the days when Guido and his pals at CWI were 
developing Python on Macs.  I just tried:

    time.mktime((1900,1,1,0,0,0,0,0,0))

on my iMac and it works.  If the year is 1899 it generates
the
traceback.  A year of 1 is currently interpreted as 2001.

I'm not sure this is worth fixing, other than to document
the
limitations better.  If you want to display calendars
perhaps
you should look at Marc-Andre Lemburg's mx.DateTime
module, which supports a much wider range of dates.

Skip
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=434143&group_id=5470


From noreply@sourceforge.net  Wed Aug 22 19:42:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 11:42:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-454307 ] select.select locks up IDE
Message-ID: <E15ZcxE-0008FC-00@usw-sf-web2.sourceforge.net>

Bugs item #454307, was opened at 2001-08-22 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Emanon Adespoton (emanon)
Assigned to: Jack Jansen (jackjansen)
Summary: select.select locks up IDE

Initial Comment:
Running Medusa with int->long patches etc., calls to 
select.select (polling mode) lock up server computer 
until data is sent to the listening port.  AFAIK, 
select was designed to get around such behaviour.
Also, when select.select is running, there is no way 
to halt the process when in debug mode; the only way 
to stop the code from running is to cmd-ctrl-esc out 
of the IDE.
This was tried under MacOS 9.1 using MacPython 2.1.1.

The same code runs fine on WinPython 2.1.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 00:10:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 16:10:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-454383 ] make test failed in solaris_2.7 with gcc
Message-ID: <E15Zh8V-0002r8-00@usw-sf-web3.sourceforge.net>

Bugs item #454383, was opened at 2001-08-22 16:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454383&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Thiep Duong (duongusa)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failed in solaris_2.7 with gcc

Initial Comment:
I tried to compile/build configure with no option, make
gave no apparent error, but make test failed at the
below messages.
Any clue what to do next?  I am new with Python ....
Please help.

skipping 'sunaudiodev' extension (up-to-date)
running build_scripts
not copying
/fas2/eda2/duong/dev/source/UNIX/Python-2.1.1/Tools/scripts/pydoc
(up-to-date)
find ./Lib -name '*.py[co]' -print | xargs rm -f
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File
"/fas2/eda2/duong/dev/source/UNIX/Python-2.1.1/Lib/random.py",
line 76, in ?
    from math import log as _log, exp as _exp, pi as
_pi, e as _e
ImportError: cannot import name log
make: [test] Error 1 (ignored)
PYTHONPATH= ./python -tt ./Lib/test/regrtest.py -l
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 39, in ?
    import random
  File
"/fas2/eda2/duong/dev/source/UNIX/Python-2.1.1/Lib/random.py",
line 76, in ?
    from math import log as _log, exp as _exp, pi as
_pi, e as _e
ImportError: cannot import name log
Bus Error - core dumped
make: *** [test] Error 138


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454383&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 04:18:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 20:18:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-454446 ] new int overflow handling needs docs
Message-ID: <E15Zl0S-0006a7-00@usw-sf-web2.sourceforge.net>

Bugs item #454446, was opened at 2001-08-22 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454446&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: new int overflow handling needs docs

Initial Comment:
Docs are needed for the new handling of overflow of
short int operations. Would you mind adding these?

This affects x+y, x-y, x*y, x/y, x%y, divmod(x, y),
x**y, pow(x, y[, z]), and -x.

The rules are as follows:

- If an int result overflows, the (new) OverflowWarning
warning is issued (with a message argument indicating
the operation, e.g. "integer addition").

- This warning is ignored by default.

- The warning can be controlled like all warnings, via
the -W command line option (use
-Wdefault::OverflowWarning to cause the warning to be
issued) or via the warnings.filterwarnings() call.

- Unless the warning is turned into an error, the
result is recomputed after converting the arguments to
long ints.

- If the warning is turned into an error, OverflowError
is substituted (for backwards compatibility).

PS. Is it documented yet that
int-to-the-negative-int-power now returns a float?

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454446&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 05:26:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 22 Aug 2001 21:26:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-454456 ] int overflow code needs tests
Message-ID: <E15Zm4L-0008Os-00@usw-sf-web1.sourceforge.net>

Bugs item #454456, was opened at 2001-08-22 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454456&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: int overflow code needs tests

Initial Comment:
The code that implements phase A of PEP 237 is now
checked in. It seems to work, but it deserves a test
suite. When I had first coded it, there were quite a
few surprises when I ran it!

I'm looking for a volunteer to create a test that
checks the various boundary cases, different optional
behaviors, etc.

I need to concentrate on type/class unification, so I
won't get to this myself.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454456&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 08:44:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 00:44:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-454493 ] building _socket failed
Message-ID: <E15ZpA1-0002q7-00@usw-sf-web1.sourceforge.net>

Bugs item #454493, was opened at 2001-08-23 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Nobody/Anonymous (nobody)
Summary: building _socket failed

Initial Comment:
I experienced a build failure of Python2.2a2 on Suse
6.4 Linux 2.2.14

The following error was reported:

gcc -DINET6 -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I~/Python-2.2a2/./Include -I/usr/local/include
-IInclude/ -c ~/Python-2.2a2/Modules/socketmodule.c -o
build/temp.linux-i686-2.2/socketmodule.o
~/Python-2.2a2/Modules/socketmodule.c: In function
`makesockaddr':
~/Python-2.2a2/Modules/socketmodule.c:715: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`getsockaddrarg':
~/Python-2.2a2/Modules/socketmodule.c:828: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`PySocket_getnameinfo':
~/Python-2.2a2/Modules/socketmodule.c:2469: structure
has no member named `sin6_scope_id'
WARNING: building of extension "_socket" failed:
command 'gcc' failed with exit status 1

I didn't see this in 2.2a1. Presumably, there is a
problem with IPv6 support on my machine. Shouldn't
configure have cought this?

Probably also a bug is that test_socket ran
succesfully. Since _socket wasn't build, the old
version in $PREFIX/lib/Python2.2/, which I got from
2.2a1, was used in the test.

Let me know if you need additional info.

Roeland

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 14:21:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 06:21:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-454493 ] building _socket failed
Message-ID: <E15ZuQk-00080O-00@usw-sf-web1.sourceforge.net>

Bugs item #454493, was opened at 2001-08-23 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470

>Category: Extension Modules
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
>Assigned to: Martin v. Lіwis (loewis)
Summary: building _socket failed

Initial Comment:
I experienced a build failure of Python2.2a2 on Suse
6.4 Linux 2.2.14

The following error was reported:

gcc -DINET6 -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I~/Python-2.2a2/./Include -I/usr/local/include
-IInclude/ -c ~/Python-2.2a2/Modules/socketmodule.c -o
build/temp.linux-i686-2.2/socketmodule.o
~/Python-2.2a2/Modules/socketmodule.c: In function
`makesockaddr':
~/Python-2.2a2/Modules/socketmodule.c:715: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`getsockaddrarg':
~/Python-2.2a2/Modules/socketmodule.c:828: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`PySocket_getnameinfo':
~/Python-2.2a2/Modules/socketmodule.c:2469: structure
has no member named `sin6_scope_id'
WARNING: building of extension "_socket" failed:
command 'gcc' failed with exit status 1

I didn't see this in 2.2a1. Presumably, there is a
problem with IPv6 support on my machine. Shouldn't
configure have cought this?

Probably also a bug is that test_socket ran
succesfully. Since _socket wasn't build, the old
version in $PREFIX/lib/Python2.2/, which I got from
2.2a1, was used in the test.

Let me know if you need additional info.

Roeland

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 06:21

Message:
Logged In: YES 
user_id=6380

Thanks for the report.  I've assigned this to the IPv6
author.  He's on vacation, but will look at this when he's
back in a week or so.

Re test_socket succeeding: did you run it from the build
directory, or did you install the broken installation? If
the latter, you have yourself to blame. If the former, I'd
like to see the value of sys.path and all env variables
starting with PYTHON (try "set | grep PYTHON" in your shell)
to help you debug this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 14:35:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 06:35:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-454307 ] select.select locks up IDE
Message-ID: <E15Zudk-0006Mo-00@usw-sf-web2.sourceforge.net>

Bugs item #454307, was opened at 2001-08-22 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Emanon Adespoton (emanon)
>Assigned to: Just van Rossum (jvr)
Summary: select.select locks up IDE

Initial Comment:
Running Medusa with int->long patches etc., calls to 
select.select (polling mode) lock up server computer 
until data is sent to the listening port.  AFAIK, 
select was designed to get around such behaviour.
Also, when select.select is running, there is no way 
to halt the process when in debug mode; the only way 
to stop the code from running is to cmd-ctrl-esc out 
of the IDE.
This was tried under MacOS 9.1 using MacPython 2.1.1.

The same code runs fine on WinPython 2.1.1.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-23 06:35

Message:
Logged In: YES 
user_id=45365

This is a known problem with the IDE: it can only interrupt a script (or give cycles
to other applications, or pass mouse presses and such along) when it gets control, and if
the script doesn't print to stdout or otherwise invokes the IDE it will not get control.

This problem not only exists with select.select, but also with infinite loops, time.sleep()
and various other methods.

The quick solution is to run your script under the bare PythonInterpreter, which does not have
this problem.

And I'm assigning the bug to Just (although a solution will probably require joint work
from both of us).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 15:33:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 07:33:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-210821 ] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <E15ZvXY-0005yu-00@usw-sf-web3.sourceforge.net>

Bugs item #210821, was opened at 2000-08-01 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Initial Comment:
Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=305840

I have a related question, I have a project that I am 
working on, and I ran into an enormous amount of problems 
with file i/o as a result of pythons standard file stuf not 
using win32api, what I'm doing to prevent the problem is re-
building python, and my project (embedded into python) but 
in rebuilding i have edited fileobject.c to force all file 
operation calls to use their win32api counterparts by 
defining macros to replace the stdio functions.  I.E. fopen
() -> createfile(), ...The macro replacement accepts the 
original arguements, converts them as neccessary to the 
ones needed by the win32API func, calls the win32api 
function and then returns a value which models the behavior 
of the original function. 
        As you may have guessed already this presented some 
interesting problems as most of these functions are all 
passing around (FILE *) structures.  To work around this I 
am returning the HANDLE's that these functions return 
letting the program pretend that they are FILE *s.  I would 
have macrod FILE * to be a HANDLE except that one of the 
first functions PyFile_AsFile(f) is of type FILE *, and 
didnt like that very much....     Finally I had replaced 
almost everything..
      Currently I am down to 2 last problems, dealing with 
fputs(), and that in now in my tracebacks sys.stdout 
instead of being an open path to stdout so as to enable 
sys.stdout.write('whatever') to write to stdout and thus to 
screen, it becomes an error as 'my' file opener i believe 
attempts to open a file named stdout..  I havent had much 
luck trying to figure what happens in sysmodule, and was 
wondering if any one had any ideas comments suggestions or 
help to offer.  

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-15 12:21

Message:
added to pep 42


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-13 03:53

Message:
This is a feature request.
Jeremy, how's that feature request PEP coming?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-12 09:01

Message:
Guido -- In 1999, you said you would add this feature.  Did you?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:01

Message:
Please do triage on this bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 15:33:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 07:33:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-454493 ] building _socket failed
Message-ID: <E15ZvYD-0000no-00@usw-sf-web1.sourceforge.net>

Bugs item #454493, was opened at 2001-08-23 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470

Category: Extension Modules
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Martin v. Lіwis (loewis)
Summary: building _socket failed

Initial Comment:
I experienced a build failure of Python2.2a2 on Suse
6.4 Linux 2.2.14

The following error was reported:

gcc -DINET6 -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I~/Python-2.2a2/./Include -I/usr/local/include
-IInclude/ -c ~/Python-2.2a2/Modules/socketmodule.c -o
build/temp.linux-i686-2.2/socketmodule.o
~/Python-2.2a2/Modules/socketmodule.c: In function
`makesockaddr':
~/Python-2.2a2/Modules/socketmodule.c:715: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`getsockaddrarg':
~/Python-2.2a2/Modules/socketmodule.c:828: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`PySocket_getnameinfo':
~/Python-2.2a2/Modules/socketmodule.c:2469: structure
has no member named `sin6_scope_id'
WARNING: building of extension "_socket" failed:
command 'gcc' failed with exit status 1

I didn't see this in 2.2a1. Presumably, there is a
problem with IPv6 support on my machine. Shouldn't
configure have cought this?

Probably also a bug is that test_socket ran
succesfully. Since _socket wasn't build, the old
version in $PREFIX/lib/Python2.2/, which I got from
2.2a1, was used in the test.

Let me know if you need additional info.

Roeland

----------------------------------------------------------------------

>Comment By: Roeland Rengelink (rengelink)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=302601

Re test_socket failing to fail. You can mark that as
irreproducable. I completely deleted my old Python installs
and then did an Install of 2.2a1 followed by a build of
2.2a2. make test now failed on test__all__ with

test test___all__ skipped --  No module named _socket

and on test_socket with

test test_socket crashed -- exceptions.AttributeError:
'module' object has no attribute 'error'

I am of course convinced that this didn't happen last time
;)
Sorry for bothering you with that one.

(the build failure stands, I'm not going crazy yet)

Roeland



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 06:21

Message:
Logged In: YES 
user_id=6380

Thanks for the report.  I've assigned this to the IPv6
author.  He's on vacation, but will look at this when he's
back in a week or so.

Re test_socket succeeding: did you run it from the build
directory, or did you install the broken installation? If
the latter, you have yourself to blame. If the former, I'd
like to see the value of sys.path and all env variables
starting with PYTHON (try "set | grep PYTHON" in your shell)
to help you debug this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 15:38:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 07:38:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-210821 ] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <E15Zvcy-0000tM-00@usw-sf-web1.sourceforge.net>

Bugs item #210821, was opened at 2000-08-01 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Initial Comment:
Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 07:38

Message:
Logged In: YES 
user_id=6380

To strife35 (Adam Edelstein?):

It might be better to have a separate object type that
resembles a file object in its Python interface but uses the
win32api calls rather than stdio.

Can you explain why you need to use win32api I/O calls
directly rather than via the MS-provided standard C library
(which makes Win32 API calls underneath)?

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=305840

I have a related question, I have a project that I am 
working on, and I ran into an enormous amount of problems 
with file i/o as a result of pythons standard file stuf not 
using win32api, what I'm doing to prevent the problem is re-
building python, and my project (embedded into python) but 
in rebuilding i have edited fileobject.c to force all file 
operation calls to use their win32api counterparts by 
defining macros to replace the stdio functions.  I.E. fopen
() -> createfile(), ...The macro replacement accepts the 
original arguements, converts them as neccessary to the 
ones needed by the win32API func, calls the win32api 
function and then returns a value which models the behavior 
of the original function. 
        As you may have guessed already this presented some 
interesting problems as most of these functions are all 
passing around (FILE *) structures.  To work around this I 
am returning the HANDLE's that these functions return 
letting the program pretend that they are FILE *s.  I would 
have macrod FILE * to be a HANDLE except that one of the 
first functions PyFile_AsFile(f) is of type FILE *, and 
didnt like that very much....     Finally I had replaced 
almost everything..
      Currently I am down to 2 last problems, dealing with 
fputs(), and that in now in my tracebacks sys.stdout 
instead of being an open path to stdout so as to enable 
sys.stdout.write('whatever') to write to stdout and thus to 
screen, it becomes an error as 'my' file opener i believe 
attempts to open a file named stdout..  I havent had much 
luck trying to figure what happens in sysmodule, and was 
wondering if any one had any ideas comments suggestions or 
help to offer.  

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-15 12:21

Message:
added to pep 42


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-13 03:53

Message:
This is a feature request.
Jeremy, how's that feature request PEP coming?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-12 09:01

Message:
Guido -- In 1999, you said you would add this feature.  Did you?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:01

Message:
Please do triage on this bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 15:39:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 07:39:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-454493 ] building _socket failed
Message-ID: <E15Zvdv-0000uX-00@usw-sf-web1.sourceforge.net>

Bugs item #454493, was opened at 2001-08-23 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470

Category: Extension Modules
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Martin v. Lіwis (loewis)
Summary: building _socket failed

Initial Comment:
I experienced a build failure of Python2.2a2 on Suse
6.4 Linux 2.2.14

The following error was reported:

gcc -DINET6 -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I~/Python-2.2a2/./Include -I/usr/local/include
-IInclude/ -c ~/Python-2.2a2/Modules/socketmodule.c -o
build/temp.linux-i686-2.2/socketmodule.o
~/Python-2.2a2/Modules/socketmodule.c: In function
`makesockaddr':
~/Python-2.2a2/Modules/socketmodule.c:715: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`getsockaddrarg':
~/Python-2.2a2/Modules/socketmodule.c:828: structure
has no member named `sin6_scope_id'
~/Python-2.2a2/Modules/socketmodule.c: In function
`PySocket_getnameinfo':
~/Python-2.2a2/Modules/socketmodule.c:2469: structure
has no member named `sin6_scope_id'
WARNING: building of extension "_socket" failed:
command 'gcc' failed with exit status 1

I didn't see this in 2.2a1. Presumably, there is a
problem with IPv6 support on my machine. Shouldn't
configure have cought this?

Probably also a bug is that test_socket ran
succesfully. Since _socket wasn't build, the old
version in $PREFIX/lib/Python2.2/, which I got from
2.2a1, was used in the test.

Let me know if you need additional info.

Roeland

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 07:39

Message:
Logged In: YES 
user_id=6380

Oh well. Maybe you built 2.2a2 in the same directory as
2.2a1?

----------------------------------------------------------------------

Comment By: Roeland Rengelink (rengelink)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=302601

Re test_socket failing to fail. You can mark that as
irreproducable. I completely deleted my old Python installs
and then did an Install of 2.2a1 followed by a build of
2.2a2. make test now failed on test__all__ with

test test___all__ skipped --  No module named _socket

and on test_socket with

test test_socket crashed -- exceptions.AttributeError:
'module' object has no attribute 'error'

I am of course convinced that this didn't happen last time
;)
Sorry for bothering you with that one.

(the build failure stands, I'm not going crazy yet)

Roeland



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 06:21

Message:
Logged In: YES 
user_id=6380

Thanks for the report.  I've assigned this to the IPv6
author.  He's on vacation, but will look at this when he's
back in a week or so.

Re test_socket succeeding: did you run it from the build
directory, or did you install the broken installation? If
the latter, you have yourself to blame. If the former, I'd
like to see the value of sys.path and all env variables
starting with PYTHON (try "set | grep PYTHON" in your shell)
to help you debug this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454493&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 16:00:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 08:00:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-210821 ] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <E15Zvy7-0007aR-00@usw-sf-web2.sourceforge.net>

Bugs item #210821, was opened at 2000-08-01 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Initial Comment:
Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 08:00

Message:
Logged In: YES 
user_id=305840

The problem arrises in that this project is running over a 
network, and later I get problems with lockfiles and 
deleting files because although files may appear to 
be "closed" at the python level from the old stdio 
functions like fclose, they are indeed still open at the NT 
level and as a result cant be deleted.  This becomes a real 
problem with OCI files, and other things on NT.  It is not 
a problem on other os's like Solaris, Unix, linux, hpux, 
etc.., it is a WINnt problem
                    Adam

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 07:38

Message:
Logged In: YES 
user_id=6380

To strife35 (Adam Edelstein?):

It might be better to have a separate object type that
resembles a file object in its Python interface but uses the
win32api calls rather than stdio.

Can you explain why you need to use win32api I/O calls
directly rather than via the MS-provided standard C library
(which makes Win32 API calls underneath)?

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=305840

I have a related question, I have a project that I am 
working on, and I ran into an enormous amount of problems 
with file i/o as a result of pythons standard file stuf not 
using win32api, what I'm doing to prevent the problem is re-
building python, and my project (embedded into python) but 
in rebuilding i have edited fileobject.c to force all file 
operation calls to use their win32api counterparts by 
defining macros to replace the stdio functions.  I.E. fopen
() -> createfile(), ...The macro replacement accepts the 
original arguements, converts them as neccessary to the 
ones needed by the win32API func, calls the win32api 
function and then returns a value which models the behavior 
of the original function. 
        As you may have guessed already this presented some 
interesting problems as most of these functions are all 
passing around (FILE *) structures.  To work around this I 
am returning the HANDLE's that these functions return 
letting the program pretend that they are FILE *s.  I would 
have macrod FILE * to be a HANDLE except that one of the 
first functions PyFile_AsFile(f) is of type FILE *, and 
didnt like that very much....     Finally I had replaced 
almost everything..
      Currently I am down to 2 last problems, dealing with 
fputs(), and that in now in my tracebacks sys.stdout 
instead of being an open path to stdout so as to enable 
sys.stdout.write('whatever') to write to stdout and thus to 
screen, it becomes an error as 'my' file opener i believe 
attempts to open a file named stdout..  I havent had much 
luck trying to figure what happens in sysmodule, and was 
wondering if any one had any ideas comments suggestions or 
help to offer.  

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-15 12:21

Message:
added to pep 42


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-13 03:53

Message:
This is a feature request.
Jeremy, how's that feature request PEP coming?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-12 09:01

Message:
Guido -- In 1999, you said you would add this feature.  Did you?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:01

Message:
Please do triage on this bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 17:36:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 09:36:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-210821 ] On Windows, APIs passing FILE* break with Borland C (PR#121)
Message-ID: <E15ZxTS-0007jV-00@usw-sf-web3.sourceforge.net>

Bugs item #210821, was opened at 2000-08-01 14:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jeremy Hylton (jhylton)
Summary: On Windows, APIs passing FILE* break with Borland C (PR#121)

Initial Comment:
Jitterbug-Id: 121
Submitted-By: "Brad Clements" <bkc@murkworks.com>
Date: Wed, 3 Nov 1999 15:53:01 -0500
Version: None
OS: None

The system encountered a fatal error 
After command: 
Received: 
The last error code was: Connection refused 

Web interface using {HYPERLINK "http://samba.anu.edu.au/jitterbug/"}Jitterbug 
{HYPERLINK "../python-bugs/"}Public interface 
{HYPERLINK "../python-bugs.private"}Private interface (requires password) 
{HYPERLINK "http://www.python.org/"}Python home page 

-----
Here's what I said for Python 1.5.2 on Win32 #0

PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
usable on WIN32 from non-VC applications because python15.dll is statically 
linked to the MS runtime DLL. Embedding applications that try to use these 
functions are passing in FILE * structures that do not match MS's runtime 
format. 

For example, I'm using Python in a Borland C++ Builder application. Although I 
can open a FILE *, when passed to python15.dll the FILE * is not usable.

The addition of two helper functions would solve this problem:

FILE * PyRun_OpenFile(char *file, char *mode) 
{
  return fopen(file,mode)
}

int PyRun_CloseFile(FILE *ptr)
{
  return fclose(ptr)
}

This way embedding apps could get python15.dll to open the file and it would 
work.

A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


====================================================================
Audit trail:
Fri Nov 05 10:31:10 1999	guido	moved from incoming to request

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 09:36

Message:
Logged In: YES 
user_id=6380

Hm.  Are you *sure* that you are calling the close()
method?  I find it hard to believe that the stdio fclose()
wouldn't make the corresponding Win32 call to really close
the object. A fairly common failure mode in Python is to
have a local variable referencing an open file and assuming
that when the local variable goes out of scope, the file is
closed.  This will *usually* happen, but sometimes the stack
frame is kept alive (e.g. by exception handling machinery)
and that prevents the file from being closed.

I am very familiar with the Windows problem that you can't
remove/rename a file that's still open -- but I've never
heard of a case where making the explicit close() call
doesn't fix it.

Just trying to be helpful -- what you're embarking on seems
a big project...

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 08:00

Message:
Logged In: YES 
user_id=305840

The problem arrises in that this project is running over a 
network, and later I get problems with lockfiles and 
deleting files because although files may appear to 
be "closed" at the python level from the old stdio 
functions like fclose, they are indeed still open at the NT 
level and as a result cant be deleted.  This becomes a real 
problem with OCI files, and other things on NT.  It is not 
a problem on other os's like Solaris, Unix, linux, hpux, 
etc.., it is a WINnt problem
                    Adam

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-23 07:38

Message:
Logged In: YES 
user_id=6380

To strife35 (Adam Edelstein?):

It might be better to have a separate object type that
resembles a file object in its Python interface but uses the
win32api calls rather than stdio.

Can you explain why you need to use win32api I/O calls
directly rather than via the MS-provided standard C library
(which makes Win32 API calls underneath)?

----------------------------------------------------------------------

Comment By: adam edelstein (strife35)
Date: 2001-08-23 07:33

Message:
Logged In: YES 
user_id=305840

I have a related question, I have a project that I am 
working on, and I ran into an enormous amount of problems 
with file i/o as a result of pythons standard file stuf not 
using win32api, what I'm doing to prevent the problem is re-
building python, and my project (embedded into python) but 
in rebuilding i have edited fileobject.c to force all file 
operation calls to use their win32api counterparts by 
defining macros to replace the stdio functions.  I.E. fopen
() -> createfile(), ...The macro replacement accepts the 
original arguements, converts them as neccessary to the 
ones needed by the win32API func, calls the win32api 
function and then returns a value which models the behavior 
of the original function. 
        As you may have guessed already this presented some 
interesting problems as most of these functions are all 
passing around (FILE *) structures.  To work around this I 
am returning the HANDLE's that these functions return 
letting the program pretend that they are FILE *s.  I would 
have macrod FILE * to be a HANDLE except that one of the 
first functions PyFile_AsFile(f) is of type FILE *, and 
didnt like that very much....     Finally I had replaced 
almost everything..
      Currently I am down to 2 last problems, dealing with 
fputs(), and that in now in my tracebacks sys.stdout 
instead of being an open path to stdout so as to enable 
sys.stdout.write('whatever') to write to stdout and thus to 
screen, it becomes an error as 'my' file opener i believe 
attempts to open a file named stdout..  I havent had much 
luck trying to figure what happens in sysmodule, and was 
wondering if any one had any ideas comments suggestions or 
help to offer.  

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-15 12:21

Message:
added to pep 42


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-09-13 03:53

Message:
This is a feature request.
Jeremy, how's that feature request PEP coming?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-12 09:01

Message:
Guido -- In 1999, you said you would add this feature.  Did you?


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:01

Message:
Please do triage on this bug.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: "Brad Clements" <bkc@murkworks.com>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 3 Nov 1999 20:22:21 -0500

Here it is again.

Also, I believe this will resolve  FAQ entry 8.10


> 8.10. Can't get Py_RunSimpleFile() to work.
> This is very sensitive to the compiler vendor, version and (perhaps) even
> options. If the FILE* structure in your embedding program isn't the same as
> is assumed by the Python interpreter it won't work. The Python 1.5.* DLLs
> (python15.dll) are all compiled with MS VC++ 5.0 and with
> multithreading-DLL options (/MD, I think). 
> 
> If you can't change compilers or flags, try using Py_RunSimpleString(). A
> trick to get it to run an arbitrary file is to construct a call to
> execfile() with the name of your file as argument. 
> 
> 
> 
> ---------------------------------------------------------------------------
> -----


> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..


I confirm that, to the best of my knowledge and belief, this
contribution is free of any claims of third parties under
copyright, patent or other rights or interests ("claims").  To
the extent that I have any such claims, I hereby grant to CNRI a
nonexclusive, irrevocable, royalty-free, worldwide license to
reproduce, distribute, perform and/or display publicly, prepare
derivative versions, and otherwise use this contribution as part
of the Python software and its related documentation, or any
derivative versions thereof, at no cost to CNRI or its licensed
users, and to authorize others to do so.

I acknowledge that CNRI may, at its sole discretion, decide
whether or not to incorporate this contribution in the Python
software and its related documentation.  I further grant CNRI
permission to use my name and other identifying information
provided to CNRI by me for use in connection with the Python
software and its related documentation.



Brad Clements,                bkc@murkworks.com   (315)268-1000
http://www.murkworks.com                          (315)268-9812 Fax
netmeeting: ils://ils.murkworks.com               ICQ: 14856937


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-08-01 14:10

Message:
From: Guido van Rossum <guido@CNRI.Reston.VA.US>
Subject: Re: [Python-bugs-list] Python 1.5.2 bug, tried to post but got error (PR#121)
Date: Wed, 03 Nov 1999 20:08:11 -0500

> I tried to post a bug, but got this error:
> 
> The system encountered a fatal error 

We were being slammed by a defective spider (or, if you're more
paranoid, by a hacker) so we temporarily turned off the webserver.  It
should be back on now.

> Here's what I said for Python 1.5.2 on Win32 #0
> 
> PyRun_SimpleFile, PyRun_File and other functions that take a FILE * are not 
> usable on WIN32 from non-VC applications because python15.dll is statically 
> linked to the MS runtime DLL. Embedding applications that try to use these 
> functions are passing in FILE * structures that do not match MS's runtime 
> format. 
> 
> For example, I'm using Python in a Borland C++ Builder application. Although I 
> can open a FILE *, when passed to python15.dll the FILE * is not usable.
> 
> The addition of two helper functions would solve this problem:
> 
> FILE * PyRun_OpenFile(char *file, char *mode) 
> {
>   return fopen(file,mode)
> }
> 
> int PyRun_CloseFile(FILE *ptr)
> {
>   return fclose(ptr)
> }
> 
> This way embedding apps could get python15.dll to open the file and it would 
> work.
> 
> A temporary workaround is to always load the .pyc file in PyRun_SimpleFile..

This is an elegant solution.  I think I'll add it.

Could you mail me your suggestion again with the legal boilerplate
included?  See http://www.python.org/1.5/bugrelease.html for the text
and explanation.  Our lawyers require that I request this silliness...

--Guido van Rossum (home page: http://www.python.org/~guido/)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210821&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 20:44:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 12:44:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-454685 ] exec() and globals weirdness
Message-ID: <E15a0Ow-0003Ez-00@usw-sf-web2.sourceforge.net>

Bugs item #454685, was opened at 2001-08-23 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454685&group_id=5470

Category: None
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec() and globals weirdness

Initial Comment:
The following program should print:

xyzzy
plugh

but instead it prints:

xyzzy
xyzzy

Program:

gunk = 'xyzzy'

def func():
    global gunk

    junk = 'plugh'
    exec('gunk = junk')

print gunk
func()
print gunk


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454685&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 21:06:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 13:06:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-454685 ] exec() and globals weirdness
Message-ID: <E15a0kF-0002Br-00@usw-sf-web3.sourceforge.net>

Bugs item #454685, was opened at 2001-08-23 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454685&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: exec() and globals weirdness

Initial Comment:
The following program should print:

xyzzy
plugh

but instead it prints:

xyzzy
xyzzy

Program:

gunk = 'xyzzy'

def func():
    global gunk

    junk = 'plugh'
    exec('gunk = junk')

print gunk
func()
print gunk


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-23 13:06

Message:
Logged In: YES 
user_id=31435

Not a bug.  "global" only applies to the code block it 
appears in.  "exec" creates a new code block, so 
the "global gunk" in func has nothing to do with anything 
in the "exec" string -- within the latter code 
block, 'gunk' is a local name.  You have to add "global 
gunk\n" to the exec'ed string if you want 'gunk' to be a 
global name in the code block compiled for that string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454685&group_id=5470


From noreply@sourceforge.net  Thu Aug 23 23:54:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 15:54:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-454456 ] int overflow code needs tests
Message-ID: <E15a3Mk-0000Z9-00@usw-sf-web1.sourceforge.net>

Bugs item #454456, was opened at 2001-08-22 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454456&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: int overflow code needs tests

Initial Comment:
The code that implements phase A of PEP 237 is now
checked in. It seems to work, but it deserves a test
suite. When I had first coded it, there were quite a
few surprises when I ran it!

I'm looking for a volunteer to create a test that
checks the various boundary cases, different optional
behaviors, etc.

I need to concentrate on type/class unification, so I
won't get to this myself.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-23 15:54

Message:
Logged In: YES 
user_id=31435

I added tests to test_long.py that check for auto-long on 
overflowing + - * / ** unary_minus divmod and 3-arg pow.  
That turned up several bugs, but most unrelated to the PEP!

I don't intend to do more on this.  "various boundary 
cases" are pretty well covered now, but "different optional 
behaviors" aren't at all.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454456&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 01:05:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 17:05:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-225744 ] httplib does not check if port is valid (easy to fix?)
Message-ID: <E15a4Th-0006ik-00@usw-sf-web2.sourceforge.net>

Bugs item #225744, was opened at 2000-12-13 20:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225744&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Luca de Alfaro (dealfaro)
>Assigned to: Greg Stein (gstein)
Summary: httplib does not check if port is valid (easy to fix?)

Initial Comment:
In httplib.py, line 336, the following code appears: 

    def _set_hostport(self, host, port):
        if port is None:
            i = string.find(host, ':')
            if i >= 0:
                port = int(host[i+1:])
                host = host[:i]
            else:
                port = self.default_port
        self.host = host
        self.port = port

Ths code breaks if the host string ends with ":", so that
int("") is called.  In the old (1.5.2) version of this 
module, the corresponding int () conversion used to be 
enclosed in a try/except pair: 

                try: port = string.atoi(port)
                except string.atoi_error:
                    raise socket.error, "nonnumeric port"

and this fixed the problem.  
Note BTW that now the error reported by int is 
"ValueError: invalid literal for int():"
rather than the above string.atoi_error. 

I found this problem while downloading web pages, 
but unfortunately I cannot pinpoint which page 
caused the problem. 

Luca de Alfaro

----------------------------------------------------------------------

Comment By: MartinThomas (martinthomas)
Date: 2001-01-10 13:19

Message:
I have been trying to pin down a problem in Redhat's
Update agent which is written in Python (..mostly)
which happens when a proxy is specified. 

In RH7.0, they are still using Python 1.5.2 and the message
'nonnumeric port' is received when a proxy is specified
in the following form:
http://proxy.yourdomain.com:80
but  the following:
proxy.yourdomain.com:80
works..
looking at the code, it seems that it expects that the only
colon would be near the end of the url and makes no
allowance for 'http:' nor 'https:'...

Regards / Martin

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-18 14:38

Message:
Thanks for explaining this more.

I am surprised that a 301 redirect would give an invalid port -- but surely webmasters aren't perfect. :-)

The argument that urllib.Urlopener.open() checks for socket.error but not for other errors is a good one.

However I don't see the httplib.py code raising socket.error elsewhere.  I'll ask Jeremy.  The rest of the module seems to be using a totally different set of exceptions.  On the other hand, it *can* raise socket.error, implicitly (when various socket calls are being made).



----------------------------------------------------------------------

Comment By: Luca de Alfaro (dealfaro)
Date: 2000-12-18 14:25

Message:
There are three (minor?) problems with raising
ValueError. 

1) Compatibility.  I had some code for 1.5.2 that
was trying to load web pages checking for various
errors, and it was expecting this error to cause
a socket error, not a value error. 

2) Accuracy.  ValueError can be caused by
anything.  The 'non-numeric port' error is much 
more informative.  I don't want to catch
ValueError, because it can be caused in too 
many situations.  I also cannot check 
myself that the port is fine, because the 
port and the URL are often given by a  
redirect (errors 301 and 302, if I remember
correctly).  This in fact was the situation 
that caused the problem. 
Hence, my only real solution was to patch my version of httplib. 

3) Style.  I am somewhat new to Python, but I was
under the impression that, stilistically, 
a ValueError was used to convey a situation that
was the fault of the programmer, while other 
more specific errors were used for unexpected 
situations (communication, etc).  Since the 
socket is the result of a URL redirection 
(errors 301 or 302), the programmer is not in 
a position to prevent this error by "better 
checking".  Hence, I would consider a
network-relted exception to be more appropriate 
here. 

But who am I to argue with the creator of Python? 
;-)

Luca


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-14 06:37

Message:
The only effect is that it raises ValueError instead of socket.error.
Where is this a problem?

(Note that string.atoi_error is an alias for ValueError.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225744&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 04:40:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 20:40:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-454843 ] Python2.x sre and threaded import lockin
Message-ID: <E15a7pE-0000ql-00@usw-sf-web2.sourceforge.net>

Bugs item #454843, was opened at 2001-08-23 20:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454843&group_id=5470

Category: Threads
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Joe Kelly (jpkelly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python2.x sre and threaded import lockin

Initial Comment:
There appears to be a bug in the way Python2.x does 
import locking on
sre.  This is illustrated by the following code 
fragments.

$ cat retest
#!/usr/local/bin/python
__import__("ret")

$ cat ret.py
#!/usr/local/bin/python

import time, thread, string
#import time, thread
import re
#import pre
#re=pre

def mythread():
        time.sleep(2)
        url = "hello there"
        url = re.sub(" ", '', url)
        print "hello from threadland", url

thread.start_new_thread(mythread, ())

url = "hello main there"
url = re.sub(" ", '', url)
print "main", url
time.sleep(5)
print "goodbye", url


If you run retest as shown above you get:
$ retest
main hellomainthere
goodbye hellomainthere

It never runs the code in the thread.

If you run python on ret.pyc directly you get the 
correct/expected
result:
$ python ret.pyc
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

If you replace sre with pre by commenting out line 5 
and uncommenting
out line 6 and 7 it works correctly/as expected:
$ retest
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

I've also noticed some strange interaction with other 
imports, i.e. if
you go back to the original ret.py and comment out 
line 3 and
uncomment line 4 (just don't import the string module) 
you get the
following:
$ retest
main hellomainthere
goodbye hellomainthere
hello from threadland hellothere

That is the thread gets executed at the end or 
sometimes not at all:
$ retest
main hellomainthere
goodbye hellomainthere

Again, calling ret directly seems to work.
$ python ret.pyc
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

This has been tested on Solaris 8 running on Intel:
$ uname -a
SunOS machine 5.8 Generic_108529-07 i86pc i386 i86pc

It also exhibits the same behavior under Linux:
$ uname -a
Linux machine 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 
2001 i686 unknown

The above output was generated by python 2.0 compiled 
with threading
on:
$ python
Python 2.0 (#1, May 13 2001, 00:55:08)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.
>>>

It exhibits the same behavior under python 2.1.1:
$ python
Python 2.1.1 (#22, Aug 20 2001, 17:12:35)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454843&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 05:20:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 23 Aug 2001 21:20:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-454843 ] Python2.x sre and threaded import lockin
Message-ID: <E15a8Si-0005Ln-00@usw-sf-web1.sourceforge.net>

Bugs item #454843, was opened at 2001-08-23 20:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454843&group_id=5470

Category: Threads
>Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Joe Kelly (jpkelly)
>Assigned to: Fredrik Lundh (effbot)
Summary: Python2.x sre and threaded import lockin

Initial Comment:
There appears to be a bug in the way Python2.x does 
import locking on
sre.  This is illustrated by the following code 
fragments.

$ cat retest
#!/usr/local/bin/python
__import__("ret")

$ cat ret.py
#!/usr/local/bin/python

import time, thread, string
#import time, thread
import re
#import pre
#re=pre

def mythread():
        time.sleep(2)
        url = "hello there"
        url = re.sub(" ", '', url)
        print "hello from threadland", url

thread.start_new_thread(mythread, ())

url = "hello main there"
url = re.sub(" ", '', url)
print "main", url
time.sleep(5)
print "goodbye", url


If you run retest as shown above you get:
$ retest
main hellomainthere
goodbye hellomainthere

It never runs the code in the thread.

If you run python on ret.pyc directly you get the 
correct/expected
result:
$ python ret.pyc
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

If you replace sre with pre by commenting out line 5 
and uncommenting
out line 6 and 7 it works correctly/as expected:
$ retest
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

I've also noticed some strange interaction with other 
imports, i.e. if
you go back to the original ret.py and comment out 
line 3 and
uncomment line 4 (just don't import the string module) 
you get the
following:
$ retest
main hellomainthere
goodbye hellomainthere
hello from threadland hellothere

That is the thread gets executed at the end or 
sometimes not at all:
$ retest
main hellomainthere
goodbye hellomainthere

Again, calling ret directly seems to work.
$ python ret.pyc
main hellomainthere
hello from threadland hellothere
goodbye hellomainthere

This has been tested on Solaris 8 running on Intel:
$ uname -a
SunOS machine 5.8 Generic_108529-07 i86pc i386 i86pc

It also exhibits the same behavior under Linux:
$ uname -a
Linux machine 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 
2001 i686 unknown

The above output was generated by python 2.0 compiled 
with threading
on:
$ python
Python 2.0 (#1, May 13 2001, 00:55:08)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.
>>>

It exhibits the same behavior under python 2.1.1:
$ python
Python 2.1.1 (#22, Aug 20 2001, 17:12:35)
[GCC 2.95.2 19991024 (release)] on sunos5
Type "copyright", "credits" or "license" for more 
information.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-23 21:20

Message:
Logged In: YES 
user_id=31435

Assigned to Fredrik, but as I said on c.l.py, never write a 
module that spawns threads as a side effect of merely being 
imported.  Everything you're chasing is an accident, and 
while /F may or may not bother worming around this one, 
you're going to get in trouble over and over again.  I've 
reduced the priority accordingly.

/F, the immediate cause for this one is the

        import sre_parse

in the body of sre_compile.compile(), which is reached in 
the spawned thread via calling re.sub().  Since the 
module "ret" is itself imported, the main thread doing the 
import of "ret" holds the import lock for the duration.  
This causes the spawned thread (created by merely 
importing "ret", and there's no proper synchronization in 
the test case either, so accidents compound) to block on 
any import attempt.  In particular, the spawned thread 
blocks on the line shown above.  Worm around that, and it 
blocks somewhere else later; etc.  In *general* it's 
hopeless.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454843&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 09:36:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 01:36:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-454887 ] static/classmethods and tp_slots
Message-ID: <E15aCRn-0004Yv-00@usw-sf-web2.sourceforge.net>

Bugs item #454887, was opened at 2001-08-24 01:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Guido van Rossum (gvanrossum)
Summary: static/classmethods and tp_slots

Initial Comment:
Consider:

>>> class D(object):
...     def __iter__():return iter([1,2,3])
...     __iter__ = staticmethod(__iter__)
... 
>>> D.__iter__()
<iterator object at 0x814cfcc>
>>> iter(D)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iter() of non-sequence

I can't say this is a bug, because i don't think the
behaviour of assignment of staticmethod and classmethod
objects to tp_* slots is defined. However, the
behaviour was unexpected to me.  Also, if the
assignment is illegal it should probably raise an error
at class definition time.

PS I have one or two similar examples of surprising
errors that would probably just need additional docs to
explain them. Should I report these as bugs, or should
I await further releases/doc updates first?

Cheers,

Roeland

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 09:51:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 01:51:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-454891 ] loss of precision in float marshaling
Message-ID: <E15aCgI-0003hE-00@usw-sf-web3.sourceforge.net>

Bugs item #454891, was opened at 2001-08-24 01:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454891&group_id=5470

Category: Parser/Compiler
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: loss of precision in float marshaling

Initial Comment:
putting this in pi.py:

_pi = 3.1415926535897932
class pi:
    def __init__(self):
        self.pi = _pi

then in another module using
import pi
a = pi.pi()

gives 3.1415926535897931  the first time you
run it and 3.1415926535900001 the second time.

What's happened is the first time you run it,
pi.py gets compiled to pi.pyc.  pi.pyc contains
a marshalled version of 3.14159.... .  However,
floats are marshalled to ascii strings with less
than full precision.

Proposed fix: a new floating point marshalling
code should be created, that dumps out the
machine representation of the float in network
byte order and reads it back.  This should be
used in preference to the ascii method on all
platforms using IEEE-754 floats, which is
practically all computers these days.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454891&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 10:42:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 02:42:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-454887 ] static/classmethods and tp_slots
Message-ID: <E15aDUG-0001Yr-00@usw-sf-web1.sourceforge.net>

Bugs item #454887, was opened at 2001-08-24 01:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Guido van Rossum (gvanrossum)
Summary: static/classmethods and tp_slots

Initial Comment:
Consider:

>>> class D(object):
...     def __iter__():return iter([1,2,3])
...     __iter__ = staticmethod(__iter__)
... 
>>> D.__iter__()
<iterator object at 0x814cfcc>
>>> iter(D)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iter() of non-sequence

I can't say this is a bug, because i don't think the
behaviour of assignment of staticmethod and classmethod
objects to tp_* slots is defined. However, the
behaviour was unexpected to me.  Also, if the
assignment is illegal it should probably raise an error
at class definition time.

PS I have one or two similar examples of surprising
errors that would probably just need additional docs to
explain them. Should I report these as bugs, or should
I await further releases/doc updates first?

Cheers,

Roeland

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-24 02:42

Message:
Logged In: YES 
user_id=6380

This is indeed as intended. To get the behavior you want
(iterate over a class object) you would have to define a
metaclass (derived from type) that defines __iter__.

I'll try to ensure this is documented.

I disagree that the assignment is illegal: in general if you
put something invalid in a special method name it's very
hard to detect that until the time you actually try to call
it.

Why don't you email me the other examples?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 11:38:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 03:38:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-454917 ] Wrong URL for SHA standard
Message-ID: <E15aEMZ-00066j-00@usw-sf-web2.sourceforge.net>

Bugs item #454917, was opened at 2001-08-24 03:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454917&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Wrong URL for SHA standard

Initial Comment:
In the documentation for SHA,

the reference to the "Secure Hash Standard" should be

"http://csrc.nist.gov/publications/fips/fips180-
1/fip180-1.pdf"

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454917&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 17:36:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 09:36:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-455003 ] time module
Message-ID: <E15aJwy-0002jU-00@usw-sf-web2.sourceforge.net>

Bugs item #455003, was opened at 2001-08-24 09:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module

Initial Comment:
Is not present in 2.1.1 on Solaris, or Win2000.
I also looked in the CVS of the latest Python Source. Not there either.
Documentation doesn't say that is has been deprecated?
Can anyone help me?
mailto:mcnaught@bea.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 17:40:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 09:40:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-455003 ] time module
Message-ID: <E15aK0q-0008Bg-00@usw-sf-web1.sourceforge.net>

Bugs item #455003, was opened at 2001-08-24 09:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470

Category: Python Library
>Group: Irreproducible
Status: Open
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module

Initial Comment:
Is not present in 2.1.1 on Solaris, or Win2000.
I also looked in the CVS of the latest Python Source. Not there either.
Documentation doesn't say that is has been deprecated?
Can anyone help me?
mailto:mcnaught@bea.com

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-24 09:40

Message:
Logged In: YES 
user_id=6380

You must be thinking of time.py.  There is no such thing;
time is a built-in module, with source at
Modules/timemodule.c.

Does "import time" fail for you? If so, you'll have to do
more digging.  Is timemodule.so present somewhere (on
Solaris)? If so, is the directory where it lives on
sys.path?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 18:27:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 10:27:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-455020 ] identify data objects defined in classes
Message-ID: <E15aKk8-0003Wb-00@usw-sf-web2.sourceforge.net>

Bugs item #455020, was opened at 2001-08-24 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455020&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Ka-Ping Yee (ping)
Summary: identify data objects defined in classes

Initial Comment:
If I define a data object at the module level, pydoc
identifies it and its value.  It would be nice if it
did the same for data objects defined in the class
scope, e.g.:

    Class Frame:
        NO_SHADOW = gtk.SHADOW_NONE
        SHADOW_IN = gtk.SHADOW_IN
	...

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455020&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 18:37:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 10:37:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-454891 ] loss of precision in float marshaling
Message-ID: <E15aKtu-0003ep-00@usw-sf-web2.sourceforge.net>

Bugs item #454891, was opened at 2001-08-24 01:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454891&group_id=5470

Category: Parser/Compiler
>Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: loss of precision in float marshaling

Initial Comment:
putting this in pi.py:

_pi = 3.1415926535897932
class pi:
    def __init__(self):
        self.pi = _pi

then in another module using
import pi
a = pi.pi()

gives 3.1415926535897931  the first time you
run it and 3.1415926535900001 the second time.

What's happened is the first time you run it,
pi.py gets compiled to pi.pyc.  pi.pyc contains
a marshalled version of 3.14159.... .  However,
floats are marshalled to ascii strings with less
than full precision.

Proposed fix: a new floating point marshalling
code should be created, that dumps out the
machine representation of the float in network
byte order and reads it back.  This should be
used in preference to the ascii method on all
platforms using IEEE-754 floats, which is
practically all computers these days.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-24 10:37

Message:
Logged In: YES 
user_id=31435

Closed as Duplicate and Fixed.  This was reported and fixed 
in bug 422177, and released in 2.2a1.  Note that the 754 
standard requires that

double -> string -> double

reproduce the starting double exactly provided at least 17 
significant digits are generated in the string, and .pyc 
files now do that.  Binary formats are much more trouble, 
because .pycs are supposed to be transportable across all 
platforms (not just 754 ones).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454891&group_id=5470


From noreply@sourceforge.net  Fri Aug 24 22:53:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 14:53:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-455003 ] time module
Message-ID: <E15aOt8-0007Dz-00@usw-sf-web2.sourceforge.net>

Bugs item #455003, was opened at 2001-08-24 09:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470

Category: Python Library
Group: Irreproducible
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: time module

Initial Comment:
Is not present in 2.1.1 on Solaris, or Win2000.
I also looked in the CVS of the latest Python Source. Not there either.
Documentation doesn't say that is has been deprecated?
Can anyone help me?
mailto:mcnaught@bea.com

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-24 14:53

Message:
Logged In: YES 
user_id=31435

Closing this bug, because it looks like Guido intended to.  
While it wasn't in doubt, I confirmed that "import time" 
works fine in the released Windows 2.1.1.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-24 09:40

Message:
Logged In: YES 
user_id=6380

You must be thinking of time.py.  There is no such thing;
time is a built-in module, with source at
Modules/timemodule.c.

Does "import time" fail for you? If so, you'll have to do
more digging.  Is timemodule.so present somewhere (on
Solaris)? If so, is the directory where it lives on
sys.path?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455003&group_id=5470


From noreply@sourceforge.net  Sat Aug 25 03:20:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 24 Aug 2001 19:20:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-455183 ] Cygwin build fails for 2.2a2
Message-ID: <E15aT3k-000274-00@usw-sf-web2.sourceforge.net>

Bugs item #455183, was opened at 2001-08-24 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455183&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cygwin build fails for 2.2a2

Initial Comment:
The Cygwin build fails at the compile stage with the 
error message that a working getaddrinfo function is 
needed, unless the option "--disable-ipv6" is 
selected.  

I tried that option (as well as --with-threads=no), 
and both configure and make ran successfully.  I 
started the interpreter from the Python-2.2a2 
directory and successfully imported division and 
generators from __future__.  I ran the interpreter 
test following the instructions for Cygwin and got 
this message:

1 test failed:
    test_strftime
31 tests skipped: test_al test_asynchat test_bsddb 
test_cd test_cl test_dbm test_dl test_fork1 test_gl 
test_imgfile test_largefile test_linuxaudiodev 
test_locale test_minidom test_nis test_ntpath 
test_openpty test_pty test_pyexpat test_sax 
test_socket_ssl test_socketserver test_sunaudiodev 
test_sundry test_thread test_threaded_import 
test_threadedtempfile test_threading test_unicode_file 
test_winreg test_winsound

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455183&group_id=5470


From noreply@sourceforge.net  Sat Aug 25 08:25:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 Aug 2001 00:25:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] restricted execution allows marshal
Message-ID: <E15aXow-0004lk-00@usw-sf-web3.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
>Assigned to: Tim Peters (tim_one)
Summary: restricted execution allows marshal

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2001-08-25 00:25

Message:
Logged In: YES 
user_id=6656

I think a reasonable approach to the first problem is to not 
let marshal load code objects when in restricted execution 
mode.

The second crasher you mention is much more worrying, to me.  
I think it blows the "immutable list trick" out of the water.

I'll attach a patch to marshal (from another machine) and 
assign to Tim to think about the list nagery.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 01:32:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 Aug 2001 17:32:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-455405 ] operator TypeErrors
Message-ID: <E15anqh-0001w9-00@usw-sf-web1.sourceforge.net>

Bugs item #455405, was opened at 2001-08-25 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455405&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark J (average)
Assigned to: Guido van Rossum (gvanrossum)
Summary: operator TypeErrors

Initial Comment:
Platform:  RedHat 7.1, Python 2.2a1.  Haven't been able
to verify on 2.2a2 but given absent bug report it looks
like it may apply there as well.  Apologies if this is
merely due to alpha release and unfinished
implementation.

Given:

class D(dictionary):
    def __add__(self, other):
        return
    def __sub__(self, other):
        return
    def __isub__(self, other):
        return self

>>> d=D()
>>> d + []          #works
>>> d -= []         #works
>>> d.__sub__([])   #works
>>> d - []          #oops
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for -
>>> d - D()         #works

Some of the other operators (ex. /,^) are problematic
as well.  Problem also appears with objects derived
from type list.

Let me know if you need more info.  Thanks!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455405&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 02:33:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 Aug 2001 18:33:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-454446 ] new int overflow handling needs docs
Message-ID: <E15aonu-0002ml-00@usw-sf-web1.sourceforge.net>

Bugs item #454446, was opened at 2001-08-22 20:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454446&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 6
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: new int overflow handling needs docs

Initial Comment:
Docs are needed for the new handling of overflow of
short int operations. Would you mind adding these?

This affects x+y, x-y, x*y, x/y, x%y, divmod(x, y),
x**y, pow(x, y[, z]), and -x.

The rules are as follows:

- If an int result overflows, the (new) OverflowWarning
warning is issued (with a message argument indicating
the operation, e.g. "integer addition").

- This warning is ignored by default.

- The warning can be controlled like all warnings, via
the -W command line option (use
-Wdefault::OverflowWarning to cause the warning to be
issued) or via the warnings.filterwarnings() call.

- Unless the warning is turned into an error, the
result is recomputed after converting the arguments to
long ints.

- If the warning is turned into an error, OverflowError
is substituted (for backwards compatibility).

PS. Is it documented yet that
int-to-the-negative-int-power now returns a float?

Thanks!

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-25 18:33

Message:
Logged In: YES 
user_id=3066

Bumped priority.

No, the int-to-negative-int-power behavior has not been documented.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454446&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 06:16:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 25 Aug 2001 22:16:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-455438 ] C API version mismatch for strop
Message-ID: <E15asHN-0005qY-00@usw-sf-web1.sourceforge.net>

Bugs item #455438, was opened at 2001-08-25 22:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: C API version mismatch for strop

Initial Comment:
On starting the Python 2.2a2 interpreter from the command line in Mac OS X, I get the following error message:

/usr/local/lib/python2.2/string.py:381: RuntimeWarning: Python C API version mismatch for module strop: This Python has API version 1011, module strop has version 1010.
  from strop import maketrans, lowercase, uppercase, whitespace


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 16:35:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 08:35:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-455438 ] C API version mismatch for strop
Message-ID: <E15b1ww-0002TW-00@usw-sf-web3.sourceforge.net>

Bugs item #455438, was opened at 2001-08-25 22:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jack Jansen (jackjansen)
Summary: C API version mismatch for strop

Initial Comment:
On starting the Python 2.2a2 interpreter from the command line in Mac OS X, I get the following error message:

/usr/local/lib/python2.2/string.py:381: RuntimeWarning: Python C API version mismatch for module strop: This Python has API version 1011, module strop has version 1010.
  from strop import maketrans, lowercase, uppercase, whitespace


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 16:37:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 08:37:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-450013 ] bsddbmodule.c problem
Message-ID: <E15b1ya-0002Uy-00@usw-sf-web3.sourceforge.net>

Bugs item #450013, was opened at 2001-08-11 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450013&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddbmodule.c problem

Initial Comment:
Hello all,

I'am trying to compile python 2.0.1 on my slack 8.0 but
look at the result:


make[1]: Entering directory
`/home/blenderman/2compile/Python-2.0.1/Modules'
gcc -fpic  -g -O2 -Wall -Wstrict-prototypes -fPIC
-I./../Include -I.. -DHAVE_CON                        
     FIG_H -c ./bsddbmodule.c
./bsddbmodule.c: In function `newdbhashobject':
./bsddbmodule.c:55: `HASHINFO' undeclared (first use in
this function)
./bsddbmodule.c:55: (Each undeclared identifier is
reported only once
./bsddbmodule.c:55: for each function it appears in.)
./bsddbmodule.c:55: parse error before `info'
./bsddbmodule.c:60: `info' undeclared (first use in
this function)
./bsddbmodule.c:71: warning: implicit declaration of
function `dbopen'
./bsddbmodule.c:71: warning: assignment makes pointer
from integer without a cas                              t
./bsddbmodule.c: In function `newdbbtobject':
./bsddbmodule.c:100: `BTREEINFO' undeclared (first use
in this function)
./bsddbmodule.c:100: parse error before `info'
./bsddbmodule.c:105: `info' undeclared (first use in
this function)
./bsddbmodule.c:118: warning: assignment makes pointer
from integer without a ca                              st
./bsddbmodule.c: In function `newdbrnobject':
./bsddbmodule.c:147: `RECNOINFO' undeclared (first use
in this function)
./bsddbmodule.c:147: parse error before `info'
./bsddbmodule.c:152: `info' undeclared (first use in
this function)
./bsddbmodule.c:164: warning: assignment makes pointer
from integer without a ca                              st
./bsddbmodule.c: In function `bsddb_dealloc':
./bsddbmodule.c:202: too few arguments to function
./bsddbmodule.c: In function `bsddb_length':
./bsddbmodule.c:232: structure has no member named `seq'
./bsddbmodule.c:233: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:235: structure has no member named
`seq'./bsddbmodule.c:307: warning: passing arg 2 of
pointer to function from incompat                     
        ible pointer type
./bsddbmodule.c:307: too few arguments to function
./bsddbmodule.c:330: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:330: too few arguments to function
./bsddbmodule.c: In function `bsddb_close':
./bsddbmodule.c:357: too few arguments to function
./bsddbmodule.c: In function `bsddb_keys':
./bsddbmodule.c:386: structure has no member named `seq'
./bsddbmodule.c:386: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:407: structure has no member named `seq'
./bsddbmodule.c:407: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:376: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_has_key':
./bsddbmodule.c:440: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:440: too few arguments to function
./bsddbmodule.c: In function `bsddb_set_location':
./bsddbmodule.c:466: structure has no member named `seq'
./bsddbmodule.c:466: `R_CURSOR' undeclared (first use
in this function)
./bsddbmodule.c:453: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_seq':
./bsddbmodule.c:503: structure has no member named
`seq'make[1]: Leaving directory
`/home/blenderman/2compile/Python-2.0.1/Modules'
make: *** [sharedmods] Error 2
bash-2.05$
./bsddbmodule.c:489: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_next':
./bsddbmodule.c:531: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_previous':
./bsddbmodule.c:536: `R_PREV' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_first':
./bsddbmodule.c:541: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_last':
./bsddbmodule.c:546: `R_LAST' undeclared (first use in
this function)
make[1]: *** [bsddbmodule.o] Error 1

./bsddbmodule.c:236: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:229: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_subscript':
./bsddbmodule.c:265: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:265: too few arguments to function
./bsddbmodule.c: In function `bsddb_ass_sub':



Voila...
what can I do ?

-pol-

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-26 08:37

Message:
Logged In: YES 
user_id=31392

Two weeks without any comment from the anonymous submittor..

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-11 07:13

Message:
Logged In: YES 
user_id=21627

Try configuring with --without-libdb. Please report 
whether this helps.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450013&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 17:53:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 09:53:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-454307 ] select.select locks up IDE
Message-ID: <E15b3AN-0003UN-00@usw-sf-web3.sourceforge.net>

Bugs item #454307, was opened at 2001-08-22 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Emanon Adespoton (emanon)
Assigned to: Just van Rossum (jvr)
Summary: select.select locks up IDE

Initial Comment:
Running Medusa with int->long patches etc., calls to 
select.select (polling mode) lock up server computer 
until data is sent to the listening port.  AFAIK, 
select was designed to get around such behaviour.
Also, when select.select is running, there is no way 
to halt the process when in debug mode; the only way 
to stop the code from running is to cmd-ctrl-esc out 
of the IDE.
This was tried under MacOS 9.1 using MacPython 2.1.1.

The same code runs fine on WinPython 2.1.1.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2001-08-26 09:53

Message:
Logged In: YES 
user_id=92689

I don't agree this is a bug at all: the IDE currently
doesn't do multi threading. However, there *is* a solution
for the IDE: you should register asyncore.poll as an idle
handler, like so:
import W, asyncore
W.getapplication().addidlefunc(asyncore.poll)
Further discussion to the macpython list please: I'm on
vacation ,-)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-23 06:35

Message:
Logged In: YES 
user_id=45365

This is a known problem with the IDE: it can only interrupt a script (or give cycles
to other applications, or pass mouse presses and such along) when it gets control, and if
the script doesn't print to stdout or otherwise invokes the IDE it will not get control.

This problem not only exists with select.select, but also with infinite loops, time.sleep()
and various other methods.

The quick solution is to run your script under the bare PythonInterpreter, which does not have
this problem.

And I'm assigning the bug to Just (although a solution will probably require joint work
from both of us).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 17:54:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 09:54:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-454307 ] select.select locks up IDE
Message-ID: <E15b3BU-0003V7-00@usw-sf-web3.sourceforge.net>

Bugs item #454307, was opened at 2001-08-22 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Emanon Adespoton (emanon)
Assigned to: Just van Rossum (jvr)
Summary: select.select locks up IDE

Initial Comment:
Running Medusa with int->long patches etc., calls to 
select.select (polling mode) lock up server computer 
until data is sent to the listening port.  AFAIK, 
select was designed to get around such behaviour.
Also, when select.select is running, there is no way 
to halt the process when in debug mode; the only way 
to stop the code from running is to cmd-ctrl-esc out 
of the IDE.
This was tried under MacOS 9.1 using MacPython 2.1.1.

The same code runs fine on WinPython 2.1.1.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2001-08-26 09:53

Message:
Logged In: YES 
user_id=92689

I don't agree this is a bug at all: the IDE currently
doesn't do multi threading. However, there *is* a solution
for the IDE: you should register asyncore.poll as an idle
handler, like so:
import W, asyncore
W.getapplication().addidlefunc(asyncore.poll)
Further discussion to the macpython list please: I'm on
vacation ,-)

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-23 06:35

Message:
Logged In: YES 
user_id=45365

This is a known problem with the IDE: it can only interrupt a script (or give cycles
to other applications, or pass mouse presses and such along) when it gets control, and if
the script doesn't print to stdout or otherwise invokes the IDE it will not get control.

This problem not only exists with select.select, but also with infinite loops, time.sleep()
and various other methods.

The quick solution is to run your script under the bare PythonInterpreter, which does not have
this problem.

And I'm assigning the bug to Just (although a solution will probably require joint work
from both of us).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454307&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 18:08:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 10:08:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-455537 ] module search in import.c
Message-ID: <E15b3OC-0008Kg-00@usw-sf-web1.sourceforge.net>

Bugs item #455537, was opened at 2001-08-26 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: module search in import.c

Initial Comment:
I'm porting 2.1.1 to QNX6 and got the situation that the module 'os' could not
be be found with 'import os'

After some hacking with DDD .. I found out that the pathes used by the search
algorithm of import.c has nothing to do with the directory structure of the UNIX
distribution of Python 2.1.1 =:-/

I have installed Python in the root directory and set PYTHONHOME/PYTHONPATH to
/Python-2.1.1 -> the path to he library modules is then

                     -> /Python-2.1.1/Lib   OK ... that's not a clean place for UNIX freaks :)

The search algorithm of import.c is using the following search path sequence:

  "os.so"   -> I don't know why it should make sense to open
               a shared object with fopen ??
  "osmodule.so"
  "os.py"
  "os.pyc"

  "/Python-2.1.1/os.so" ... os.pyc

  "/Python-2.1.1/lib/python2.1/os.so" ... os.pyc
                ^^^^^^^^^^^^^^^ who got the idea that this is part of the 
                                                  UNIX tar.gz distribution ??

Also ... there are similar problems with the binaries installed by 'make install' ...

Armin

a-steinhoff@web.de

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470


From noreply@sourceforge.net  Sun Aug 26 19:53:03 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 11:53:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-450013 ] bsddbmodule.c problem
Message-ID: <E15b51r-0001Rc-00@usw-sf-web1.sourceforge.net>

Bugs item #450013, was opened at 2001-08-11 01:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450013&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddbmodule.c problem

Initial Comment:
Hello all,

I'am trying to compile python 2.0.1 on my slack 8.0 but
look at the result:


make[1]: Entering directory
`/home/blenderman/2compile/Python-2.0.1/Modules'
gcc -fpic  -g -O2 -Wall -Wstrict-prototypes -fPIC
-I./../Include -I.. -DHAVE_CON                        
     FIG_H -c ./bsddbmodule.c
./bsddbmodule.c: In function `newdbhashobject':
./bsddbmodule.c:55: `HASHINFO' undeclared (first use in
this function)
./bsddbmodule.c:55: (Each undeclared identifier is
reported only once
./bsddbmodule.c:55: for each function it appears in.)
./bsddbmodule.c:55: parse error before `info'
./bsddbmodule.c:60: `info' undeclared (first use in
this function)
./bsddbmodule.c:71: warning: implicit declaration of
function `dbopen'
./bsddbmodule.c:71: warning: assignment makes pointer
from integer without a cas                              t
./bsddbmodule.c: In function `newdbbtobject':
./bsddbmodule.c:100: `BTREEINFO' undeclared (first use
in this function)
./bsddbmodule.c:100: parse error before `info'
./bsddbmodule.c:105: `info' undeclared (first use in
this function)
./bsddbmodule.c:118: warning: assignment makes pointer
from integer without a ca                              st
./bsddbmodule.c: In function `newdbrnobject':
./bsddbmodule.c:147: `RECNOINFO' undeclared (first use
in this function)
./bsddbmodule.c:147: parse error before `info'
./bsddbmodule.c:152: `info' undeclared (first use in
this function)
./bsddbmodule.c:164: warning: assignment makes pointer
from integer without a ca                              st
./bsddbmodule.c: In function `bsddb_dealloc':
./bsddbmodule.c:202: too few arguments to function
./bsddbmodule.c: In function `bsddb_length':
./bsddbmodule.c:232: structure has no member named `seq'
./bsddbmodule.c:233: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:235: structure has no member named
`seq'./bsddbmodule.c:307: warning: passing arg 2 of
pointer to function from incompat                     
        ible pointer type
./bsddbmodule.c:307: too few arguments to function
./bsddbmodule.c:330: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:330: too few arguments to function
./bsddbmodule.c: In function `bsddb_close':
./bsddbmodule.c:357: too few arguments to function
./bsddbmodule.c: In function `bsddb_keys':
./bsddbmodule.c:386: structure has no member named `seq'
./bsddbmodule.c:386: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c:407: structure has no member named `seq'
./bsddbmodule.c:407: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:376: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_has_key':
./bsddbmodule.c:440: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:440: too few arguments to function
./bsddbmodule.c: In function `bsddb_set_location':
./bsddbmodule.c:466: structure has no member named `seq'
./bsddbmodule.c:466: `R_CURSOR' undeclared (first use
in this function)
./bsddbmodule.c:453: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_seq':
./bsddbmodule.c:503: structure has no member named
`seq'make[1]: Leaving directory
`/home/blenderman/2compile/Python-2.0.1/Modules'
make: *** [sharedmods] Error 2
bash-2.05$
./bsddbmodule.c:489: warning: `status' might be used
uninitialized in this funct                           
  ion
./bsddbmodule.c: In function `bsddb_next':
./bsddbmodule.c:531: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_previous':
./bsddbmodule.c:536: `R_PREV' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_first':
./bsddbmodule.c:541: `R_FIRST' undeclared (first use in
this function)
./bsddbmodule.c: In function `bsddb_last':
./bsddbmodule.c:546: `R_LAST' undeclared (first use in
this function)
make[1]: *** [bsddbmodule.o] Error 1

./bsddbmodule.c:236: `R_NEXT' undeclared (first use in
this function)
./bsddbmodule.c:229: warning: `status' might be used
uninitialized in this function
./bsddbmodule.c: In function `bsddb_subscript':
./bsddbmodule.c:265: warning: passing arg 2 of pointer
to function from incompat                             
ible pointer type
./bsddbmodule.c:265: too few arguments to function
./bsddbmodule.c: In function `bsddb_ass_sub':



Voila...
what can I do ?

-pol-

----------------------------------------------------------------------

Comment By: Pol D. (blenderman)
Date: 2001-08-26 11:53

Message:
Logged In: YES 
user_id=288038

Ok, now it works if I use ./configure --without-libdb

Thanks a lot dude.



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-26 08:37

Message:
Logged In: YES 
user_id=31392

Two weeks without any comment from the anonymous submittor..

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-11 07:13

Message:
Logged In: YES 
user_id=21627

Try configuring with --without-libdb. Please report 
whether this helps.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450013&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 03:37:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 26 Aug 2001 19:37:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-455648 ] getpass.getpass() freezes windows client
Message-ID: <E15bCH3-0002Pj-00@usw-sf-web3.sourceforge.net>

Bugs item #455648, was opened at 2001-08-26 19:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470

Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getpass.getpass() freezes windows client

Initial Comment:
When getpass.getpass() is called from IDLE 0.8 (bundled with python 2.1.1), IDLE freezes (under windows 2000).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 09:15:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 01:15:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-455694 ] bug in list append, or list multiply?
Message-ID: <E15bHYX-00076h-00@usw-sf-web2.sourceforge.net>

Bugs item #455694, was opened at 2001-08-27 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in list append, or list multiply?

Initial Comment:
Python 2.1.1 (Windows NT 4)

>>> x=6*[[]]
>>> x
[[], [], [], [], [], []]
>>> x[3].append(7)
>>> x
[[7], [7], [7], [7], [7], [7]]

But, I was expecting:

[[], [], [], [7], [], []]

So I then tried this:

>>> x=[[],[],[],[],[],[]] # instead of x=6*[[]]
>>> x[3].append(7)
>>> x
[[], [], [], [7], [], []]

And it worked.

----

I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list?  But, if so, 
the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise:

s * n , n * s yields n _copies_ of s concatenated

Anyway, I'm confused.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 15:25:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 07:25:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-455775 ] float parsing discrepancy
Message-ID: <E15bNK8-0003bj-00@usw-sf-web2.sourceforge.net>

Bugs item #455775, was opened at 2001-08-27 07:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: float parsing discrepancy

Initial Comment:
Typing "3e" or "3e-" or "3e+" to the >>> prompt
or passing them to eval all return 3, which is
reasonable.

Passing any of these strings to float() throws
a value error exception.

What's the deal?

I think float() and the parser should accept the
same set of strings representing floats.  My 
preference (at least for what I'm currently doing)
is to update float() to act like eval rather than
the other way around, but either way is consistent.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 15:28:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 07:28:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-453728 ] Tutorial: string lits & cont. lines
Message-ID: <E15bNNZ-0003fH-00@usw-sf-web2.sourceforge.net>

Bugs item #453728, was opened at 2001-08-21 06:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453728&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Tutorial: string lits & cont. lines

Initial Comment:
The text on string literals and continuation lines
(esp. the example) assumes a good understanding of how
string literals and continuation lines work in C; this
needs to be clarified programmers with no experience in
C-like languages.

(Based on a comment sent to python-docs.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-27 07:28

Message:
Logged In: NO 

I don't remember what the tutorial said but cont. lines
work differently in python than C and I don't see the
reason.  For example it would be nice to split integer
literals, like:

a=123\
456\
78L

If the number is large (100's of digits) it's nice to be
able to split it across several lines.  Of course one could
enter it as a string split across several lines, but that
makes the .pyc file larger since the strings will appear in
it rather than the marshalled long int.
(This example is from a comp.lang.python discussion).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453728&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 16:12:19 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 08:12:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-455438 ] C API version mismatch for strop
Message-ID: <E15bO3n-0002sa-00@usw-sf-web1.sourceforge.net>

Bugs item #455438, was opened at 2001-08-25 22:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Jack Jansen (jackjansen)
Summary: C API version mismatch for strop

Initial Comment:
On starting the Python 2.2a2 interpreter from the command line in Mac OS X, I get the following error message:

/usr/local/lib/python2.2/string.py:381: RuntimeWarning: Python C API version mismatch for module strop: This Python has API version 1011, module strop has version 1010.
  from strop import maketrans, lowercase, uppercase, whitespace


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2001-08-27 08:12

Message:
Logged In: YES 
user_id=45365

I tried to repeat this, but it works for me. My gues is that
there is somehow an older
version of strop.so on sys.path (through PYTHONPATH?). You
can check this with "python -v".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455438&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 17:07:34 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 09:07:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-455775 ] float parsing discrepancy
Message-ID: <E15bOvG-00056u-00@usw-sf-web2.sourceforge.net>

Bugs item #455775, was opened at 2001-08-27 07:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: float parsing discrepancy

Initial Comment:
Typing "3e" or "3e-" or "3e+" to the >>> prompt
or passing them to eval all return 3, which is
reasonable.

Passing any of these strings to float() throws
a value error exception.

What's the deal?

I think float() and the parser should accept the
same set of strings representing floats.  My 
preference (at least for what I'm currently doing)
is to update float() to act like eval rather than
the other way around, but either way is consistent.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-27 09:07

Message:
Logged In: YES 
user_id=6380

Actually, it's a lexer bug that "3e", "3e-" and "3e+" are accepted.

We'll fix the lexer, thank you!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 20:20:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 12:20:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-455775 ] float parsing discrepancy
Message-ID: <E15bRw7-0007Qn-00@usw-sf-web3.sourceforge.net>

Bugs item #455775, was opened at 2001-08-27 07:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470

>Category: Parser/Compiler
>Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: float parsing discrepancy

Initial Comment:
Typing "3e" or "3e-" or "3e+" to the >>> prompt
or passing them to eval all return 3, which is
reasonable.

Passing any of these strings to float() throws
a value error exception.

What's the deal?

I think float() and the parser should accept the
same set of strings representing floats.  My 
preference (at least for what I'm currently doing)
is to update float() to act like eval rather than
the other way around, but either way is consistent.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-27 12:20

Message:
Logged In: YES 
user_id=31435

Exponents must contain a digit, as of

Lib/test/test_compile.py; new revision: 1.7
Parser/tokenizer.c; new revision: 2.52

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-27 09:07

Message:
Logged In: YES 
user_id=6380

Actually, it's a lexer bug that "3e", "3e-" and "3e+" are accepted.

We'll fix the lexer, thank you!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455775&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 22:25:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 14:25:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-455694 ] bug in list append, or list multiply?
Message-ID: <E15bTsk-0000kx-00@usw-sf-web1.sourceforge.net>

Bugs item #455694, was opened at 2001-08-27 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470

>Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug in list append, or list multiply?

Initial Comment:
Python 2.1.1 (Windows NT 4)

>>> x=6*[[]]
>>> x
[[], [], [], [], [], []]
>>> x[3].append(7)
>>> x
[[7], [7], [7], [7], [7], [7]]

But, I was expecting:

[[], [], [], [7], [], []]

So I then tried this:

>>> x=[[],[],[],[],[],[]] # instead of x=6*[[]]
>>> x[3].append(7)
>>> x
[[], [], [], [7], [], []]

And it worked.

----

I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list?  But, if so, 
the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise:

s * n , n * s yields n _copies_ of s concatenated

Anyway, I'm confused.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-27 14:25

Message:
Logged In: YES 
user_id=31435

Changed to Doc and reassigned to Fred.  The docs may be 
clearer if they said "n shallow copies" instead of "n 
copies".

>>> s = [[]]
>>> from copy import copy
>>> x = copy(s) + copy(s) + copy(s)
>>> x
[[], [], []]
>>> x[1].append(7)
>>> x
[[7], [7], [7]]
>>>

That is, "s*n is n copies of s concatenated" is correct, 
but only if you have shallow copies in mind.

Anonymous, the effect you *want* can be gotten via

x = []
for i in range(6):
    x.append([])

or, in Python 2.0+ via

x = [[] for i in range(6)]

Doing

[O] * n

creates a list with n repetitions of O, i.e. exactly the 
same object n times, the same as [O, O, O, ...].  In

[[], []]

you create two distinct empty lists, but in

temp = []
[temp, temp]

you get a single empty list twice.  Same thing for

[[]] * n

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470


From noreply@sourceforge.net  Mon Aug 27 23:20:07 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 15:20:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-455537 ] module search in import.c
Message-ID: <E15bUjn-0001TA-00@usw-sf-web3.sourceforge.net>

Bugs item #455537, was opened at 2001-08-26 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: module search in import.c

Initial Comment:
I'm porting 2.1.1 to QNX6 and got the situation that the module 'os' could not
be be found with 'import os'

After some hacking with DDD .. I found out that the pathes used by the search
algorithm of import.c has nothing to do with the directory structure of the UNIX
distribution of Python 2.1.1 =:-/

I have installed Python in the root directory and set PYTHONHOME/PYTHONPATH to
/Python-2.1.1 -> the path to he library modules is then

                     -> /Python-2.1.1/Lib   OK ... that's not a clean place for UNIX freaks :)

The search algorithm of import.c is using the following search path sequence:

  "os.so"   -> I don't know why it should make sense to open
               a shared object with fopen ??
  "osmodule.so"
  "os.py"
  "os.pyc"

  "/Python-2.1.1/os.so" ... os.pyc

  "/Python-2.1.1/lib/python2.1/os.so" ... os.pyc
                ^^^^^^^^^^^^^^^ who got the idea that this is part of the 
                                                  UNIX tar.gz distribution ??

Also ... there are similar problems with the binaries installed by 'make install' ...

Armin

a-steinhoff@web.de

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-27 15:20

Message:
Logged In: YES 
user_id=31392

I'm not sure what the complaint is.  The man page for Python
is quite clear about what PYTHONHOME means:

Change the location of the standard Python libraries.  By
default, the
libraries are searched in ${prefix}/lib/python<version> and
${exec_prefix}/lib/python<version>, where ${prefix} and
${exec_prefix}
are installation-dependent directories, both defaulting to
\fI/usr/local\fP.  When $PYTHONHOME is set to a single
directory, its value
replaces both ${prefix} and ${exec_prefix}.  To specify
different values
for these, set $PYTHONHOME to ${prefix}:${exec_prefix}.

It sounds like Python is doing exactly what it is documented
to do.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 04:59:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 20:59:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-456005 ] PyArg_ParseTuple failure in Python 2.2s2
Message-ID: <E15ba2A-0005pD-00@usw-sf-web3.sourceforge.net>

Bugs item #456005, was opened at 2001-08-27 20:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTuple failure in Python 2.2s2

Initial Comment:
The following code fails with size being set to
135270484 instead of being left at zero when no
arguements are passed.  This worked in Python 2.1.1.

    ...
    int         fd, cur, end, size, remaining = 0;

    if (!PgLargeObject_check((PyObject *)self, 
PGRES_LO_OPENED|PGRES_LO_READ))
        return (PyObject *)NULL;

    if (!PyArg_ParseTuple(args,"|i:read", &size))
        return (PyObject *)NULL;
    ...

At this point, when the method is called with no
arguments, size is nolonger zero!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 06:10:11 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 22:10:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-456005 ] PyArg_ParseTuple failure in Python 2.2s2
Message-ID: <E15bb8d-0007qI-00@usw-sf-web1.sourceforge.net>

Bugs item #456005, was opened at 2001-08-27 20:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTuple failure in Python 2.2s2

Initial Comment:
The following code fails with size being set to
135270484 instead of being left at zero when no
arguements are passed.  This worked in Python 2.1.1.

    ...
    int         fd, cur, end, size, remaining = 0;

    if (!PgLargeObject_check((PyObject *)self, 
PGRES_LO_OPENED|PGRES_LO_READ))
        return (PyObject *)NULL;

    if (!PyArg_ParseTuple(args,"|i:read", &size))
        return (PyObject *)NULL;
    ...

At this point, when the method is called with no
arguments, size is nolonger zero!

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-27 22:10

Message:
Logged In: YES 
user_id=31435

Why do you believe "size" should be 0?  The code snippet 
you showed set "remaining" to 0, but 
left "fd", "cur", "end" and "size" as uninitialized stack 
trash (which could be anything at all, depending on 
whatever junk is sitting in memory at the time).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 06:56:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 22:56:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-456024 ] event synchronization
Message-ID: <E15bbr3-0008VL-00@usw-sf-web1.sourceforge.net>

Bugs item #456024, was opened at 2001-08-27 22:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456024&group_id=5470

Category: Threads
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: event synchronization

Initial Comment:
It would be nice if the set and clear operations
on Event objects atomically returned the old state of
the internal flag:

  old_state = event.set()
  if old_state: nevermind()
  else: do_stuff ()

sets the flag to true and returns true if the flag
was already set, otherwise returns false.

This avoids the obvious race condition in
  if event.isSet(): nevermind()
  else: 
     event.set()
     do_stuff()

Maybe there's a way to accomplish this with
Semaphore objects (I haven't figured this thread
stuff out yet) but the event interface is more
natural for some purposes (i.e. the event represents
a lock on a resource).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456024&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 06:58:13 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 27 Aug 2001 22:58:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests
Message-ID: <E15bbt7-0007oF-00@usw-sf-web2.sourceforge.net>

Bugs item #451607, was opened at 2001-08-16 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Martin v. Lіwis (loewis)
Summary: SSL support in socket module needs tests

Initial Comment:
SSL support in the socket module should have a
regression test, either in test_socket.py or in a
separate test_ssl.py file.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-27 22:58

Message:
Logged In: NO 

I may be able to help with this.  I'm fairly familiar with
SSL in general, though not about the socket module.
What's needed?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 14:53:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 06:53:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-451607 ] SSL support in socket module needs tests
Message-ID: <E15bjJH-0005gk-00@usw-sf-web2.sourceforge.net>

Bugs item #451607, was opened at 2001-08-16 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Martin v. Lіwis (loewis)
Summary: SSL support in socket module needs tests

Initial Comment:
SSL support in the socket module should have a
regression test, either in test_socket.py or in a
separate test_ssl.py file.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-28 06:53

Message:
Logged In: YES 
user_id=12800

There is currently an extremely minimal test in
test_socket_ssl.py, but it is fairly bogus because it
requires an outside network connection.  The only test there
just tries to hit https://sf.net.

Ideally, there would be a set of regression tests that only
required local resources.  I.e. it would set up a local SSL
server, then do connects to it to test the various SSL
features in socket module.

Take a look at test_socket_ssl.py in the 2.2 cvs and see if
you can improve matters.  From what I understand, the tricky
part is generating all the necessary certificates, etc.

Also, if you intend to work on this, please log in to SF to
continue this dialog so we know who we're talking to! :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-27 22:58

Message:
Logged In: NO 

I may be able to help with this.  I'm fairly familiar with
SSL in general, though not about the socket module.
What's needed?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 15:56:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 07:56:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-455694 ] bug in list append, or list multiply?
Message-ID: <E15bkIP-0006dB-00@usw-sf-web2.sourceforge.net>

Bugs item #455694, was opened at 2001-08-27 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug in list append, or list multiply?

Initial Comment:
Python 2.1.1 (Windows NT 4)

>>> x=6*[[]]
>>> x
[[], [], [], [], [], []]
>>> x[3].append(7)
>>> x
[[7], [7], [7], [7], [7], [7]]

But, I was expecting:

[[], [], [], [7], [], []]

So I then tried this:

>>> x=[[],[],[],[],[],[]] # instead of x=6*[[]]
>>> x[3].append(7)
>>> x
[[], [], [], [7], [], []]

And it worked.

----

I imagine what is happening is that 6*[[]] creates 6 pointers to the same empty list?  But, if so, 
the python docs (http://www.python.org/doc/current/lib/typesseq.html) imply otherwise:

s * n , n * s yields n _copies_ of s concatenated

Anyway, I'm confused.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 07:56

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libstdtypes.tex revision 1.68.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-27 14:25

Message:
Logged In: YES 
user_id=31435

Changed to Doc and reassigned to Fred.  The docs may be 
clearer if they said "n shallow copies" instead of "n 
copies".

>>> s = [[]]
>>> from copy import copy
>>> x = copy(s) + copy(s) + copy(s)
>>> x
[[], [], []]
>>> x[1].append(7)
>>> x
[[7], [7], [7]]
>>>

That is, "s*n is n copies of s concatenated" is correct, 
but only if you have shallow copies in mind.

Anonymous, the effect you *want* can be gotten via

x = []
for i in range(6):
    x.append([])

or, in Python 2.0+ via

x = [[] for i in range(6)]

Doing

[O] * n

creates a list with n repetitions of O, i.e. exactly the 
same object n times, the same as [O, O, O, ...].  In

[[], []]

you create two distinct empty lists, but in

temp = []
[temp, temp]

you get a single empty list twice.  Same thing for

[[]] * n

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455694&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:27:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:27:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-451309 ] don't store traceback objects
Message-ID: <E15bkm2-00075n-00@usw-sf-web2.sourceforge.net>

Bugs item #451309, was opened at 2001-08-15 13:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Steve Purcell (purcell)
Summary: don't store traceback objects

Initial Comment:
A TestResult object stores the exceptions raised when
tests fail.  The only use of these stored tracebacks,
it seems, is to print a stack trace when the test run's
report is generated.

The traceback objects, however, keep pointers to a bunch
of objects that might otherwise be garbage collected. 
I ran into this on Windows, where the traceback was
keeping a file object alive.  Because the file object
was not collected, my tearDown() method could not
remove the file.

This patch changes unittest to generate the formatted
traceback immediately, so that it does not keep
tracebacks around any longer than needed.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-28 08:27

Message:
Logged In: YES 
user_id=31392

We had a water-cooler conversation about this issue.  It was
observed that keeping tracebacks alive until the end of a
test suite isn't very useful, because any number of objects
on the stack may be mutated during the subsequent run of the
program.  In general, a traceback object should be handed to
the debugger right away or processed in some other way.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-16 08:38

Message:
Logged In: YES 
user_id=31392

I think this feature is more trouble than it's worth. If
a testrunner wants to capture the actual exception, it
could easily override the addError or addFailure method to 
get the traceback then.

The cost of the feature is high, particularly since it is
not used by anyone.  The effects of preserving tracebacks
can be hard to discern, and I expect when it happens it
will cause a lot of confusion.  In my case, two experienced
Python programmers, who are novices with unittest, spent
several hours trying to figure out what went wrong.

I don't think updating the docs will be particularly
helpful, because this situation is somewhat unusual and
the current behavior so surprising.


----------------------------------------------------------------------

Comment By: Steve Purcell (purcell)
Date: 2001-08-15 14:46

Message:
Logged In: YES 
user_id=21477

Hi Jeremy,

This behaviour is actually known and intentional; the 
dangers are documented as a caveat in the PyUnit docs. The 
intention was that a test runner (GUI or otherwise) could 
potentially make the traceback available for inspection 
when a test fails, to aid in debugging.

In your particular case, relying on GC to close the file 
might have caused problems with following code even if 
PyUnit didn't store the traceback.

Overall I'd prefer to keep storing the tracebacks, 
especially since they only get stored when tests fail. It 
would be worth me adding a note about GC interaction to 
the docs, though.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451309&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:29:46 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:29:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-440725 ] setup.py does not properly build bsddb
Message-ID: <E15bkoE-0001tz-00@usw-sf-web1.sourceforge.net>

Bugs item #440725, was opened at 2001-07-12 09:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: setup.py does not properly build bsddb

Initial Comment:
On my Mandrake system, if the db2-devel RPM is
installed it will compile and link bsddb.o and
bsddb.so,
but importing bsddb fails because the .so wasn't
linked with -ldb2, so the dbopen symbol isn't defined.

The attached context diff solves the problem for me.
Note that it's possible that any or all of libdb3,
libdb2,
or libdb1 are installed.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-28 08:29

Message:
Logged In: YES 
user_id=44345

I'm closing this.  I have not heard a peep from anyone
about this change.  It can always be reopened if there turns
out to be a problem down the road to 2.2final.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-20 21:24

Message:
Logged In: YES 
user_id=44345

okay, Guido said, "go ahead", so I just checked in
setup.py 1.51 with my libdb finding patch.  I've
assigned this patch to myself.  Please feel free
to comment with or without changes to setup.py...


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2001-07-19 02:54

Message:
Logged In: YES 
user_id=34209

I'm wary of submitting this without a release candidate
before-hand... Consider it postponed for 2.1-maint, unless
we have another release candidate. It's still a good idea
for 2.2, IMHO, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=440725&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:33:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:33:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-453706 ] sgmllib exception behaviour: policy?
Message-ID: <E15bksJ-0007BM-00@usw-sf-web2.sourceforge.net>

Bugs item #453706, was opened at 2001-08-21 05:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470

Category: Python Library
>Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib exception behaviour: policy?

Initial Comment:
the standard python htmlparser produces an exception
from sgmllib while parsing this contruction:

<!spacer type="block" height="25">

in the body of an html file. IДm not sure if this is a
regular HTML Tag, but when netscape renders the page,
it seems to ignore it.

The problem is now, that sgmllib produces an uncaught
exception, and i donДt know how to handle this
exception really intelligent by my program. I like to
have a HTLMParser that never crashes, even if he
sometimes produces not exactly output.

What does the developer team think for that? is this
unimportant for the rest of the world or have i found a
bug that should be fixed? if not, can you give me some
suggestions how to work around this bug in my special
case. 

thanks

Michael

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:34:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:34:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-453515 ] filecmp.dircmp case sensitivity bug
Message-ID: <E15bktA-0007CE-00@usw-sf-web2.sourceforge.net>

Bugs item #453515, was opened at 2001-08-20 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Rik Kabel (ving)
>Assigned to: Paul Prescod (prescod)
Summary: filecmp.dircmp case sensitivity bug

Initial Comment:
(warning: python newbie submission)

Platforms: W2K w/Activestate 2.1.1 (same library source found in 2.0 and 2.11 on NetBSD).

filecmp.dircmp performs incorrect filename comparisons when building lists of common and 
directory-unique files. In particular, it sets a dictionary key to the filename (and value to 1) for 
each file in the right-hand tree, and looks for matching names (has_key). This fails on 
case-insensitive platforms when the names are equivalent except for case.

A simple workaround would be to use os.path.normcase() around the filenames before storing and 
comparing, but this is not case-preserving. Case preservation is to be preferred.

A case-preserving workaround might use os.path.normcase() for the dictionary entry keys, but 
store the unchanged filename as the value, and use that value when constructing the list from the 
dictionary.

-- 
Rik      creating tomorrow's legacy systems, today


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-28 08:34

Message:
Logged In: YES 
user_id=31392

Can you look at this, Paul?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453515&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:35:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:35:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-451636 ] linuxaudiodev caused machine hangup
Message-ID: <E15bku8-0007Dp-00@usw-sf-web2.sourceforge.net>

Bugs item #451636, was opened at 2001-08-16 10:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
>Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: linuxaudiodev caused machine hangup

Initial Comment:
OS and Python versions:
Linux turb 2.2.17-8enterprise #1 SMP Fri Nov 17
16:02:20 EST 2000 i686 unknown

Python 2.1.1 (#1, Aug 15 2001, 16:39:55) 
[GCC 2.96 20000731 (Red Hat Linux 7.0)] on linux2

In following the standard procedure:

./configure
make
make test

our RedHat machine locked up when testing
linuxaudiodev.

The speaker on the machine was uttering nonsense
repeatedly. We had to reboot the machine and run fsck
to clear things up.

Thanks,

Gerry Wiener
National Center for Atmospheric Research
gerry@ucar.edu



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 13:16

Message:
Logged In: NO 

I would look into this further, but unfortunately (or
fortunately depending on your point of view) the machine in
question is being used operationally for turbulence
forecasting. We're using Python to glue the system together.
If the machine is down for routine maintenance, I'll check
into this problem.

Strangely enough, there's at least one person one reads
README files :-)

Gerry Wiener
gerry@ucar.edu

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-16 12:52

Message:
Logged In: YES 
user_id=6380

It might be more productive to find out why it didn't work
as advertised.  I've only heard reports of one kind of
failure for the linuxaudiodev module: with some
hardware/driver combinations it plays the first second or so
of the sound file and then stops with an exception. The
failure you are experiencing is different. Until we've
figured out what went wrong on your box, I see no reason to
do either of the things you propose. (Besides, nobody reads
README files. :-)

As a workaround, su root followed by chmod 0 /dev/audio does
wonders. :-)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:37

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-16 12:35

Message:
Logged In: NO 

Our version of Red Hat was factory installed at Dell on a
Dell PC. Admittedly there may be a problem with how the OS
was configured or with the sound card. Still, I would think
"make test" would be more user friendly if:

1. Testing linuxaudiodev be optional -- perhaps make
test_optional. 

2. Warnings be provided with regard to make test in the
README file, i.e., some users have experienced system
crashes when using make test owing to problems with
linuxaudiodev.

Note that we typically are not interested in the use of the
sound cards on our systems -- our systems are generally used
for running scientific algorithms.  

Gerry Wiener
gerry@ucar.edu




----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-08-16 11:33

Message:
Logged In: YES 
user_id=21627

Why do you think this is a Python bug? Python was acessing 
the hardware of your computer through the official 
interfaces that your operating system offers for that. 
Unless you can demonstrate that it did wrong doing so, 
I'll assume that either your machine is misconfigured, or 
the sound drivers of your system are broken. In that case, 
you best disable sound support, since it won't work 
anyways.

Since the specific test works without problems on any 
other Linux system, I propose to close this bug as "Works 
for me".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451636&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:48:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:48:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-456175 ] add dictionary "tokens" to token.py
Message-ID: <E15bl6J-0002Dl-00@usw-sf-web1.sourceforge.net>

Bugs item #456175, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:48:48 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:48:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-456176 ] add dictionary "tokens" to token.py
Message-ID: <E15bl6e-0002E3-00@usw-sf-web1.sourceforge.net>

Bugs item #456176, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:51:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:51:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-453706 ] sgmllib exception behaviour: policy?
Message-ID: <E15bl9S-0002Hk-00@usw-sf-web1.sourceforge.net>

Bugs item #453706, was opened at 2001-08-21 05:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib exception behaviour: policy?

Initial Comment:
the standard python htmlparser produces an exception
from sgmllib while parsing this contruction:

<!spacer type="block" height="25">

in the body of an html file. IДm not sure if this is a
regular HTML Tag, but when netscape renders the page,
it seems to ignore it.

The problem is now, that sgmllib produces an uncaught
exception, and i donДt know how to handle this
exception really intelligent by my program. I like to
have a HTLMParser that never crashes, even if he
sometimes produces not exactly output.

What does the developer team think for that? is this
unimportant for the rest of the world or have i found a
bug that should be fixed? if not, can you give me some
suggestions how to work around this bug in my special
case. 

thanks

Michael

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 08:51

Message:
Logged In: YES 
user_id=3066

This is not legal HTML or SGML (or XHTML, or any other
acronym-of-the-week).  The <! syntax introduces a
"declaration", of which only two forms should appear in an
HTML document:  <!DOCTYPE, which may appear at the start of
the document, and <!--, which introduces a comment (yeah, I
know, that doesn't sound like a declaration to me either).

(At one point there was a proposed <spacer> element that
would have looked like that, but without the "!".  I suspect
someone had played with that and tried to comment it out,
which they botched.)

The "right thing" is to raise an exception due to illegal
syntax.  The problem is that you weren't seeing the
exception before (what was the latest released version you
were using where you did not get the exception?).

I'll look into this a bit and think about it.  The
sgmllib/htmllib parsers have traditionally been way too
lenient, so we may need to restore the old behavior.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 16:52:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 08:52:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-456176 ] add dictionary "tokens" to token.py
Message-ID: <E15blAF-00073Y-00@usw-sf-web3.sourceforge.net>

Bugs item #456176, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
>Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

>Comment By: Grant Griffin (dspguru)
Date: 2001-08-28 08:52

Message:
Logged In: YES 
user_id=70844

Sorry!  This is a duplicate of the previous one.  Please 
delete it.

darn-them-browsers-ly y'rs

=g2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 17:42:35 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 09:42:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-456175 ] add dictionary "tokens" to token.py
Message-ID: <E15blwh-0008DU-00@usw-sf-web2.sourceforge.net>

Bugs item #456175, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
>Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2001-08-28 09:42

Message:
Logged In: YES 
user_id=44345

I encountered the same problem when programming with Gtk.
Gtk defines an enormous number of enumeration types.  While
I could define one or more dictionaries to map enumerations
back to names as you suggested, I chose a somewhat different
approach.  I defined a ConstantMap class whose instances
create a new dictionary containing all non-instance/non-
class objects created since the last ConstantMap class was
instantiated.

class ConstantMap:
    markdict = {}

    def __init__(self):
        """add new global symbols to instance's name map"""
        self.names = {}
        import types
        for key,val in globals().items():
            if (not self.markdict.has_key(key) and
                key[:2] != "__" and
                type(val) not in [types.InstanceType,
types.ClassType]):
                self.names[val] = key
        self.markdict.update(globals())

    def __call__(self, key):
        """return a name mapping"""
        return self.names[key]

    def mark(self):
        """checkpoint current globals"""

I then instantiate ConstantMap after each block of
enumeration constants are defined like so:

# GdkPropertyState's
PROPERTY_NEW_VALUE = 0
PROPERTY_DELETE    = 1
GdkPropertyState = ConstantMap()

# GdkWindowState's
WINDOW_STATE_WITHDRAWN = 1 << 0
WINDOW_STATE_ICONIFIED = 1 << 1
WINDOW_STATE_MAXIMIZED = 1 << 2
WINDOW_STATE_STICKY    = 1 << 3
GdkWindowState = ConstantMap()

# GdkSettingAction's
SETTING_ACTION_NEW     = 0
SETTING_ACTION_CHANGED = 1
SETTING_ACTION_DELETED = 2
GdkSettingAction = ConstantMap()

# GdkScrollDirection's
SCROLL_UP    = 0
SCROLL_DOWN  = 1
SCROLL_LEFT  = 2
SCROLL_RIGHT = 3
GdkScrollDirection = ConstantMap()

This is more than you're asking for in this case, but may
be a somewhat more general foundation for a problem that
bugs many people debugging code that uses imported
constants.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 17:51:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 09:51:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-456005 ] PyArg_ParseTuple failure in Python 2.2s2
Message-ID: <E15bm5H-0008Le-00@usw-sf-web2.sourceforge.net>

Bugs item #456005, was opened at 2001-08-27 20:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Billy G. Allie (ballie01)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyArg_ParseTuple failure in Python 2.2s2

Initial Comment:
The following code fails with size being set to
135270484 instead of being left at zero when no
arguements are passed.  This worked in Python 2.1.1.

    ...
    int         fd, cur, end, size, remaining = 0;

    if (!PgLargeObject_check((PyObject *)self, 
PGRES_LO_OPENED|PGRES_LO_READ))
        return (PyObject *)NULL;

    if (!PyArg_ParseTuple(args,"|i:read", &size))
        return (PyObject *)NULL;
    ...

At this point, when the method is called with no
arguments, size is nolonger zero!

----------------------------------------------------------------------

>Comment By: Billy G. Allie (ballie01)
Date: 2001-08-28 09:51

Message:
Logged In: YES 
user_id=8500

1.  remaining was just added (inserted in front of the =). 
taking over the assignment.
2.  The code working with Python2.1 (luck, something with 
2.1, whatever.  It worked every time I tried it.)
3.  The brain ignoring what is there for whiat it thought 
was there.

Close this bug report.  It wasn't with Python 2.2.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-27 22:10

Message:
Logged In: YES 
user_id=31435

Why do you believe "size" should be 0?  The code snippet 
you showed set "remaining" to 0, but 
left "fd", "cur", "end" and "size" as uninitialized stack 
trash (which could be anything at all, depending on 
whatever junk is sitting in memory at the time).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 18:44:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 10:44:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-453706 ] sgmllib exception behaviour: policy?
Message-ID: <E15bmv1-0004EW-00@usw-sf-web1.sourceforge.net>

Bugs item #453706, was opened at 2001-08-21 05:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib exception behaviour: policy?

Initial Comment:
the standard python htmlparser produces an exception
from sgmllib while parsing this contruction:

<!spacer type="block" height="25">

in the body of an html file. IДm not sure if this is a
regular HTML Tag, but when netscape renders the page,
it seems to ignore it.

The problem is now, that sgmllib produces an uncaught
exception, and i donДt know how to handle this
exception really intelligent by my program. I like to
have a HTLMParser that never crashes, even if he
sometimes produces not exactly output.

What does the developer team think for that? is this
unimportant for the rest of the world or have i found a
bug that should be fixed? if not, can you give me some
suggestions how to work around this bug in my special
case. 

thanks

Michael

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 10:44

Message:
Logged In: YES 
user_id=3066

Python 2.1 and 2.1.1 both raised an exception in this case,
while Python 2.0.1 did not (it skipped over the markup).

I wish this had been caught before 2.1 was released!  The
fact that it has only now come up indicates that this is a
very unusual input (which I'd expect for HTML, but not so
much for SGML).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 08:51

Message:
Logged In: YES 
user_id=3066

This is not legal HTML or SGML (or XHTML, or any other
acronym-of-the-week).  The <! syntax introduces a
"declaration", of which only two forms should appear in an
HTML document:  <!DOCTYPE, which may appear at the start of
the document, and <!--, which introduces a comment (yeah, I
know, that doesn't sound like a declaration to me either).

(At one point there was a proposed <spacer> element that
would have looked like that, but without the "!".  I suspect
someone had played with that and tried to comment it out,
which they botched.)

The "right thing" is to raise an exception due to illegal
syntax.  The problem is that you weren't seeing the
exception before (what was the latest released version you
were using where you did not get the exception?).

I'll look into this a bit and think about it.  The
sgmllib/htmllib parsers have traditionally been way too
lenient, so we may need to restore the old behavior.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 18:56:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 10:56:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-456175 ] add dictionary "tokens" to token.py
Message-ID: <E15bn6R-0000p3-00@usw-sf-web2.sourceforge.net>

Bugs item #456175, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
>Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

>Comment By: Grant Griffin (dspguru)
Date: 2001-08-28 10:56

Message:
Logged In: YES 
user_id=70844

Thanks much, Skip.  That's not a bad idea, but here's what 
I ended up doing:

def token_names():
    import tokenize
    res = {}
    names = dir(tokenize)
    for name in names:
        attr = getattr(tokenize, name)
        if type(attr) is type(1):
            res[attr] = name
    return res

Instead of modifying token.py as I had suggested 
previously, perhaps something like the above could be added 
to tokenize.

- There isn't much code here, but it took me awhile to 
figure out how to include my own batteries <wink>.

- I learned the hard way that it's better to get these 
symbols from tokenize than token because tokenize adds 
the "COMMENT" token.)

thanks,

=g2

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-08-28 09:42

Message:
Logged In: YES 
user_id=44345

I encountered the same problem when programming with Gtk.
Gtk defines an enormous number of enumeration types.  While
I could define one or more dictionaries to map enumerations
back to names as you suggested, I chose a somewhat different
approach.  I defined a ConstantMap class whose instances
create a new dictionary containing all non-instance/non-
class objects created since the last ConstantMap class was
instantiated.

class ConstantMap:
    markdict = {}

    def __init__(self):
        """add new global symbols to instance's name map"""
        self.names = {}
        import types
        for key,val in globals().items():
            if (not self.markdict.has_key(key) and
                key[:2] != "__" and
                type(val) not in [types.InstanceType,
types.ClassType]):
                self.names[val] = key
        self.markdict.update(globals())

    def __call__(self, key):
        """return a name mapping"""
        return self.names[key]

    def mark(self):
        """checkpoint current globals"""

I then instantiate ConstantMap after each block of
enumeration constants are defined like so:

# GdkPropertyState's
PROPERTY_NEW_VALUE = 0
PROPERTY_DELETE    = 1
GdkPropertyState = ConstantMap()

# GdkWindowState's
WINDOW_STATE_WITHDRAWN = 1 << 0
WINDOW_STATE_ICONIFIED = 1 << 1
WINDOW_STATE_MAXIMIZED = 1 << 2
WINDOW_STATE_STICKY    = 1 << 3
GdkWindowState = ConstantMap()

# GdkSettingAction's
SETTING_ACTION_NEW     = 0
SETTING_ACTION_CHANGED = 1
SETTING_ACTION_DELETED = 2
GdkSettingAction = ConstantMap()

# GdkScrollDirection's
SCROLL_UP    = 0
SCROLL_DOWN  = 1
SCROLL_LEFT  = 2
SCROLL_RIGHT = 3
GdkScrollDirection = ConstantMap()

This is more than you're asking for in this case, but may
be a somewhat more general foundation for a problem that
bugs many people debugging code that uses imported
constants.

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456175&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 19:00:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 11:00:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-456222 ] LateX's author is not Donald Knuth
Message-ID: <E15bn9y-0000sv-00@usw-sf-web2.sourceforge.net>

Bugs item #456222, was opened at 2001-08-28 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456222&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Florent Rougon (frougon)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: LateX's author is not Donald Knuth

Initial Comment:
In the Python 2.1.1 documentation (precise URL:
http://www.python.org/doc/current/doc/node21.html), one
can read about LaTeX:

"This is a world-class typesetter by Donald Knuth"

This is not correct.

LaTeX is a big set of TeX macros (called a "format" in
TeX's terminology) written by Leslie Lamport. Donald
Knuth is the author of TeX, not of LaTeX.

Of course, LaTeX relies completely upon TeX.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456222&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 19:10:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 11:10:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-456222 ] LateX's author is not Donald Knuth
Message-ID: <E15bnJg-0000d5-00@usw-sf-web3.sourceforge.net>

Bugs item #456222, was opened at 2001-08-28 11:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456222&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Florent Rougon (frougon)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: LateX's author is not Donald Knuth

Initial Comment:
In the Python 2.1.1 documentation (precise URL:
http://www.python.org/doc/current/doc/node21.html), one
can read about LaTeX:

"This is a world-class typesetter by Donald Knuth"

This is not correct.

LaTeX is a big set of TeX macros (called a "format" in
TeX's terminology) written by Leslie Lamport. Donald
Knuth is the author of TeX, not of LaTeX.

Of course, LaTeX relies completely upon TeX.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 11:10

Message:
Logged In: YES 
user_id=3066

You're absolutely right!  That'll teach me to write these
things too quickly.  Fixed in Doc/doc/doc.tex revision 1.51.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456222&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 19:36:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 11:36:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-456005 ] PyArg_ParseTuple failure in Python 2.2s2
Message-ID: <E15bniv-000109-00@usw-sf-web3.sourceforge.net>

Bugs item #456005, was opened at 2001-08-27 20:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Billy G. Allie (ballie01)
>Assigned to: Tim Peters (tim_one)
Summary: PyArg_ParseTuple failure in Python 2.2s2

Initial Comment:
The following code fails with size being set to
135270484 instead of being left at zero when no
arguements are passed.  This worked in Python 2.1.1.

    ...
    int         fd, cur, end, size, remaining = 0;

    if (!PgLargeObject_check((PyObject *)self, 
PGRES_LO_OPENED|PGRES_LO_READ))
        return (PyObject *)NULL;

    if (!PyArg_ParseTuple(args,"|i:read", &size))
        return (PyObject *)NULL;
    ...

At this point, when the method is called with no
arguments, size is nolonger zero!

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-28 11:36

Message:
Logged In: YES 
user_id=31435

Closed as agreed.  An uninitialized-vrbl problem is quite 
likely to act the same way each time you run it, provided 
nothing changes (same box, same compiler, same compile 
options, same C library, same code).

----------------------------------------------------------------------

Comment By: Billy G. Allie (ballie01)
Date: 2001-08-28 09:51

Message:
Logged In: YES 
user_id=8500

1.  remaining was just added (inserted in front of the =). 
taking over the assignment.
2.  The code working with Python2.1 (luck, something with 
2.1, whatever.  It worked every time I tried it.)
3.  The brain ignoring what is there for whiat it thought 
was there.

Close this bug report.  It wasn't with Python 2.2.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-27 22:10

Message:
Logged In: YES 
user_id=31435

Why do you believe "size" should be 0?  The code snippet 
you showed set "remaining" to 0, but 
left "fd", "cur", "end" and "size" as uninitialized stack 
trash (which could be anything at all, depending on 
whatever junk is sitting in memory at the time).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456005&group_id=5470


From noreply@sourceforge.net  Tue Aug 28 20:35:00 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 12:35:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-456252 ] Python should never stomp on [u]intptr_t
Message-ID: <E15bodY-00064a-00@usw-sf-web1.sourceforge.net>

Bugs item #456252, was opened at 2001-08-28 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Python should never stomp on [u]intptr_t

Initial Comment:
Attached is from c.l.py.  Python should always use 
Py_uintptr_t (from pyport.h), and define a 
corresponding Py_intptr_t.  It should never presume to 
make up a definition for uintptr_t or intptr_t.  A 
quick glance suggests the problem is unique to 
Windows, so assigned it to me.

"""
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of 
Maciej Sobczak
Sent: Tuesday, August 28, 2001 3:52 AM
To: python-list@python.org
Subject: Header inconsistency?


Hi,

I'm trying to get my hands dirty with extensions and 
modules written in C/C++. I try to use SWIG.  When 
I've set up to compile the extension as a dynamic 
library, I've found that in file config.h that is 
shipped with Python distribution there are lines:

typedef long intptr_t;
typedef unsigned long uintptr_t;

whereas in some other files shipped with my compiler 
(indirectly included by my lib code) there are:

typedef int intptr_t;
typedef unsigned int uintptr_t;

The net result is that the compiler complains about 
different base types in type redefinitions. I've 
changed the config.h file to fit the rest and got my 
job done.

However, I've got a question:
Is this a problem? Or a bug? Should/Can I tinker with 
the files distributed with Python this way? Is this a 
known problem?

Few details:
I use ActiveState2.1.0 distribution and MSVC++ 
compiler on Win2000.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 03:56:59 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 19:56:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-456024 ] event synchronization
Message-ID: <E15bvXH-000811-00@usw-sf-web2.sourceforge.net>

Bugs item #456024, was opened at 2001-08-27 22:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456024&group_id=5470

Category: Threads
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: event synchronization

Initial Comment:
It would be nice if the set and clear operations
on Event objects atomically returned the old state of
the internal flag:

  old_state = event.set()
  if old_state: nevermind()
  else: do_stuff ()

sets the flag to true and returns true if the flag
was already set, otherwise returns false.

This avoids the obvious race condition in
  if event.isSet(): nevermind()
  else: 
     event.set()
     do_stuff()

Maybe there's a way to accomplish this with
Semaphore objects (I haven't figured this thread
stuff out yet) but the event interface is more
natural for some purposes (i.e. the event represents
a lock on a resource).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-28 19:56

Message:
Logged In: YES 
user_id=31435

I'm opposed to this.  Events are very feeble mechanisms, 
best reserved for dead-simple cases where an event is set 
once, is never cleared, and it doesn't matter if it's set 
multiple times (if you find yourself clearing an event, 
your code is likely wrong).  If you want a lock, 
threading.py already supplies two flavors:

if lock.acquire(0):
.   # we own the lock now
.   do_stuff()
.   lock.release()
else:
.   # the lock wasn't available
.   nevermind()

A non-blocking acquire can also be done with a Sempahore, 
but that's overkill unless the semaphore is counting a pool 
(more than one) of resources.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456024&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:19:49 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:19:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-456386 ] test_commands regression failure
Message-ID: <E15bwpR-0005wj-00@usw-sf-web1.sourceforge.net>

Bugs item #456386, was opened at 2001-08-28 21:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456386&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_commands regression failure

Initial Comment:
test_commands does not work on IRIX

It assumes the output of "ls /bin/ls" is a line
that starts with a '-'.  On IRIX that file is
a symbolic link, so the first character is an l.
This causes test_getstatus to fail.

>>> import commands
>>> commands.getstatus("/bin/ls")
'lrwxr-xr-x    1 root     sys           13 Feb 23  
1997 /bin/ls -> ../../sbin/ls'
>>> pat = r'''-..x..x..x   # It is executable.
...                   \s+\d+       # It has some 
number of links.
...                   \s+\w+\s+\w+ # It has a user and 
group, which may
...                                #     be named 
anything.
...                   [^/]*        # Skip the date.
...                   /bin/ls      # and end with the 
name of the file.
...                '''
>>> import re
>>> re.match(pat, commands.getstatus("/bin/ls"), 
re.VERBOSE)
>>>

Here's a context diff for a patch.  (I hate how narrow
this entry textbox is.)  Feel free to adjust the '#'s
so they all line up.

*** Lib/test/test_commands.py   2001/07/23 
04:08:01     1.1
--- Lib/test/test_commands.py   2001/08/29 04:18:36
***************
*** 32,38 ****
      def test_getstatus(self):
          # This pattern should match 'ls -ld /bin/ls' 
on any posix
          # system, however perversely configured.
!         pat = r'''-..x..x..x   # It is executable.
                    \s+\d+       # It has some number 
of links.
                    \s+\w+\s+\w+ # It has a user and 
group, which may
                                 #     be named 
anything.
--- 32,38 ----
      def test_getstatus(self):
          # This pattern should match 'ls -ld /bin/ls' 
on any posix
          # system, however perversely configured.
!         pat = r'''[l-]..x..x..x   # It is 
executable. (May be a symlink.)
                    \s+\d+       # It has some number 
of links.
                    \s+\w+\s+\w+ # It has a user and 
group, which may
                                 #     be named 
anything.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456386&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:26:53 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:26:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-456390 ] test_fpformat fails on IRIX
Message-ID: <E15bwwH-0000kZ-00@usw-sf-web2.sourceforge.net>

Bugs item #456390, was opened at 2001-08-28 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456390&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_fpformat fails on IRIX

Initial Comment:
Given it involves "-0" this failure is beyond my
floating point ken.  I also note the comment:

# Test the old and obsolescent fpformat module

so I'll put no more effort into understanding.  :)

This is on an old IRIX machine running 6.4,
which means it's at least 2 years out of date.


origin> ./python Lib/test/test_fpformat.py
test_basic_cases (__main__.FpformatTest) ... ok
test_failing_values (__main__.FpformatTest) ... ok
test_reasonable_values (__main__.FpformatTest) ... FAIL

=======================================================
===============
FAIL: test_reasonable_values (__main__.FpformatTest)
-------------------------------------------------------
---------------
Traceback (most recent call last):
  File "Lib/test/test_fpformat.py", line 51, in 
test_reasonable_values
    self.checkFix(realVal, d)
  File "Lib/test/test_fpformat.py", line 28, in 
checkFix
    self.assertEquals(result, expected)
  
File "/usr2/people/dalke/cvses/python/dist/src/Lib/unit
test.py", line 273, in fa
ilUnlessEqual
    raise self.failureException, (msg or '%s != %s' % 
(first, second))
AssertionError: -0 != 0
-------------------------------------------------------
---------------
Ran 3 tests in 0.009s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_fpformat.py", line 69, in ?
    run_unittest(FpformatTest)
  File "./Lib/test/test_support.py", line 159, in 
run_unittest
    raise TestFailed(str(err[1]))
test_support.TestFailed: -0 != 0


                           Andrew
                           dalke@dalkescientific.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456390&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:31:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:31:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-456391 ] unexpected test_largefile output
Message-ID: <E15bx0c-0000kw-00@usw-sf-web3.sourceforge.net>

Bugs item #456391, was opened at 2001-08-28 21:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456391&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: unexpected test_largefile output 

Initial Comment:
Running test_largefile produces this output:

test_largefile
@test exists: 0

The second line is unexpected.  It occurs because
at the end of test_largefile.py is

print >>sys.stderr, name, "exists:", os.path.exists
(name)

This makes it harder to understand the regression
test output and should likely be removed.

                          Andrew
                          dalke@dalkescientific.com


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456391&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:37:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:37:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-456393 ] missing test_locale output
Message-ID: <E15bx6f-0006E6-00@usw-sf-web1.sourceforge.net>

Bugs item #456393, was opened at 2001-08-28 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456393&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: missing test_locale output

Initial Comment:
When running the regression tests for the CVS
version of Python (under IRIX 6.4 - an old SGI
machine) I get:

test_locale
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_locale
*******************************************************
***************
Then ...
We expected (repr): ''
But instead we got: "'%f' % 1024 == '1024.000000' !
= '1,024.000000'"
test test_locale failed -- Writing: "'%f' % 1024 
== '1024.000000' != '1,024.000000
'", expected: ''

This appears to be because there is no file named
  Lib/test/output/test_locale

origin> ./python Lib/test/test_locale.py
'%f' % 1024 =? '1,024.000000' ... no
'%f' % 1024 == '1024.000000' != '1,024.000000'
'%f' % 102 =? '102.000000' ... yes
'%f' % -42 =? '-42.000000' ... yes
'%+f' % -42 =? '-42.000000' ... yes
'%20.f' % -42 =? '                 -42' ... yes
'%+10.f' % -4200 =? '    -4,200' ... no
'%+10.f' % -4200 == '     -4200' != '    -4,200'
'%-10.f' % 4200 =? '4,200     ' ... no
'%-10.f' % 4200 == '4200      ' != '4,200     '
origin> ls Lib/test/output/*loc*
ls: No match.
origin> ls Lib/test/output/*lo*
Lib/test/output/test_global   
Lib/test/output/test_longexp
origin>

                      Andrew
                      dalke@dalkescientific.com



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456393&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:42:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:42:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-456395 ] test_pty failure under IRIX
Message-ID: <E15bxBJ-0000wh-00@usw-sf-web2.sourceforge.net>

Bugs item #456395, was opened at 2001-08-28 21:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456395&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pty failure under IRIX

Initial Comment:
Under IRIX 6.4 (which is at least two years old)
I get the following regression failure in test_pty.
It appears newlines are converted to "\r\n".  I
don't know enough about ptys to suggest a solution.

test_pty
The actual stdout doesn't match the expected stdout.
This much did match (between asterisk lines):
*******************************************************
***************
test_pty
*******************************************************
***************
Then ...
We expected (repr): 'I wish to buy a fish 
license.\nFor my pet fish, Eric.\n'
But instead we got: 'I wish to buy a fish 
license.\r\nFor my pet fish, Eric.\n'
test test_pty failed -- Writing: 'I wish to buy a fish 
license.\r\nFor my pet fish
, Eric.\n', expected: 'I wish to buy a fish 
license.\nFor my pet fish, Eric.\n'

          Andrew
          dalke@dalkescientific.com


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456395&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 05:56:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 28 Aug 2001 21:56:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-456398 ] strange IRIX test_re/test_sre failure
Message-ID: <E15bxPH-00018d-00@usw-sf-web2.sourceforge.net>

Bugs item #456398, was opened at 2001-08-28 21:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: strange IRIX test_re/test_sre failure

Initial Comment:
The test_re and test_sre regression tests cause
a core dump with the CVS version of Python.  If
I run the file directly I don't get the core dump.

test_pyclbr
test_pyexpat
test test_pyexpat skipped --  No module named pyexpat
test_quopri
test_re
make: *** [test] Segmentation fault (core dumped)
./python -E -tt ./Lib/test/regrtest.py -l
^C
%
% ./python -E -tt ./Lib/test/test_re.py
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
Test engine limitations
maximum recursion limit exceeded
Running re_tests test suite
% 

This is under an IRIX 6.4 machine, which is
several years old.  Python is compiled with
gcc 2.95.2 but using the vendor's assembler.
The assembler is also out of date.  There were
known problems with in 1.5.2 where the optimizer
broke the pcre module.  So I recompiled _sre.c
with "-g".  That did not fix the problem.

Here's the stack trace from the core file.

>  0 mark_save(state = <no such address>, lo = <no 
such address>, hi = <no such ad
dress>) 
["/usr2/people/dalke/cvses/python/dist/src/./Modules/_s
re.c":280, 0x100a1e
2c]
   1 sre_match(state = 0x7fff1200, pattern = 
0x104ec55a, level = 1357) ["/usr2/peo
ple/dalke/cvses/python/dist/src/Modules/_sre.c":1053, 
0x100a44b4]
   2 sre_match(state = 0x7fff1200, pattern = 
0x104ec55a, level = 1356) ["/usr2/peo
ple/dalke/cvses/python/dist/src/Modules/_sre.c":1057, 
0x100a4504]

Guessing it's in the "recursion limit" test.

I don't know if the problem is in _sre.c or in
the IRIX libraries.  I don't have access to
a newer version of IRIX.

I tried to force the core dump to occur without
having to go through the whole regression suite.
That doesn't work, which is itself suspecious.

% ./python -E -tt ./Lib/test/regrtest.py -l test_re
test_re
1 test OK.
% ./python -E -tt ./Lib/test/regrtest.py -l test_array 
test_re
test_array
test_re
All 2 tests OK.
% ./python -E -tt ./Lib/test/regrtest.py -l test_array 
test_re test_re
test_array
test_re
test_re
All 3 tests OK.
%

I get the same failures with test_sre.

                Andrew
                dalke@dalkescientific.com



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456398&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 08:32:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 00:32:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-456420 ] no __methods__ for lists, strings etc.
Message-ID: <E15bzq3-0000Rs-00@usw-sf-web1.sourceforge.net>

Bugs item #456420, was opened at 2001-08-29 00:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Detlef Lannert (lannert)
Assigned to: Guido van Rossum (gvanrossum)
Summary: no __methods__ for lists, strings etc.

Initial Comment:
With Python 2.2a2+ from cvs, [].__methods__ fails with

AttributeError: 'list' object has no attribute
'__methods__'

Same for a string or a dictionary.

The Library Reference section on "Special Attributes"
(2.1.9 here) still recommends [].__methods__ for
finding out about an object's methods.

dir([]) returns [] and doesn't list the attributes
either.

OK, I can use [].__class__.__dict__.keys() -- but it's
not very intuitive ...

  Detlef


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 11:21:20 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 03:21:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-453706 ] sgmllib exception behaviour: policy?
Message-ID: <E15c2TI-0005M8-00@usw-sf-web2.sourceforge.net>

Bugs item #453706, was opened at 2001-08-21 05:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sgmllib exception behaviour: policy?

Initial Comment:
the standard python htmlparser produces an exception
from sgmllib while parsing this contruction:

<!spacer type="block" height="25">

in the body of an html file. IДm not sure if this is a
regular HTML Tag, but when netscape renders the page,
it seems to ignore it.

The problem is now, that sgmllib produces an uncaught
exception, and i donДt know how to handle this
exception really intelligent by my program. I like to
have a HTLMParser that never crashes, even if he
sometimes produces not exactly output.

What does the developer team think for that? is this
unimportant for the rest of the world or have i found a
bug that should be fixed? if not, can you give me some
suggestions how to work around this bug in my special
case. 

thanks

Michael

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-29 03:21

Message:
Logged In: NO 

I use Python 2.1.1 as you expected and I didnДt try it with
any earlier version, I began to use it only 2 months ago. 
By the way, the coolest programming language IДve ever seen.
Good work, guys!


When the desired behaviour for sgmllib is to throw an
exception when parsing such an unknown tag, what is the
preferred way to catch it?
I liked to use sgmllib as a kind of black box, and IДm sure
this is possible in some way. Is there such a way and I
donДt see it or isnДt it existing?
In the current implementation of my program, I had to
overwrite the function parse_declaration. This is what I
would call in internal function of sgmllib, and maybe with
the next version of sgmllib, the internal structure changes
a bit and my programm wonДt run anymore. And all the
advantages of OO Programming are just blown away.

a kind of this would be cool:

data = "<tag>bla</tag>foo bla..."

while true:
   try:
      myParser.feed(data)
      break
   except SGMLCatcheableParseError:
      exc_value = sys.exc_info()[1]
      data = data[exc_value:]
      continue

you know what I mean? The code snippet is not very nice, but
it should explain the problem..
When sgmllib throws an exception on ParseErrors there should
be a way to instruct the Parser Object to ommit the tag an
go further.

Michael



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 10:44

Message:
Logged In: YES 
user_id=3066

Python 2.1 and 2.1.1 both raised an exception in this case,
while Python 2.0.1 did not (it skipped over the markup).

I wish this had been caught before 2.1 was released!  The
fact that it has only now come up indicates that this is a
very unusual input (which I'd expect for HTML, but not so
much for SGML).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-28 08:51

Message:
Logged In: YES 
user_id=3066

This is not legal HTML or SGML (or XHTML, or any other
acronym-of-the-week).  The <! syntax introduces a
"declaration", of which only two forms should appear in an
HTML document:  <!DOCTYPE, which may appear at the start of
the document, and <!--, which introduces a comment (yeah, I
know, that doesn't sound like a declaration to me either).

(At one point there was a proposed <spacer> element that
would have looked like that, but without the "!".  I suspect
someone had played with that and tried to comment it out,
which they botched.)

The "right thing" is to raise an exception due to illegal
syntax.  The problem is that you weren't seeing the
exception before (what was the latest released version you
were using where you did not get the exception?).

I'll look into this a bit and think about it.  The
sgmllib/htmllib parsers have traditionally been way too
lenient, so we may need to restore the old behavior.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453706&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 14:09:05 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 06:09:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-456504 ] Memory leak in PyString_FromString
Message-ID: <E15c55d-0005i8-00@usw-sf-web1.sourceforge.net>

Bugs item #456504, was opened at 2001-08-29 06:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456504&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in PyString_FromString

Initial Comment:
Purify (on WinNT) reports a memory leak:

Memory leak of 567 bytes from 14 blocks allocated in 
PyString_FromString
    Distribution of leaked blocks
    Allocation location
        malloc       [msvcrt.dll]
        PyString_FromString [python21.dll]
        ???          [python.exe ip=0x00405059]

This fragments the heap and my long-running program 
eventually runs out of memory. I was running my sample 
program with wxPython and so could not run debug 
version for more explicit info without compiling wx 
myself. If this is not enough info we can probably get 
a more detailed output.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456504&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 19:03:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 11:03:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-456612 ] SRE fix 133283 (minimizing repeats) bug
Message-ID: <E15c9gQ-0003Y5-00@usw-sf-web2.sourceforge.net>

Bugs item #456612, was opened at 2001-08-29 11:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456612&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fredrik Lundh (effbot)
Summary: SRE fix 133283 (minimizing repeats) bug

Initial Comment:
The following is from Python 2.2a2:

>>> pat = sre.compile(r'"(?:\")*?"')
>>> m = pat.search(r'"a"')
>>> m.group()
'"a"'

Clearly, that string should not have matched the 
pattern (since the pattern should not allow the 'a').  
I believe the problem is from the change marked as 
#133283 in _sre.c.  The code in the first ("unbounded 
repeat") branch of the if statement searches forward 
through the string until it matches the tail ('"'), 
but then the code neglects to check if the repeated 
pattern actually matches the intervening characters.

FWIW, it seems to me that the behavior for non-
unbounded repeats (which I believe is identical to the 
pcre behavior) makes more sense.  That is, it seems to 
me that a minimizing repeat should minimize the number 
of times the repeated pattern is applied, not the 
number of characters consumed by those applications.  
(However, I see that Perl (v. 5.5) minimizes 
characters consumed, so I suppose that's the reason 
for the change).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456612&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 19:40:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 11:40:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-456621 ] normpath on Win32 not collapsing c:\..
Message-ID: <E15cAGM-000458-00@usw-sf-web2.sourceforge.net>

Bugs item #456621, was opened at 2001-08-29 11:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Nobody/Anonymous (nobody)
Summary: normpath on Win32 not collapsing c:\..

Initial Comment:
normpath as implemented in ntpath.py doesn't collapse 
c:\.. at all, resulting in paths that are not 
normalized.  Adding the following to ntpath.py fixes 
this, but since I don't know how to create a context 
diff, its probably not patch quality code :)

elseif comps[i] == '..' and i == 0:
  del comps[i]

and put this before the final else.

Cheers.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 20:30:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 12:30:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-456621 ] normpath on Win32 not collapsing c:\..
Message-ID: <E15cB2W-0004pC-00@usw-sf-web2.sourceforge.net>

Bugs item #456621, was opened at 2001-08-29 11:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470

Category: Extension Modules
>Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Paul Spencer (pgs)
>Assigned to: Tim Peters (tim_one)
Summary: normpath on Win32 not collapsing c:\..

Initial Comment:
normpath as implemented in ntpath.py doesn't collapse 
c:\.. at all, resulting in paths that are not 
normalized.  Adding the following to ntpath.py fixes 
this, but since I don't know how to create a context 
diff, its probably not patch quality code :)

elseif comps[i] == '..' and i == 0:
  del comps[i]

and put this before the final else.

Cheers.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 12:30

Message:
Logged In: YES 
user_id=31435

Since c:\.. is a senseless path (you can't go above the 
root!), I think changing it to a legal path would be wrong.

C:\>dir c:\..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>dir ..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>cd c:\..
Invalid directory

C:\>

Garbage in, garbage out, so rejecting this feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 20:40:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 12:40:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-456504 ] Memory leak in PyString_FromString
Message-ID: <E15cBCT-0004hb-00@usw-sf-web3.sourceforge.net>

Bugs item #456504, was opened at 2001-08-29 06:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456504&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: Memory leak in PyString_FromString

Initial Comment:
Purify (on WinNT) reports a memory leak:

Memory leak of 567 bytes from 14 blocks allocated in 
PyString_FromString
    Distribution of leaked blocks
    Allocation location
        malloc       [msvcrt.dll]
        PyString_FromString [python21.dll]
        ???          [python.exe ip=0x00405059]

This fragments the heap and my long-running program 
eventually runs out of memory. I was running my sample 
program with wxPython and so could not run debug 
version for more explicit info without compiling wx 
myself. If this is not enough info we can probably get 
a more detailed output.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 12:40

Message:
Logged In: YES 
user_id=31435

I'm afraid we need better evidence of a "real leak" than 
this.  PyString_FromString is called from 100s of 
locations, and some of the targets are file-static vrbls 
that indeed are never *expected* to get cleared (for 
example, abstract.c constructs the string "__bases__" once 
and then reuses it forever after).

BTW, it's extremely unlikely that a "loss" of 567 bytes is 
causing you to run out of memory, yes?  I'd look elsewhere.

Assigning to Barry, since he runs Insure++ regularly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456504&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 21:55:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 13:55:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-456621 ] normpath on Win32 not collapsing c:\..
Message-ID: <E15cCNA-00062n-00@usw-sf-web2.sourceforge.net>

Bugs item #456621, was opened at 2001-08-29 11:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: normpath on Win32 not collapsing c:\..

Initial Comment:
normpath as implemented in ntpath.py doesn't collapse 
c:\.. at all, resulting in paths that are not 
normalized.  Adding the following to ntpath.py fixes 
this, but since I don't know how to create a context 
diff, its probably not patch quality code :)

elseif comps[i] == '..' and i == 0:
  del comps[i]

and put this before the final else.

Cheers.

----------------------------------------------------------------------

>Comment By: Paul Spencer (pgs)
Date: 2001-08-29 13:55

Message:
Logged In: YES 
user_id=52126

Sorry, I should have been more specific.  Your example does 
work on Win2K, just not on win9x or WinNT.  I know under 
*nix that the parent of the root directory is the root 
directory, perhaps Microsoft has modified the command 
processor under 2K to be more '*nix' like.  I'll certainly 
abide by your decision since I have found another 
workaround to my problem which avoids this situation in any 
case, but it is os specific now, which is unfortunate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 12:30

Message:
Logged In: YES 
user_id=31435

Since c:\.. is a senseless path (you can't go above the 
root!), I think changing it to a legal path would be wrong.

C:\>dir c:\..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>dir ..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>cd c:\..
Invalid directory

C:\>

Garbage in, garbage out, so rejecting this feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 22:21:50 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 14:21:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-456252 ] Python should never stomp on [u]intptr_t
Message-ID: <E15cCmU-0005dR-00@usw-sf-web1.sourceforge.net>

Bugs item #456252, was opened at 2001-08-28 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470

Category: Python Interpreter Core
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Python should never stomp on [u]intptr_t

Initial Comment:
Attached is from c.l.py.  Python should always use 
Py_uintptr_t (from pyport.h), and define a 
corresponding Py_intptr_t.  It should never presume to 
make up a definition for uintptr_t or intptr_t.  A 
quick glance suggests the problem is unique to 
Windows, so assigned it to me.

"""
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of 
Maciej Sobczak
Sent: Tuesday, August 28, 2001 3:52 AM
To: python-list@python.org
Subject: Header inconsistency?


Hi,

I'm trying to get my hands dirty with extensions and 
modules written in C/C++. I try to use SWIG.  When 
I've set up to compile the extension as a dynamic 
library, I've found that in file config.h that is 
shipped with Python distribution there are lines:

typedef long intptr_t;
typedef unsigned long uintptr_t;

whereas in some other files shipped with my compiler 
(indirectly included by my lib code) there are:

typedef int intptr_t;
typedef unsigned int uintptr_t;

The net result is that the compiler complains about 
different base types in type redefinitions. I've 
changed the config.h file to fit the rest and got my 
job done.

However, I've got a question:
Is this a problem? Or a bug? Should/Can I tinker with 
the files distributed with Python this way? Is this a 
known problem?

Few details:
I use ActiveState2.1.0 distribution and MSVC++ 
compiler on Win2000.
"""

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 14:21

Message:
Logged In: YES 
user_id=31435

Turns out it's not platform-specific, it's just worse on 
Windows than elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 22:38:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 14:38:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-456252 ] Python should never stomp on [u]intptr_t
Message-ID: <E15cD31-0006Q9-00@usw-sf-web3.sourceforge.net>

Bugs item #456252, was opened at 2001-08-28 12:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: Python should never stomp on [u]intptr_t

Initial Comment:
Attached is from c.l.py.  Python should always use 
Py_uintptr_t (from pyport.h), and define a 
corresponding Py_intptr_t.  It should never presume to 
make up a definition for uintptr_t or intptr_t.  A 
quick glance suggests the problem is unique to 
Windows, so assigned it to me.

"""
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of 
Maciej Sobczak
Sent: Tuesday, August 28, 2001 3:52 AM
To: python-list@python.org
Subject: Header inconsistency?


Hi,

I'm trying to get my hands dirty with extensions and 
modules written in C/C++. I try to use SWIG.  When 
I've set up to compile the extension as a dynamic 
library, I've found that in file config.h that is 
shipped with Python distribution there are lines:

typedef long intptr_t;
typedef unsigned long uintptr_t;

whereas in some other files shipped with my compiler 
(indirectly included by my lib code) there are:

typedef int intptr_t;
typedef unsigned int uintptr_t;

The net result is that the compiler complains about 
different base types in type redefinitions. I've 
changed the config.h file to fit the rest and got my 
job done.

However, I've got a question:
Is this a problem? Or a bug? Should/Can I tinker with 
the files distributed with Python this way? Is this a 
known problem?

Few details:
I use ActiveState2.1.0 distribution and MSVC++ 
compiler on Win2000.
"""

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 14:38

Message:
Logged In: YES 
user_id=31435

Repaired in

Include/pyport.h; new revision: 2.33
Modules/posixmodule.c; new revision: 2.198
Modules/socketmodule.c; new revision: 1.168
PC/msvcrtmodule.c; new revision: 1.7
PC/pyconfig.h; new revision: 1.3
Python/thread_nt.h; new revision: 2.18


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 14:21

Message:
Logged In: YES 
user_id=31435

Turns out it's not platform-specific, it's just worse on 
Windows than elsewhere.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456252&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 22:55:17 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 14:55:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-456621 ] normpath on Win32 not collapsing c:\..
Message-ID: <E15cDIr-0006Ef-00@usw-sf-web1.sourceforge.net>

Bugs item #456621, was opened at 2001-08-29 11:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470

Category: Extension Modules
>Group: Platform-specific
>Status: Open
Resolution: Rejected
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: normpath on Win32 not collapsing c:\..

Initial Comment:
normpath as implemented in ntpath.py doesn't collapse 
c:\.. at all, resulting in paths that are not 
normalized.  Adding the following to ntpath.py fixes 
this, but since I don't know how to create a context 
diff, its probably not patch quality code :)

elseif comps[i] == '..' and i == 0:
  del comps[i]

and put this before the final else.

Cheers.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 14:55

Message:
Logged In: YES 
user_id=31435

Hmm -- I was running on a command.com box.  I'm surprised 
(and appalled <wink>) if the cmd.exe used by Win2K differs 
in this respect from the one used by NT.  Maybe it actually 
has to do with the filesystem?  I was running FAT32, and 
there is no ".." entry in the root there; perhaps there is 
under NTFS (but I can't check that right now).

Reopening pending more info.

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2001-08-29 13:55

Message:
Logged In: YES 
user_id=52126

Sorry, I should have been more specific.  Your example does 
work on Win2K, just not on win9x or WinNT.  I know under 
*nix that the parent of the root directory is the root 
directory, perhaps Microsoft has modified the command 
processor under 2K to be more '*nix' like.  I'll certainly 
abide by your decision since I have found another 
workaround to my problem which avoids this situation in any 
case, but it is os specific now, which is unfortunate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 12:30

Message:
Logged In: YES 
user_id=31435

Since c:\.. is a senseless path (you can't go above the 
root!), I think changing it to a legal path would be wrong.

C:\>dir c:\..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>dir ..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>cd c:\..
Invalid directory

C:\>

Garbage in, garbage out, so rejecting this feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470


From noreply@sourceforge.net  Wed Aug 29 23:10:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 15:10:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-456420 ] no __methods__ for lists, strings etc.
Message-ID: <E15cDXT-0006TT-00@usw-sf-web1.sourceforge.net>

Bugs item #456420, was opened at 2001-08-29 00:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Detlef Lannert (lannert)
>Assigned to: Tim Peters (tim_one)
Summary: no __methods__ for lists, strings etc.

Initial Comment:
With Python 2.2a2+ from cvs, [].__methods__ fails with

AttributeError: 'list' object has no attribute
'__methods__'

Same for a string or a dictionary.

The Library Reference section on "Special Attributes"
(2.1.9 here) still recommends [].__methods__ for
finding out about an object's methods.

dir([]) returns [] and doesn't list the attributes
either.

OK, I can use [].__class__.__dict__.keys() -- but it's
not very intuitive ...

  Detlef


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 15:10

Message:
Logged In: YES 
user_id=31435

Reassigned to me.  __members__ and __methods__ were always 
ugly hacks, and we'd like to get rid of them.  I'm making 
dir() "smarter" again, so that dir([]) will be more 
informative (see bug 449989).

Until then, try using dir(type([])) (more generally, dir
(type(object)) instead of the atrocious 
[].__class__.__dict__.keys().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456420&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 03:42:25 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 19:42:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-456738 ] Support for smoother debugging of C exts
Message-ID: <E15cHmj-00028n-00@usw-sf-web1.sourceforge.net>

Bugs item #456738, was opened at 2001-08-29 19:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456738&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Support for smoother debugging of C exts

Initial Comment:
With every new Python release, the first thing that I
do is modify Modules/main.c to add an empty function
called

void Py_DebugTrap(void) { return; }

The purpose of this function is to give me a handy
place to set a breakpoint so that I can debug my C/C++
extension modules. 

It occured to me that this handy trick might be more
generally useful and worthy of inclusion in the
standard distributions.

Thoughts?

-- Michael Aivazis (aivazis@caltech.edu)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456738&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 04:04:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 20:04:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-456742 ] Failing test case for .*?
Message-ID: <E15cI8C-0002Mp-00@usw-sf-web2.sourceforge.net>

Bugs item #456742, was opened at 2001-08-29 20:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456742&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Darrell Gallion (dgallion)
Assigned to: Fredrik Lundh (effbot)
Summary: Failing test case for .*?

Initial Comment:
The following error is the result of patch 101612   
Which tries to fix recursion limits in sre.
>>> s="""a\nb\n1"""
>>> re.findall("[^\n]+?\d", s)
['a\nb\n1']

A less than optimal work around makes sure a 
simple '.' is being searched for.
If it has a chance of being accepted, I'll look for a 
way to remove the recursion for more complex patterns.


line 1105 _sre.c

            /* see if the tail matches */
            state->repeat = rp->prev;
            if (rp->pattern[2] == 65535 && (*(rp-
>pattern+3) == SRE_OP_ANY || *(rp->pattern+3) == 
SRE_OP_ANY_ALL)){
                /* unbounded repeat */
                for (;;) {


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456742&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 05:47:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 21:47:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-456756 ] Unary minus vs **
Message-ID: <E15cJkE-0003yg-00@usw-sf-web1.sourceforge.net>

Bugs item #456756, was opened at 2001-08-29 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456756&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Unary minus vs **

Initial Comment:
Fred, I think you already understand what's going 
wrong here.  If not, assign it back to me and I'll 
figure it out.

>>> -2**1
-2
>>> -2**2
-2
>>> -2**9832793287932874932
-2
>>> -2**(x+y+z)
-2
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456756&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 07:45:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 29 Aug 2001 23:45:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] restricted execution allows marshal
Message-ID: <E15cLZm-0004ol-00@usw-sf-web3.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: restricted execution allows marshal

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-29 23:45

Message:
Logged In: YES 
user_id=31435

Reassigning to Guido.  The patch stops marshal from loading 
a code object when in restricted mode, but I have no feel 
for whether that's going to be a serious limitation for 
restricted mode (which I've never used for real).  For 
example, wouldn't this also stop regular old imports 
from .pyc files?  I'd hate for restricted users to be 
barred from importing tabnanny <wink>.

The list-crasher is a different issue, but I went over *my* 
limit for caring about trying to foil hostile users when we 
added the immutable list type.  That trick doesn't help 
here (the mutating mutable-list method is captured in a 
bound method object before the sort is invoked).

I suppose we could instead check that the list base address 
and length haven't changed after every compare -- but with 
N*log(N) compares, that's a significant expense the 
immutable list trick was trying to get away from.  Not 
worth it to me, but my native interest in competing with 
hostile users is admittedly undetectable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-08-25 00:25

Message:
Logged In: YES 
user_id=6656

I think a reasonable approach to the first problem is to not 
let marshal load code objects when in restricted execution 
mode.

The second crasher you mention is much more worrying, to me.  
I think it blows the "immutable list trick" out of the water.

I'll attach a patch to marshal (from another machine) and 
assign to Tim to think about the list nagery.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 13:48:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 05:48:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] restricted execution allows marshal
Message-ID: <E15cRF8-0001Cg-00@usw-sf-web2.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: restricted execution allows marshal

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 05:48

Message:
Logged In: YES 
user_id=6380

Michael's patch is fine -- the code-loading is not done
in restricted mode (but the execution is, because the
restricted globals are passed).  Michael, can you check
it in?

The list issue could be fixed by adding a PyList_Check()
call to each list method implementation (or at least to
the mutating ones).

But is it sufficient?  I believe there are plenty of other
ways to cause a crash -- stack overflow is one, and I
think marshal itself can also crash on corrupt input.

Greg's bug report points out that rexec is far from
sufficient to deter a real hacker.  Imagine that this
was used in a popular email program... :-(

If we can't deprecate rexec, perhaps we should add
very big warnings to the documentation that it can't
be trusted against truly hostile users.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 23:45

Message:
Logged In: YES 
user_id=31435

Reassigning to Guido.  The patch stops marshal from loading 
a code object when in restricted mode, but I have no feel 
for whether that's going to be a serious limitation for 
restricted mode (which I've never used for real).  For 
example, wouldn't this also stop regular old imports 
from .pyc files?  I'd hate for restricted users to be 
barred from importing tabnanny <wink>.

The list-crasher is a different issue, but I went over *my* 
limit for caring about trying to foil hostile users when we 
added the immutable list type.  That trick doesn't help 
here (the mutating mutable-list method is captured in a 
bound method object before the sort is invoked).

I suppose we could instead check that the list base address 
and length haven't changed after every compare -- but with 
N*log(N) compares, that's a significant expense the 
immutable list trick was trying to get away from.  Not 
worth it to me, but my native interest in competing with 
hostile users is admittedly undetectable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-08-25 00:25

Message:
Logged In: YES 
user_id=6656

I think a reasonable approach to the first problem is to not 
let marshal load code objects when in restricted execution 
mode.

The second crasher you mention is much more worrying, to me.  
I think it blows the "immutable list trick" out of the water.

I'll attach a patch to marshal (from another machine) and 
assign to Tim to think about the list nagery.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 14:05:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 06:05:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-455648 ] getpass.getpass() freezes windows client
Message-ID: <E15cRW7-0001Si-00@usw-sf-web3.sourceforge.net>

Bugs item #455648, was opened at 2001-08-26 19:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470

Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getpass.getpass() freezes windows client

Initial Comment:
When getpass.getpass() is called from IDLE 0.8 (bundled with python 2.1.1), IDLE freezes (under windows 2000).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 06:05

Message:
Logged In: YES 
user_id=6380

This can be fixed by checking that sys.stdin is
sys.__stdin__ before using the platform-specific approach;
otherwise, the fallback should be used.

Anonymous, please check the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 14:08:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 06:08:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-455405 ] operator TypeErrors
Message-ID: <E15cRYO-0001Ti-00@usw-sf-web2.sourceforge.net>

Bugs item #455405, was opened at 2001-08-25 17:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455405&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark J (average)
Assigned to: Guido van Rossum (gvanrossum)
Summary: operator TypeErrors

Initial Comment:
Platform:  RedHat 7.1, Python 2.2a1.  Haven't been able
to verify on 2.2a2 but given absent bug report it looks
like it may apply there as well.  Apologies if this is
merely due to alpha release and unfinished
implementation.

Given:

class D(dictionary):
    def __add__(self, other):
        return
    def __sub__(self, other):
        return
    def __isub__(self, other):
        return self

>>> d=D()
>>> d + []          #works
>>> d -= []         #works
>>> d.__sub__([])   #works
>>> d - []          #oops
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: unsupported operand type(s) for -
>>> d - D()         #works

Some of the other operators (ex. /,^) are problematic
as well.  Problem also appears with objects derived
from type list.

Let me know if you need more info.  Thanks!


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 06:08

Message:
Logged In: YES 
user_id=6380

This is fixed in 2.2a2 -- in 2.2a1, there were many problems
with binary operators that were all fixed in .2a2.

Closing this report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455405&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 14:09:32 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 06:09:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-454887 ] static/classmethods and tp_slots
Message-ID: <E15cRZc-0001Up-00@usw-sf-web2.sourceforge.net>

Bugs item #454887, was opened at 2001-08-24 01:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 4
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Guido van Rossum (gvanrossum)
Summary: static/classmethods and tp_slots

Initial Comment:
Consider:

>>> class D(object):
...     def __iter__():return iter([1,2,3])
...     __iter__ = staticmethod(__iter__)
... 
>>> D.__iter__()
<iterator object at 0x814cfcc>
>>> iter(D)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: iter() of non-sequence

I can't say this is a bug, because i don't think the
behaviour of assignment of staticmethod and classmethod
objects to tp_* slots is defined. However, the
behaviour was unexpected to me.  Also, if the
assignment is illegal it should probably raise an error
at class definition time.

PS I have one or two similar examples of surprising
errors that would probably just need additional docs to
explain them. Should I report these as bugs, or should
I await further releases/doc updates first?

Cheers,

Roeland

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-24 02:42

Message:
Logged In: YES 
user_id=6380

This is indeed as intended. To get the behavior you want
(iterate over a class object) you would have to define a
metaclass (derived from type) that defines __iter__.

I'll try to ensure this is documented.

I disagree that the assignment is illegal: in general if you
put something invalid in a special method name it's very
hard to detect that until the time you actually try to call
it.

Why don't you email me the other examples?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454887&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 14:09:43 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 06:09:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] restricted execution allows marshal
Message-ID: <E15cRZn-0003lx-00@usw-sf-web1.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
Summary: restricted execution allows marshal

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 05:48

Message:
Logged In: YES 
user_id=6380

Michael's patch is fine -- the code-loading is not done
in restricted mode (but the execution is, because the
restricted globals are passed).  Michael, can you check
it in?

The list issue could be fixed by adding a PyList_Check()
call to each list method implementation (or at least to
the mutating ones).

But is it sufficient?  I believe there are plenty of other
ways to cause a crash -- stack overflow is one, and I
think marshal itself can also crash on corrupt input.

Greg's bug report points out that rexec is far from
sufficient to deter a real hacker.  Imagine that this
was used in a popular email program... :-(

If we can't deprecate rexec, perhaps we should add
very big warnings to the documentation that it can't
be trusted against truly hostile users.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 23:45

Message:
Logged In: YES 
user_id=31435

Reassigning to Guido.  The patch stops marshal from loading 
a code object when in restricted mode, but I have no feel 
for whether that's going to be a serious limitation for 
restricted mode (which I've never used for real).  For 
example, wouldn't this also stop regular old imports 
from .pyc files?  I'd hate for restricted users to be 
barred from importing tabnanny <wink>.

The list-crasher is a different issue, but I went over *my* 
limit for caring about trying to foil hostile users when we 
added the immutable list type.  That trick doesn't help 
here (the mutating mutable-list method is captured in a 
bound method object before the sort is invoked).

I suppose we could instead check that the list base address 
and length haven't changed after every compare -- but with 
N*log(N) compares, that's a significant expense the 
immutable list trick was trying to get away from.  Not 
worth it to me, but my native interest in competing with 
hostile users is admittedly undetectable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-08-25 00:25

Message:
Logged In: YES 
user_id=6656

I think a reasonable approach to the first problem is to not 
let marshal load code objects when in restricted execution 
mode.

The second crasher you mention is much more worrying, to me.  
I think it blows the "immutable list trick" out of the water.

I'll attach a patch to marshal (from another machine) and 
assign to Tim to think about the list nagery.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 14:13:10 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 06:13:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-444683 ] IDLE starts too late to enable "yield"
Message-ID: <E15cRd8-0001Xp-00@usw-sf-web2.sourceforge.net>

Bugs item #444683, was opened at 2001-07-25 22:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470

Category: IDLE
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
>Summary: IDLE starts too late to enable "yield"

Initial Comment:
In attempting to test the use of the new generators,
it seems that IDLE is too far into its operation to
allow "yield" with something like:
    from __future__ import generators
It would be nice to know how to enable it in
IDLE.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 06:13

Message:
Logged In: YES 
user_id=6380

This was fixed using a grandson of Michael's proposal below.
See PEP 264.

Closing, assigning to Tim (since he checked in the fixes).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-26 06:16

Message:
Logged In: YES 
user_id=6380

A simple solution would be to add the future statement to
codeop.py, but of course that has other disadvantages.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-07-26 04:53

Message:
Logged In: YES 
user_id=6656

I've come up with a way to do this.

It's a bit gross, although it does seem to work:

[mwh@starship src]$ ./python Lib/code.py 
Python 2.2a0 (#1, Jul 26 2001, 07:37:26) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
(InteractiveConsole)
>>> yield 1
<string>:1: Warning: 'yield' will become a reserved keyword in the future
<string>:1: Warning: 'yield' will become a reserved keyword in the future
<string>:1: Warning: 'yield' will become a reserved keyword in the future
  File "<console>", line 1
    yield 1
          ^
SyntaxError: invalid syntax
>>> from __future__ import generators
>>> yield 1
SyntaxError: 'yield' outside function
>>> 

(I can't test it in Idle 'cause I'm on a dial-up connection to the starship)

Anyway, see it here:

http://starship.python.net/crew/mwh/hacks/codeop-hack.diff

As well as the inherent unpleasantness, adding this global state to 
codeop.py sucks rather, too.  But doing a better job would mean creating 
some kind of object interface and then getting Idle to use it, and I'm 
too lazy (especially if the idea is going to get thrown out anyway).


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-25 23:02

Message:
Logged In: YES 
user_id=31435

Yes, this is a *general* issue with the future statement, 
and explained in the future-statement PEP.  It's not really 
IDLE's problem (neither the cause nor the cure); it's a 
problem for all simulated (non-native) shells, including 
doctest.py.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444683&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:35:22 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:35:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-456876 ] __getitem__ issues
Message-ID: <E15cSug-0005Gt-00@usw-sf-web1.sourceforge.net>

Bugs item #456876, was opened at 2001-08-30 07:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Hochberg (tim-hochberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getitem__ issues

Initial Comment:
(Python 2.1, Windows 2000)

__getitem__ is too consistent with __getslice__ and 
not consistant enough with itself.

When getitem called in cases that would trigger 
getslice if it were present, the slice object is 
filled in a way that is consistent with getslice, but 
not consistent with the rest of getitem's behaviour. 
It's also not as useful as it could be.

Here's what getitem receives for various cases:

>>> a[0:1]
slice(0, 1, None)
>>> a[:1] # One of these things is not like the other
slice(0, 1, None)
>>> a[:1:1]
slice(None, 1, 1)
>>> a[::]
slice(None, None, None)
>>> a[:1:]
slice(None, 1, None)

In addition to being inconsistent, this behaviour is 
less useful. Someone on the Numeric's list recently 
ran into this as a stumbling block to subclassing 
UserArray as a way to get arrays that are indexed 
starting with one. (For easier translation of some 
algorithms).

I see that this could potentially break some code, but 
at this point most code that could be broken will 
still be using getslice. Putting off fixing this will 
only make it harder to fix as more people migrate to 
the getitem protocol. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:38:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:38:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-456876 ] __getitem__ issues
Message-ID: <E15cSy3-0005KG-00@usw-sf-web1.sourceforge.net>

Bugs item #456876, was opened at 2001-08-30 07:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Hochberg (tim-hochberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getitem__ issues

Initial Comment:
(Python 2.1, Windows 2000)

__getitem__ is too consistent with __getslice__ and 
not consistant enough with itself.

When getitem called in cases that would trigger 
getslice if it were present, the slice object is 
filled in a way that is consistent with getslice, but 
not consistent with the rest of getitem's behaviour. 
It's also not as useful as it could be.

Here's what getitem receives for various cases:

>>> a[0:1]
slice(0, 1, None)
>>> a[:1] # One of these things is not like the other
slice(0, 1, None)
>>> a[:1:1]
slice(None, 1, 1)
>>> a[::]
slice(None, None, None)
>>> a[:1:]
slice(None, 1, None)

In addition to being inconsistent, this behaviour is 
less useful. Someone on the Numeric's list recently 
ran into this as a stumbling block to subclassing 
UserArray as a way to get arrays that are indexed 
starting with one. (For easier translation of some 
algorithms).

I see that this could potentially break some code, but 
at this point most code that could be broken will 
still be using getslice. Putting off fixing this will 
only make it harder to fix as more people migrate to 
the getitem protocol. 

----------------------------------------------------------------------

>Comment By: Tim Hochberg (tim-hochberg)
Date: 2001-08-30 07:38

Message:
Logged In: YES 
user_id=294744

It's worse than I thought: negative indices are even worse:

>>> a[-3:-2:1]
slice(-3, -2, 1)
>>> a[-3:-2]
  File "C:\Documents and 
Settings\tim\Desktop\boa\boa\ExternalLib\PythonInterpreter.p
y", line 65, in push
  File "<console>", line 1, in ?
exceptions.AttributeError : bar instance has no 
attribute '__len__'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:43:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:43:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-454917 ] Wrong URL for SHA standard
Message-ID: <E15cT2e-0002uG-00@usw-sf-web3.sourceforge.net>

Bugs item #454917, was opened at 2001-08-24 03:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454917&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Wrong URL for SHA standard

Initial Comment:
In the documentation for SHA,

the reference to the "Secure Hash Standard" should be

"http://csrc.nist.gov/publications/fips/fips180-
1/fip180-1.pdf"

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-30 07:43

Message:
Logged In: YES 
user_id=3066

They should never move these things.  --sigh--

Fixed in Doc/lib/libsha.tex revision 1.8.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=454917&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:51:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:51:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher
Message-ID: <E15cTAX-0005ZG-00@usw-sf-web1.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 15:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: list.sort crasher

Initial Comment:
The marshal module is on the default list of ok
builtin modules, but it can be used to crash the
interpreter.  

The new module, on the other hand, is not allowed.
To me the only obvious reason for this is that 
it provides a way to make new code objects, which can
then crash the interpreter.

But marshal also gives this ability.
Example is attached as a file.  Having imported
marshal,
I use marshal.loads() on a carefully constructed string
to get a corrupt code object.

To work out this string:

(in unrestricted mode)

def f(): pass

import marshal
badstring=marshal.dumps(f.func_code).replace('(\x01\x00\x00\x00N',
'(\x00\x00\x00\x00')

which when loaded gives a code object with co_consts =
().

Possible fixes:

Easy:  remove marshal from the list of approved
modules for restricted execution.  

Hard: Fix marshal (and perhaps new) by adding checks on
code objects before returning them.  Probably no way to
do this exhaustively.

Lateral thinking: prohibit 
exec <code object> in restricted mode?  (Currently
eval() also allows execution of code objects, so 
that would have to be changed too.)
I think this is a nice complement to the existing
features of restricted execution mode, which prevent
the attachment of a new code object to a function.


On the other hand, there's not much point fixing this
unless other methods of crashing the interpreter are
also hunted down...

>>> class C:
...     def __cmp__(self, other):
...             pop(0)
...             return 1
... 
>>> gl = [C() for i in '1'*20]
>>> pop=gl.pop
>>> gl.sort()
Segmentation fault (core dumped)


(should I submit this as a separate bug report?)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2001-08-30 07:51

Message:
Logged In: YES 
user_id=6656

OK, done, in:

marshal.c version 1.67

Changed summary.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 05:48

Message:
Logged In: YES 
user_id=6380

Michael's patch is fine -- the code-loading is not done
in restricted mode (but the execution is, because the
restricted globals are passed).  Michael, can you check
it in?

The list issue could be fixed by adding a PyList_Check()
call to each list method implementation (or at least to
the mutating ones).

But is it sufficient?  I believe there are plenty of other
ways to cause a crash -- stack overflow is one, and I
think marshal itself can also crash on corrupt input.

Greg's bug report points out that rexec is far from
sufficient to deter a real hacker.  Imagine that this
was used in a popular email program... :-(

If we can't deprecate rexec, perhaps we should add
very big warnings to the documentation that it can't
be trusted against truly hostile users.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 23:45

Message:
Logged In: YES 
user_id=31435

Reassigning to Guido.  The patch stops marshal from loading 
a code object when in restricted mode, but I have no feel 
for whether that's going to be a serious limitation for 
restricted mode (which I've never used for real).  For 
example, wouldn't this also stop regular old imports 
from .pyc files?  I'd hate for restricted users to be 
barred from importing tabnanny <wink>.

The list-crasher is a different issue, but I went over *my* 
limit for caring about trying to foil hostile users when we 
added the immutable list type.  That trick doesn't help 
here (the mutating mutable-list method is captured in a 
bound method object before the sort is invoked).

I suppose we could instead check that the list base address 
and length haven't changed after every compare -- but with 
N*log(N) compares, that's a significant expense the 
immutable list trick was trying to get away from.  Not 
worth it to me, but my native interest in competing with 
hostile users is admittedly undetectable.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-08-25 00:25

Message:
Logged In: YES 
user_id=6656

I think a reasonable approach to the first problem is to not 
let marshal load code objects when in restricted execution 
mode.

The second crasher you mention is much more worrying, to me.  
I think it blows the "immutable list trick" out of the water.

I'll attach a patch to marshal (from another machine) and 
assign to Tim to think about the list nagery.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453523&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:53:02 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:53:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-456876 ] __getitem__ issues
Message-ID: <E15cTBm-00033C-00@usw-sf-web3.sourceforge.net>

Bugs item #456876, was opened at 2001-08-30 07:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Hochberg (tim-hochberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getitem__ issues

Initial Comment:
(Python 2.1, Windows 2000)

__getitem__ is too consistent with __getslice__ and 
not consistant enough with itself.

When getitem called in cases that would trigger 
getslice if it were present, the slice object is 
filled in a way that is consistent with getslice, but 
not consistent with the rest of getitem's behaviour. 
It's also not as useful as it could be.

Here's what getitem receives for various cases:

>>> a[0:1]
slice(0, 1, None)
>>> a[:1] # One of these things is not like the other
slice(0, 1, None)
>>> a[:1:1]
slice(None, 1, 1)
>>> a[::]
slice(None, None, None)
>>> a[:1:]
slice(None, 1, None)

In addition to being inconsistent, this behaviour is 
less useful. Someone on the Numeric's list recently 
ran into this as a stumbling block to subclassing 
UserArray as a way to get arrays that are indexed 
starting with one. (For easier translation of some 
algorithms).

I see that this could potentially break some code, but 
at this point most code that could be broken will 
still be using getslice. Putting off fixing this will 
only make it harder to fix as more people migrate to 
the getitem protocol. 

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 07:53

Message:
Logged In: YES 
user_id=6380

In Python 2.2a2, you can already get the right behavior
using
new-style classes; I'm not sure it's worth fixing for
classic classes.

Python 2.2a2 (#176, Aug 22 2001, 16:23:28) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class C(object):
 def __getitem__(s,a): return a

>>> c = C()
>>> c[:]
slice(None, None, None)
>>> c[1:]
slice(1, None, None)
>>> c[:1]
slice(None, 1, None)
>>> c[-1:]
slice(-1, None, None)
>>> c[:-1]
slice(None, -1, None)
>>> 


----------------------------------------------------------------------

Comment By: Tim Hochberg (tim-hochberg)
Date: 2001-08-30 07:38

Message:
Logged In: YES 
user_id=294744

It's worse than I thought: negative indices are even worse:

>>> a[-3:-2:1]
slice(-3, -2, 1)
>>> a[-3:-2]
  File "C:\Documents and 
Settings\tim\Desktop\boa\boa\ExternalLib\PythonInterpreter.p
y", line 65, in push
  File "<console>", line 1, in ?
exceptions.AttributeError : bar instance has no 
attribute '__len__'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 15:57:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 07:57:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-456876 ] __getitem__ issues
Message-ID: <E15cTGK-00033i-00@usw-sf-web2.sourceforge.net>

Bugs item #456876, was opened at 2001-08-30 07:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Tim Hochberg (tim-hochberg)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getitem__ issues

Initial Comment:
(Python 2.1, Windows 2000)

__getitem__ is too consistent with __getslice__ and 
not consistant enough with itself.

When getitem called in cases that would trigger 
getslice if it were present, the slice object is 
filled in a way that is consistent with getslice, but 
not consistent with the rest of getitem's behaviour. 
It's also not as useful as it could be.

Here's what getitem receives for various cases:

>>> a[0:1]
slice(0, 1, None)
>>> a[:1] # One of these things is not like the other
slice(0, 1, None)
>>> a[:1:1]
slice(None, 1, 1)
>>> a[::]
slice(None, None, None)
>>> a[:1:]
slice(None, 1, None)

In addition to being inconsistent, this behaviour is 
less useful. Someone on the Numeric's list recently 
ran into this as a stumbling block to subclassing 
UserArray as a way to get arrays that are indexed 
starting with one. (For easier translation of some 
algorithms).

I see that this could potentially break some code, but 
at this point most code that could be broken will 
still be using getslice. Putting off fixing this will 
only make it harder to fix as more people migrate to 
the getitem protocol. 

----------------------------------------------------------------------

>Comment By: Tim Hochberg (tim-hochberg)
Date: 2001-08-30 07:57

Message:
Logged In: YES 
user_id=294744

Great!
If it works for new style classes, that should be fine. 
mumble mumble time machine mumble.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 07:53

Message:
Logged In: YES 
user_id=6380

In Python 2.2a2, you can already get the right behavior
using
new-style classes; I'm not sure it's worth fixing for
classic classes.

Python 2.2a2 (#176, Aug 22 2001, 16:23:28) 
[GCC 2.95.3 19991030 (prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> class C(object):
 def __getitem__(s,a): return a

>>> c = C()
>>> c[:]
slice(None, None, None)
>>> c[1:]
slice(1, None, None)
>>> c[:1]
slice(None, 1, None)
>>> c[-1:]
slice(-1, None, None)
>>> c[:-1]
slice(None, -1, None)
>>> 


----------------------------------------------------------------------

Comment By: Tim Hochberg (tim-hochberg)
Date: 2001-08-30 07:38

Message:
Logged In: YES 
user_id=294744

It's worse than I thought: negative indices are even worse:

>>> a[-3:-2:1]
slice(-3, -2, 1)
>>> a[-3:-2]
  File "C:\Documents and 
Settings\tim\Desktop\boa\boa\ExternalLib\PythonInterpreter.p
y", line 65, in push
  File "<console>", line 1, in ?
exceptions.AttributeError : bar instance has no 
attribute '__len__'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456876&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 16:08:09 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 08:08:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-455648 ] getpass.getpass() freezes windows client
Message-ID: <E15cTQP-0005qD-00@usw-sf-web1.sourceforge.net>

Bugs item #455648, was opened at 2001-08-26 19:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470

Category: IDLE
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: getpass.getpass() freezes windows client

Initial Comment:
When getpass.getpass() is called from IDLE 0.8 (bundled with python 2.1.1), IDLE freezes (under windows 2000).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 08:08

Message:
Logged In: YES 
user_id=6380

Now fixed in CVS.  I'm not going to wait for Anonymous to
write back.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 06:05

Message:
Logged In: YES 
user_id=6380

This can be fixed by checking that sys.stdin is
sys.__stdin__ before using the platform-specific approach;
otherwise, the fallback should be used.

Anonymous, please check the attached patch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455648&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 17:26:56 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 09:26:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-429357 ] non-greedy regexp duplicating match bug
Message-ID: <E15cUee-0004PS-00@usw-sf-web3.sourceforge.net>

Bugs item #429357, was opened at 2001-06-01 09:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429357&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Fredrik Lundh (effbot)
Summary: non-greedy regexp duplicating match bug

Initial Comment:
I found some weird bug, where when a non-greedy match doesn't match anything,
it will duplicate the rest of the string instead of being None. 

#pyrebug.py:
import re
urlrebug=re.compile("""
	(.*?)://			#scheme
	(
		(.*?)			#user
		(?:
			:(.*)		#pass
		)?
	@)?
	(.*?)				#addr
	(?::([0-9]+))?			#port
	(/.*)?$				#path
""", re.VERBOSE)

testbad='foo://bah:81/pth'

print urlrebug.match(testbad).groups()

Bug Output:
>python2.1 pyrebug.py       
('foo', None, 'bah:81/pth', None, 'bah', '81', '/pth')
>python-cvs pyrebug.py       
('foo', None, 'bah:81/pth', None, 'bah', '81', '/pth')

Good (expected) Output:
>python1.5 pyrebug.py       
('foo', None, None, None, 'bah', '81', '/pth')



----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2001-08-30 09:26

Message:
Logged In: YES 
user_id=292741

This looks like the same bug I have reported (with a much simpler example)
as #448951 (missed this one before because I was looking for 'group').
What I found is consistent with Jeffrey's comments -
if you have a situation where an optional part is fully scanned before the
state machine can tell if it should actually be matched, the contained tentative
match(es) are stored in the group() even if the optional part turns out 
to fail. Presumably, such a case needs to be handled by going back and
deleting these after the s.m. determines that the optional part was not
matched. In my example, I mention a small modification to the test case where
the failure of the optional ? is decided one character later (at the end of the
() group, not beyond it);  this is enough to make it start working again.



----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2001-06-14 00:59

Message:
Logged In: YES 
user_id=65253

I think I understand what you are saying, and in the context
of the test, it doesn't seem too bad.  BUT, my original code
(and what I'd like to have) did not have the surrounding group.

So I'd just get: ('foo', 'bah:81/pth', None, 'bah', '81',
'/pth') 

Knowing the general ease of messing up regexs when writing
them, I'm sure you can image the pain I went through  before
actually realizing it was a python bug :)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-06-13 10:12

Message:
Logged In: NO 

What's happening makes sense, on one level.
When the regex engine gets to the user:pass@ part

((.*?)(?::(.*))?@)?

which fill groups 2, 3, and 4, the .*? of group 3 has
to try at every character in the rest of the string before
admitting overall defeat. In doing that, the last time
that group 3 successfully completely locally, it has the
rest of the string matched. Of course, overall, group
three is enclosed within group 2, and when group two
couldn't complete successfully, the engine knows it can
skip group two (due to the ? modifying it), so it totally
bails on groups 2, 3 and 4 to continue with the rest of
the expression.

What you'd like to happen is when that "bailing" happens
for group 2, the enclosing groups 3 and 4 would get zereoed
out (since they didn't participate in the *final* overall
match). That makes sense, and is what I would expect to
happen.  However, what *is* happening is that group 3 is
keeping the string that *it* last matched (even thought
that last match didn't contribute to the final, overall
match).

I'm not explaining this well -- I hope you can understand
it despite that. Sorry.

	Jeffrey


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429357&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 17:30:24 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 09:30:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-448951 ] Bug in re group handling
Message-ID: <E15cUi0-0007ES-00@usw-sf-web1.sourceforge.net>

Bugs item #448951, was opened at 2001-08-07 17:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470

Category: Regular Expressions
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: Bug in re group handling

Initial Comment:
#
# read it or run it!
#
import re,sys
print sys.version
#
# Bug in 're' lib in Python 2.1
#
# Consider this regexp : (?:([0-3]):)?0#
# This will match one of
# '0#', '0:0#', '1:0#', '2:0#', '3:0#' 
#
# The matching itself works fine, but group(1) should
# be None for the '0#' case, and 'x' for the 'x:0#' cases.
# For '0#', the optional '([0-3]):' part of the
# r.e. (enclosed in (?: )) does not match anything, and that
# is what contains group 1.
#
# The actual result is, group(1) is '0' for both '0#' and '0:0#'.
# Likely this happens because when '0' is seen, the state machine
# cannot not yet determine whether the ([0-3]): should be matched,
# but has already seen enough of it to know what group(1) is, assuming
# it does match. The match needs to be deleted once the containing 
# ? fails. Indeed, if the group is expanded to include the ':',
# as in '(?:([0-3]:))?0#', or just '([0-3]:)?0#', '0#' produces
# group(1)=None as it should.
#
# Also, this is a good time to point out an error in the
# docs. The docs say that group(n) returns -1 when the
# group is in an unmatched part the of the r.e.; actually
# it returns None, which is more sensible.
#

rexp = '(?:([0-3]):)?0#'
mat1 = re.compile(rexp)

print "Re = ", rexp

for str in [ '2:0#', '0:0#', '0#', '0:#', ':0#']:
	print "\n-----<<", str, ">>-----"
	mat = mat1.match(str)
	if mat:
		print "    group(0) = ", mat.group(0)
		print "    group(1) = ", mat.group(1)
	else:
		print "    no match"
#
# output is below
#
#################################
# Python 2.1 (#15, Apr 16 2001, 18:25:49) [MSC 32 bit (Intel)] on win32
# Re =  (?:([0-3]):)?0#
# 
# -----<< 2:0# >>-----
#     group(0) =  2:0#
#     group(1) =  2
# 
# -----<< 0:0# >>-----
#     group(0) =  0:0#
#     group(1) =  0
# 
# -----<< 0# >>-----
#     group(0) =  0#
#     group(1) =  0
# 
# -----<< 0:# >>-----
#     no match
# 
# -----<< :0# >>-----
#     no match
#
############################################

----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2001-08-30 09:30

Message:
Logged In: YES 
user_id=292741

This appears to be the same bug as #429357, albeit using
a simpler test case. I have added a comment to that
one.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448951&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 19:53:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 11:53:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-456756 ] Unary minus vs **
Message-ID: <E15cWwl-0006Ur-00@usw-sf-web2.sourceforge.net>

Bugs item #456756, was opened at 2001-08-29 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456756&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Unary minus vs **

Initial Comment:
Fred, I think you already understand what's going 
wrong here.  If not, assign it back to me and I'll 
figure it out.

>>> -2**1
-2
>>> -2**2
-2
>>> -2**9832793287932874932
-2
>>> -2**(x+y+z)
-2
>>>


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-30 11:53

Message:
Logged In: YES 
user_id=3066

Fixed in Python/compile.c revision 2.221.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456756&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:24:28 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:24:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-456176 ] add dictionary "tokens" to token.py
Message-ID: <E15cYMW-0007o4-00@usw-sf-web2.sourceforge.net>

Bugs item #456176, was opened at 2001-08-28 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Submitted By: Grant Griffin (dspguru)
Assigned to: Nobody/Anonymous (nobody)
>Summary: add dictionary "tokens" to token.py

Initial Comment:
I would like for token.py to provide a dictionary, 
called "tokens" that maps the name of each token to 
its value, e.g.:

   token.tokens[token.INDENT] is 'INDENT'

This would be useful for debugging programs that use 
tokenize.

A user currently could create a dictionary like this 
using introspection on token.py (assuming tokens are 
in all caps) but that's a lot of trouble.  Instead, I 
believe it would be better to solve the problem once-
and-for-all by building the extra logic required to 
create the dictionary into token.main.

thanks much,

=g2


----------------------------------------------------------------------

Comment By: Grant Griffin (dspguru)
Date: 2001-08-28 08:52

Message:
Logged In: YES 
user_id=70844

Sorry!  This is a duplicate of the previous one.  Please 
delete it.

darn-them-browsers-ly y'rs

=g2

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456176&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:27:01 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:27:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-453684 ] In 2.2, types are inheritable, &c
Message-ID: <E15cYOz-0007r4-00@usw-sf-web2.sourceforge.net>

Bugs item #453684, was opened at 2001-08-21 04:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: In 2.2, types are inheritable, &c

Initial Comment:
http://python.sourceforge.net/devel-
docs/ref/class.html says that "Each item in the 
inheritance list should evaluate to a class object" -- 
no mention of 2.2's highlight, that a type can also be 
there?

Is there any mention anywhere in the 2.2a2 language 
reference manual of 2.2's new features?  Maybe I'm 
missing something, but I can't see any -- iterators, 
generators, __slots__, etc, etc.



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:27

Message:
Logged In: YES 
user_id=31392

Is it worth keeping this bug report?  We know that the
documentation is incomplete.  I'd say close it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=453684&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:30:21 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:30:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-423721 ] failure in urllib exception handling
Message-ID: <E15cYSD-0007uU-00@usw-sf-web2.sourceforge.net>

Bugs item #423721, was opened at 2001-05-13 07:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423721&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Robin Becker (rgbecker)
Assigned to: Nobody/Anonymous (nobody)
Summary: failure in urllib exception handling

Initial Comment:
This is observed sometimes using webchecker.py running python 2.0 under freeBSD 4.2
seems like urllib might checking strings against Exception instances

webchecker version 1.22

Round 1 (1 total, 1 to do, 0 done, 0 bad)


Round 2 (20 total, 19 to do, 1 done, 0 bad)


Round 3 (117 total, 97 to do, 20 done, 0 bad)


Saving checkpoint to @webchecker.pickle ...
Done.
Use ``/usr/local/lib/python2.0/Tools/webchecker/webchecker.py -R'' to
restart.
Traceback (most recent call last):
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
824, in ?
    main()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
222, in main
    c.run()
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
349, in run
    self.dopage(url)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
403, in dopage
    page = self.getpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
496, in getpage
    f = self.openpage(url_pair)
  File "/usr/local/lib/python2.0/Tools/webchecker/webchecker.py", line
534, in openpage
    return self.urlopener.open(url)
  File "/usr/local/lib/python2.0/urllib.py", line 166, in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.0/urllib.py", line 457, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "/usr/local/lib/python2.0/urllib.py", line 692, in retrfile
    if reason[:3] != '550':
TypeError: sequence index must be integer

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:30

Message:
Logged In: YES 
user_id=31392

No, this bug isn't present in 2.1.  It was fixed about six
months before this bug report was submitted.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-16 01:34

Message:
Logged In: NO 

"reason" is an ftp error exception instance, which
doesn't support slicing.  changing this to

    if str(reason)[:3] != "550"

should work.

is this bug still present in 2.1?  (only have 2.0 on
the box I'm typing this on)

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=423721&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:31:52 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:31:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E15cYTg-0007vr-00@usw-sf-web2.sourceforge.net>

Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Greg Stein (gstein)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 04:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:33:31 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:33:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-435596 ] Fork/Thread problems on FreeBSD
Message-ID: <E15cYVH-0007xD-00@usw-sf-web2.sourceforge.net>

Bugs item #435596, was opened at 2001-06-22 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435596&group_id=5470

Category: Threads
Group: Platform-specific
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fork/Thread problems on FreeBSD

Initial Comment:
Run this code on both Linux and FreeBSD. On Linux you
get a continuous stream of *'s. On FreeBSD you get 1.
FreeBSD is wrong.

import thread, os, sys, time
def run():
    while 1:
        if os.fork() == 0:
            time.sleep(0.001)
            sys.stderr.write('*')
            sys.stderr.flush()
            sys.exit(0)
            break
        os.wait()

thread.start_new_thread(run, ())
while 1:
    time.sleep(0.001)
    pass

I ran into this problem when trying to use Popen3 to
run a system call from Zope. The fork in Popen3 never
gets to the execvp. It works fine on Linux. I believe
the problem in the above code is caused by the same
issue.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:33

Message:
Logged In: YES 
user_id=31392

There's not much point to keeping this bug report around. 
There's not much evidence that it is a problem with Python
and the original poster has disappeared.

----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-26 14:59

Message:
Logged In: YES 
user_id=21627

As an additional comment, can you please verify what 
shared libraries are loaded at the time of the crash? If 
both the threaded and the non-threaded libc are loaded, 
problems will occur quite naturally.


----------------------------------------------------------------------

Comment By: Martin v. Lіwis (loewis)
Date: 2001-06-23 14:02

Message:
Logged In: YES 
user_id=21627

Why do you think this is a bug in Python?

Can you determine whether the thread is started, and 
whether the fork returns for the parent?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=435596&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:34:29 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:34:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-420720 ] Starting many threads causes core dump
Message-ID: <E15cYWD-0007yM-00@usw-sf-web2.sourceforge.net>

Bugs item #420720, was opened at 2001-05-02 07:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420720&group_id=5470

Category: Threads
Group: None
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Starting many threads causes core dump

Initial Comment:
If I start more than 1020 threads simultaneously, using
the threading module, Python 2.1 causes segmentation
faults, or will not exit, under Linux. I have not
tested this on Windows.

I don't know whether the problems are caused by the
threads themselves, or the threading.Event for which
they are waiting.

I have attached a program threadKill3.py which
demonstrates this (including sample runs and output).


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:34

Message:
Logged In: YES 
user_id=31392

Unlikely that this is Python's fault.


----------------------------------------------------------------------

Comment By: Thomas Hazel (thazel)
Date: 2001-06-04 14:29

Message:
Logged In: YES 
user_id=127523

Python Support/Developers,

I believe the fault is in Pthreads and not in the python 
interpreter. Pthreads under Linux has a few issues. Running 
this python test under Windows should not have this problem.

I have run similar tests in python with txObject ATK's 
abstraction layer to native(pthreads/Windows) threads. I 
have run these python tests on Linux, Windows and Solaris. 
Only Linux has this problem.

If folks are interested, the project txObject ATK 
(txobject.sourceforge.net) has home grown threads that can 
scale to many thousand of threads (or as much memory as you 
have). txObject ATK also provides python wrappers to these 
features. However these threads are non-preemptive.

Hope this helps

Tom



----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-05-09 08:53

Message:
Logged In: YES 
user_id=31392

We need two things in order to offer any useful help:
1. A stack trace from the core file.
2. Evidence that a C program that starts 1024 threads
   won't do the same thing.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420720&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:35:41 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:35:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-422686 ] sys.path initialization in embedded Pyth
Message-ID: <E15cYXN-0007zK-00@usw-sf-web2.sourceforge.net>

Bugs item #422686, was opened at 2001-05-09 09:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422686&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
>Assigned to: Tim Peters (tim_one)
Summary: sys.path initialization in embedded Pyth

Initial Comment:

Context:
======
Python 2.1 final release, working with build from source (c:\program files\python does not exist), 
and PYTHONHOME is set to point to the root source directory (c:\local\src\Python-2.1).
Problem shows up on Windows (other platforms?)

Problem:
======
The directory of the executable (which is not python.exe) shows up in second position in sys.path.

Ex:
==
When the process executable (__argv value) is c:\jdk1.3.0_02\bin\java.exe, I get:

sys.path = ['c:\local\src\jpe', 'c:\local\src\python-2.1\dlls', 'c:\local\src\python-2.1\lib', 
'c:\local\src\python-2.1\lib\plat-win', 'c:\local\src\python-2.1\lib\lib-tk', 
'c:\jdk1.3.0_02\bin', 'c:\local\src\python-2.1']


Note:
===
If PYTHONHOME is not set in the environment, I get a 'site module not found' message upon Python 
initialization, and then a corrupted import behavior, with corrupted values in sys.modules.
Maybe the Python VM should exit right away when the site module cannot be imported, instead of 
going on and working with a corrupted sys.modules list.

I did not have this problem on Python 1.5.2.

I looked at the sys.path initialization C code (getpath() function, windows-specific code...); the 
code seems quite complex, and I could not trace easily where the executable's directory was 
picked up.

By default of finding the source of the problem, an external fix could be a rule of the kind: Do not 
add the executable directory to sys.path when the executable basename not in (python, 
python.exe).

Frederic Giacometti


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=422686&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:41:18 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:41:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-430753 ] Python 2.1 build fails on hp-ux 11
Message-ID: <E15cYco-00085K-00@usw-sf-web2.sourceforge.net>

Bugs item #430753, was opened at 2001-06-06 10:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Eric S. Raymond (esr)
Summary: Python 2.1 build fails on hp-ux 11

Initial Comment:
I'm building on HP-UX 11.00 with HP C B.11.02.02.  I've 
tried it on both Series 700 and 800 hardware.

I've attached the make logfile.

There are problems with:

build.py not adding +z when compiling modules
termios.c - may be fixed according to another bug 
report
_cursesmodule.c

Please send any fixes to joshua.weage@arup.com

Thanks


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:41

Message:
Logged In: YES 
user_id=31392

The attached make output shows a lot of problems compiling
the curses support.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430753&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:39:16 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:39:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-431597 ] Code being copied into shelve and UserDi
Message-ID: <E15cYaq-000830-00@usw-sf-web2.sourceforge.net>

Bugs item #431597, was opened at 2001-06-09 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470

Category: Python Library
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick Jones (rjones33410)
Assigned to: Nobody/Anonymous (nobody)
Summary: Code being copied into shelve and UserDi

Initial Comment:
I've been writing a contacts program that uses a 
UserDict as a direct interface to the record which is 
then placed into a shelve.  When I view the DB file 
created by the shelve module I can see my code in the 
Table.

This is a sample from the very start of the shelve 
file, before the first record.  This apears in the 
begining like this no matter how many times I re-run 
it with varying number of records.

	
	­&#8226;n}у	Ў&#8220;Х}
&#8364;фЃ
t%vYачЃ
&#8364;%v
            CurKeys=db.keys()
            Test=len(CurKeys)
            Temp=1
            NewList=[]
            for list in CurKeys:
                One=int(list)
                NewList.append(One)
                if Test in NewList:
                    Test=Test+1
                    Temp=Test
            NextID='%s' % Temp
            GetEntry=ThisEntry()
            db[NextID]=GetEntry
            print 'New Entry no.',NextID
            db.close()
        
print 'Doneџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ
џџџџџџџџџџџџџџџџџџџџџџ

This is the method that is actually being looped.  
You'll note at the end the shelve is closed after each 
record is added yet only a single copy of the code.  
I'm baffled as to how this can be?  Not to mention it 
copied the entire document/module without regard to 
scope.

I discovered this when I did a record loop test to 
stuff 1000 records into the shelve.  I opened the file 
to see if there were any noticable problems since I 
don't know what kind of density the shelve can handle 
and saw my code in the table along with the record I 
looped in.

Now I figured I had somehow made the module scope a 
variable that was being looped in with the record so I 
went through the entire 1000 record entries and my 
code only apears once, although it is somewhat broken 
up and much more binary looking than my record.

I'm sure you can understand how much of a problem this 
can be in a comercial app.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:39

Message:
Logged In: YES 
user_id=31392

What exactly is the bug that you are reporting?  Was the
database created by shelve corrupted?  Or were you just
surprised by the appeance of the bits in it?  If there is
some functional problem, please provide a small reproducible
example.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 21:56:47 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 13:56:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-431597 ] Code being copied into shelve and UserDi
Message-ID: <E15cYrn-0003Hp-00@usw-sf-web1.sourceforge.net>

Bugs item #431597, was opened at 2001-06-09 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470

Category: Python Library
Group: 3rd Party
Status: Open
Resolution: None
Priority: 5
Submitted By: Rick Jones (rjones33410)
Assigned to: Nobody/Anonymous (nobody)
Summary: Code being copied into shelve and UserDi

Initial Comment:
I've been writing a contacts program that uses a 
UserDict as a direct interface to the record which is 
then placed into a shelve.  When I view the DB file 
created by the shelve module I can see my code in the 
Table.

This is a sample from the very start of the shelve 
file, before the first record.  This apears in the 
begining like this no matter how many times I re-run 
it with varying number of records.

	
	­&#8226;n}у	Ў&#8220;Х}
&#8364;фЃ
t%vYачЃ
&#8364;%v
            CurKeys=db.keys()
            Test=len(CurKeys)
            Temp=1
            NewList=[]
            for list in CurKeys:
                One=int(list)
                NewList.append(One)
                if Test in NewList:
                    Test=Test+1
                    Temp=Test
            NextID='%s' % Temp
            GetEntry=ThisEntry()
            db[NextID]=GetEntry
            print 'New Entry no.',NextID
            db.close()
        
print 'Doneџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ
џџџџџџџџџџџџџџџџџџџџџџ

This is the method that is actually being looped.  
You'll note at the end the shelve is closed after each 
record is added yet only a single copy of the code.  
I'm baffled as to how this can be?  Not to mention it 
copied the entire document/module without regard to 
scope.

I discovered this when I did a record loop test to 
stuff 1000 records into the shelve.  I opened the file 
to see if there were any noticable problems since I 
don't know what kind of density the shelve can handle 
and saw my code in the table along with the record I 
looped in.

Now I figured I had somehow made the module scope a 
variable that was being looped in with the record so I 
went through the entire 1000 record entries and my 
code only apears once, although it is somewhat broken 
up and much more binary looking than my record.

I'm sure you can understand how much of a problem this 
can be in a comercial app.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 13:56

Message:
Logged In: YES 
user_id=6380

I'm guessing that the shelf is using bsddb or gdbm.
These can leave some garbage in the file -- it is a binary
file
and you're not supposed to look at the DB file with a text
editor.
Due to reuse of I/O buffers, it's possible that the DB file
garbage
happens to be the contents of a file that was previously
read by
Python -- such as apparently the program source file.

The misunderstanding that the user expected the database
file
to be a text file, and opened it with a text editor.
This makes no sense.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:39

Message:
Logged In: YES 
user_id=31392

What exactly is the bug that you are reporting?  Was the
database created by shelve corrupted?  Or were you just
surprised by the appeance of the bits in it?  If there is
some functional problem, please provide a small reproducible
example.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 22:10:30 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 14:10:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E15cZ54-0008UF-00@usw-sf-web3.sourceforge.net>

Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-30 14:10

Message:
Logged In: YES 
user_id=12800

Please use RFC 2822 instead of 822 as the former has
replaced the latter. RFC 2822 describes the number of times
standard headers must or can appear in a mail message. 
AFAIK, rfc822.py does no such enforcement (and there are
good reasons to have both strict and lenient modes).  

My own mimelib (soon to be renamed and installed in the
standard library) accepts duplicates by keeping headers in a
list instead of a dictionary and searching the list linearly
for hits.  The speed advantages of a dictionary are probably
minimal for typical mail messages, so a linear search, which
preserves insertion order and duplicate order, is fine in
practice.

mimelib does not, but should have both a strict and lenient
mode where duplicates breaking the standard are either
allowed or flagged as errors.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 04:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 22:15:36 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 14:15:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-431597 ] Code being copied into shelve and UserDi
Message-ID: <E15cZA0-00006g-00@usw-sf-web3.sourceforge.net>

Bugs item #431597, was opened at 2001-06-09 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Rick Jones (rjones33410)
Assigned to: Nobody/Anonymous (nobody)
Summary: Code being copied into shelve and UserDi

Initial Comment:
I've been writing a contacts program that uses a 
UserDict as a direct interface to the record which is 
then placed into a shelve.  When I view the DB file 
created by the shelve module I can see my code in the 
Table.

This is a sample from the very start of the shelve 
file, before the first record.  This apears in the 
begining like this no matter how many times I re-run 
it with varying number of records.

	
	­&#8226;n}у	Ў&#8220;Х}
&#8364;фЃ
t%vYачЃ
&#8364;%v
            CurKeys=db.keys()
            Test=len(CurKeys)
            Temp=1
            NewList=[]
            for list in CurKeys:
                One=int(list)
                NewList.append(One)
                if Test in NewList:
                    Test=Test+1
                    Temp=Test
            NextID='%s' % Temp
            GetEntry=ThisEntry()
            db[NextID]=GetEntry
            print 'New Entry no.',NextID
            db.close()
        
print 'Doneџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџџ
џџџџџџџџџџџџџџџџџџџџџџ

This is the method that is actually being looped.  
You'll note at the end the shelve is closed after each 
record is added yet only a single copy of the code.  
I'm baffled as to how this can be?  Not to mention it 
copied the entire document/module without regard to 
scope.

I discovered this when I did a record loop test to 
stuff 1000 records into the shelve.  I opened the file 
to see if there were any noticable problems since I 
don't know what kind of density the shelve can handle 
and saw my code in the table along with the record I 
looped in.

Now I figured I had somehow made the module scope a 
variable that was being looped in with the record so I 
went through the entire 1000 record entries and my 
code only apears once, although it is somewhat broken 
up and much more binary looking than my record.

I'm sure you can understand how much of a problem this 
can be in a comercial app.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 14:15

Message:
Logged In: YES 
user_id=31392

Okay.  That's also what I expected, but wasn't sure if there
was some problem with database corruption.  I'll close this
and let the user re-submit if he has a real problem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 13:56

Message:
Logged In: YES 
user_id=6380

I'm guessing that the shelf is using bsddb or gdbm.
These can leave some garbage in the file -- it is a binary
file
and you're not supposed to look at the DB file with a text
editor.
Due to reuse of I/O buffers, it's possible that the DB file
garbage
happens to be the contents of a file that was previously
read by
Python -- such as apparently the program source file.

The misunderstanding that the user expected the database
file
to be a text file, and opened it with a text editor.
This makes no sense.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-30 13:39

Message:
Logged In: YES 
user_id=31392

What exactly is the bug that you are reporting?  Was the
database created by shelve corrupted?  Or were you just
surprised by the appeance of the bits in it?  If there is
some functional problem, please provide a small reproducible
example.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431597&group_id=5470


From noreply@sourceforge.net  Thu Aug 30 23:06:40 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 15:06:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-456621 ] normpath on Win32 not collapsing c:\..
Message-ID: <E15cZxQ-0000n4-00@usw-sf-web3.sourceforge.net>

Bugs item #456621, was opened at 2001-08-29 11:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Paul Spencer (pgs)
Assigned to: Tim Peters (tim_one)
Summary: normpath on Win32 not collapsing c:\..

Initial Comment:
normpath as implemented in ntpath.py doesn't collapse 
c:\.. at all, resulting in paths that are not 
normalized.  Adding the following to ntpath.py fixes 
this, but since I don't know how to create a context 
diff, its probably not patch quality code :)

elseif comps[i] == '..' and i == 0:
  del comps[i]

and put this before the final else.

Cheers.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-30 15:06

Message:
Logged In: YES 
user_id=31435

I changed this after all -- posixpath makes a similar 
simplification, and there's no future catering to Win9X.  
Thanks!

Checked in as

Lib/ntpath.py; new revision: 1.41
Lib/test/test_ntpath.py; new revision: 1.12

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 14:55

Message:
Logged In: YES 
user_id=31435

Hmm -- I was running on a command.com box.  I'm surprised 
(and appalled <wink>) if the cmd.exe used by Win2K differs 
in this respect from the one used by NT.  Maybe it actually 
has to do with the filesystem?  I was running FAT32, and 
there is no ".." entry in the root there; perhaps there is 
under NTFS (but I can't check that right now).

Reopening pending more info.

----------------------------------------------------------------------

Comment By: Paul Spencer (pgs)
Date: 2001-08-29 13:55

Message:
Logged In: YES 
user_id=52126

Sorry, I should have been more specific.  Your example does 
work on Win2K, just not on win9x or WinNT.  I know under 
*nix that the parent of the root directory is the root 
directory, perhaps Microsoft has modified the command 
processor under 2K to be more '*nix' like.  I'll certainly 
abide by your decision since I have found another 
workaround to my problem which avoids this situation in any 
case, but it is os specific now, which is unfortunate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-29 12:30

Message:
Logged In: YES 
user_id=31435

Since c:\.. is a senseless path (you can't go above the 
root!), I think changing it to a legal path would be wrong.

C:\>dir c:\..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>dir ..

 Volume in drive C is HOMEDRIVE
 Volume Serial Number is 2637-18E7
Invalid directory

C:\>cd c:\..
Invalid directory

C:\>

Garbage in, garbage out, so rejecting this feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=456621&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 02:17:23 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 18:17:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-457066 ] pow(a,b,c) should accept b<0
Message-ID: <E15ccvz-0003JQ-00@usw-sf-web3.sourceforge.net>

Bugs item #457066, was opened at 2001-08-30 18:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: pow(a,b,c) should accept b<0

Initial Comment:
You should be able to raise integers to negative powers
mod n.  If b<0, pow(a,b,c)==pow(pow(a,-1,c),-b,c)
where pow(a,-1,c) is a's multiplicative inverse mod c,
computed with the extended Euclid algorithm.  This
would be in Python's spirit of math completeness and
would save people from the trouble of having to figure
out the algorithm over and over.  

I can come up with a patch for this if it's agreed on
as desirable.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 02:46:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 18:46:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-457066 ] pow(a,b,c) should accept b<0
Message-ID: <E15cdOP-0003WQ-00@usw-sf-web2.sourceforge.net>

Bugs item #457066, was opened at 2001-08-30 18:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: pow(a,b,c) should accept b<0

Initial Comment:
You should be able to raise integers to negative powers
mod n.  If b<0, pow(a,b,c)==pow(pow(a,-1,c),-b,c)
where pow(a,-1,c) is a's multiplicative inverse mod c,
computed with the extended Euclid algorithm.  This
would be in Python's spirit of math completeness and
would save people from the trouble of having to figure
out the algorithm over and over.  

I can come up with a patch for this if it's agreed on
as desirable.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 18:46

Message:
Logged In: YES 
user_id=6380

Hm.

In 2.2a2, currently, pow(a, b, c) for ints a, b, c where b <
0 is defined as pow(float(a), float(b), float(c)), IOW
(1.0/(a**b))%c. This doesn't make a lot of sense for the
three-argument version though, because the result tends to
be between 0.0 and 1.0...  But it is consistent with the
(future) rule that operations on integers and floats should
give results with the same value only a different type.

Assigning to Tim, whose mathematical sensibilities are more
refined than mine...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 02:49:51 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 18:49:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-457066 ] pow(a,b,c) should accept b<0
Message-ID: <E15cdRP-0007hY-00@usw-sf-web1.sourceforge.net>

Bugs item #457066, was opened at 2001-08-30 18:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: pow(a,b,c) should accept b<0

Initial Comment:
You should be able to raise integers to negative powers
mod n.  If b<0, pow(a,b,c)==pow(pow(a,-1,c),-b,c)
where pow(a,-1,c) is a's multiplicative inverse mod c,
computed with the extended Euclid algorithm.  This
would be in Python's spirit of math completeness and
would save people from the trouble of having to figure
out the algorithm over and over.  

I can come up with a patch for this if it's agreed on
as desirable.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 18:49

Message:
Logged In: YES 
user_id=6380

Of course I meant (1.0/(a**-b))%c. Sorry!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 18:46

Message:
Logged In: YES 
user_id=6380

Hm.

In 2.2a2, currently, pow(a, b, c) for ints a, b, c where b <
0 is defined as pow(float(a), float(b), float(c)), IOW
(1.0/(a**b))%c. This doesn't make a lot of sense for the
three-argument version though, because the result tends to
be between 0.0 and 1.0...  But it is consistent with the
(future) rule that operations on integers and floats should
give results with the same value only a different type.

Assigning to Tim, whose mathematical sensibilities are more
refined than mine...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 03:52:14 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 19:52:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E15cePm-0004LK-00@usw-sf-web2.sourceforge.net>

Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
>Group: Python 2.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2001-08-30 19:52

Message:
Logged In: YES 
user_id=6501

Use response.msg.getallmatchingheaders() as a workaround.

That said: the default operation of HTTPResponse.getheader
() should use the same, since HTTP headers can (by 
definition) use multiple headers. And HTTP defines a way to 
join those headers into one.

The solution here is to not return a list of header values 
(thus, breaking backwards compat), but to join them per the 
specification (with a ",").

I'm reclassifying this as an Accepted bug due to fix in 
Python 2.2.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-30 14:10

Message:
Logged In: YES 
user_id=12800

Please use RFC 2822 instead of 822 as the former has
replaced the latter. RFC 2822 describes the number of times
standard headers must or can appear in a mail message. 
AFAIK, rfc822.py does no such enforcement (and there are
good reasons to have both strict and lenient modes).  

My own mimelib (soon to be renamed and installed in the
standard library) accepts duplicates by keeping headers in a
list instead of a dictionary and searching the list linearly
for hits.  The speed advantages of a dictionary are probably
minimal for typical mail messages, so a linear search, which
preserves insertion order and duplicate order, is fine in
practice.

mimelib does not, but should have both a strict and lenient
mode where duplicates breaking the standard are either
allowed or flagged as errors.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 04:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 04:37:58 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 20:37:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E15cf82-0004tz-00@usw-sf-web2.sourceforge.net>

Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 20:37

Message:
Logged In: YES 
user_id=6380

Greg: this is a new use of "Accepted" for me. We've only
used "Accepted" for accepted *patches*. Bugs to be fixed
simply remain open until they are fixed; I'm not sure I see
the value of changing the status. Were you innovating here,
or is this common usage in other projects?

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-08-30 19:52

Message:
Logged In: YES 
user_id=6501

Use response.msg.getallmatchingheaders() as a workaround.

That said: the default operation of HTTPResponse.getheader
() should use the same, since HTTP headers can (by 
definition) use multiple headers. And HTTP defines a way to 
join those headers into one.

The solution here is to not return a list of header values 
(thus, breaking backwards compat), but to join them per the 
specification (with a ",").

I'm reclassifying this as an Accepted bug due to fix in 
Python 2.2.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-30 14:10

Message:
Logged In: YES 
user_id=12800

Please use RFC 2822 instead of 822 as the former has
replaced the latter. RFC 2822 describes the number of times
standard headers must or can appear in a mail message. 
AFAIK, rfc822.py does no such enforcement (and there are
good reasons to have both strict and lenient modes).  

My own mimelib (soon to be renamed and installed in the
standard library) accepts duplicates by keeping headers in a
list instead of a dictionary and searching the list linearly
for hits.  The speed advantages of a dictionary are probably
minimal for typical mail messages, so a linear search, which
preserves insertion order and duplicate order, is fine in
practice.

mimelib does not, but should have both a strict and lenient
mode where duplicates breaking the standard are either
allowed or flagged as errors.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 04:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 05:23:54 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 21:23:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-432621 ] httplib: multiple Set-Cookie headers
Message-ID: <E15cfqU-0005S1-00@usw-sf-web2.sourceforge.net>

Bugs item #432621, was opened at 2001-06-12 19:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Greg Stein (gstein)
Summary: httplib: multiple Set-Cookie headers

Initial Comment:
httplib does not support multiple headers of the same 
name, because the headers are stored in a dictionary.

This causes a problem because an HTTP response can 
contain multiple "Set-Cookie".  

It is stated in RFC2109 - HTTP State Management 
Mechanism that "An origin server may include multiple 
Set-Cookie headers in a response. "

With the current python implementation, only the 
last "Set-Cookie" header is included in the headers 
dictionary, effectively meaning that the other cookies 
were lost.


----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2001-08-30 21:23

Message:
Logged In: YES 
user_id=6501

I've been using it for Expat, but that still isn't 
authoritative :-) Basically, I'm trying to suggest that the 
bug has been "accepted as a real bug" and will be 
addressed. Sort of a "started", if you will, rather than 
leaving it in the indeterminate Open/None 
status/resolution. When it gets fixed, the resolution will 
be "Fixed"

I kind of see it as a way to let the submitter know that 
their bug has been considered and acknowledged and will be 
fixed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 20:37

Message:
Logged In: YES 
user_id=6380

Greg: this is a new use of "Accepted" for me. We've only
used "Accepted" for accepted *patches*. Bugs to be fixed
simply remain open until they are fixed; I'm not sure I see
the value of changing the status. Were you innovating here,
or is this common usage in other projects?

----------------------------------------------------------------------

Comment By: Greg Stein (gstein)
Date: 2001-08-30 19:52

Message:
Logged In: YES 
user_id=6501

Use response.msg.getallmatchingheaders() as a workaround.

That said: the default operation of HTTPResponse.getheader
() should use the same, since HTTP headers can (by 
definition) use multiple headers. And HTTP defines a way to 
join those headers into one.

The solution here is to not return a list of header values 
(thus, breaking backwards compat), but to join them per the 
specification (with a ",").

I'm reclassifying this as an Accepted bug due to fix in 
Python 2.2.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-30 14:10

Message:
Logged In: YES 
user_id=12800

Please use RFC 2822 instead of 822 as the former has
replaced the latter. RFC 2822 describes the number of times
standard headers must or can appear in a mail message. 
AFAIK, rfc822.py does no such enforcement (and there are
good reasons to have both strict and lenient modes).  

My own mimelib (soon to be renamed and installed in the
standard library) accepts duplicates by keeping headers in a
list instead of a dictionary and searching the list linearly
for hits.  The speed advantages of a dictionary are probably
minimal for typical mail messages, so a linear search, which
preserves insertion order and duplicate order, is fine in
practice.

mimelib does not, but should have both a strict and lenient
mode where duplicates breaking the standard are either
allowed or flagged as errors.

----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 04:49

Message:
Logged In: YES 
user_id=88157

RFC 822-compliant mail messages frequently contain several
"Received-By:" headers. I cannot remember anything in the
standard which speaks to the general case. There may well 
be headers whose semantics require enforcement of 
the "There can be only one" variety, but equally some 
others must be treated the same as "Received-By:".

In so far as RFC 2616 [HTTP/1.1] says "Unrecognized header 
fields SHOULD be ignored by the recipient and MUST be 
forwarded by transparent proxies." (section 7.1: Entity 
header fields) this is an argument for being able to handle 
many unknown headers of the same type in the general case.

For correct processing it is therefore necessary to hold 
headers as lists, or in some other way which allows 
multiple headers of the same type. Fortunately there 
appears to be no need to emit headers in the same order 
they were seen in the original to preserve meaning.


----------------------------------------------------------------------

Comment By: Andrew Gaul (gaul)
Date: 2001-07-14 18:20

Message:
Logged In: YES 
user_id=139865

I'm willing to fix this, but I could use some clarification
of the relevant RFCs (822 and 2045). Do either of these
allow multiple headers with the same field names? I get the
impression from looking around in Google that reusing a
field is discouraged, but necessary for things like HTTP's
Set-Cookie header.

If one or both of the standards allow the above, I'll add an
optional argument (defaulting to the current behaviour) that
controls the handling of duplicate field names. If the flag
is passed, any field name having more than one value will
return the duplicate values in a list. For example:

foo: yes
bar: false
bar: true

will be returned as {foo: yes, bar: [false, true]}
as opposed to the old return value {foo: yes, bar: true}

HTTPResponse will always use this new behaviour, which may
break some programs that rely on the old behaviour.

Does anyone have comments before I code up this solution?
While I am concerned about breaking compatibility, it seems
like a correctness issue that headers aren't handled properly.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-03 23:01

Message:
Logged In: YES 
user_id=3066

Categorized as a feature request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432621&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 05:31:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 21:31:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-457100 ] httplib GET example should use host head
Message-ID: <E15cfy2-0005Y4-00@usw-sf-web2.sourceforge.net>

Bugs item #457100, was opened at 2001-08-30 21:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457100&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: httplib GET example should use host head

Initial Comment:
the POST example in httplib docs does use
a host: header, but the GET one does not.
people should probably always use a host header
these days as name-based virtual hosts are very
common, copying the example in the documentation
as is is likely to give surprises.

  -- erno@iki.fi

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457100&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 06:23:44 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 22:23:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-457066 ] pow(a,b,c) should accept b<0
Message-ID: <E15cgmO-0002NK-00@usw-sf-web1.sourceforge.net>

Bugs item #457066, was opened at 2001-08-30 18:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: pow(a,b,c) should accept b<0

Initial Comment:
You should be able to raise integers to negative powers
mod n.  If b<0, pow(a,b,c)==pow(pow(a,-1,c),-b,c)
where pow(a,-1,c) is a's multiplicative inverse mod c,
computed with the extended Euclid algorithm.  This
would be in Python's spirit of math completeness and
would save people from the trouble of having to figure
out the algorithm over and over.  

I can come up with a patch for this if it's agreed on
as desirable.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-30 22:23

Message:
Logged In: YES 
user_id=31435

The desire is understandable but this isn't the right way 
to do it, so I'm rejecting this.  While 2.2a2 changed the 
specifics, the general rule remains that

pow(a, b, c) == a**b % c

except that the LHS may be very much faster for large 
integer arguments.

"The right way" to do modular arithmetic is to define a 
class for it, and do the full job (+ - * /, not just 
modular pow).  egcd is easy to code in Python, and because 
it's an obscure speciality need (it gets asked about maybe 
twice per year on c.l.py) doesn't really belong in the core 
even if it weren't.  I'm not even sure how 3-argument pow 
got in, but am grateful it did and don't want to press our 
luck <wink>.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 18:49

Message:
Logged In: YES 
user_id=6380

Of course I meant (1.0/(a**-b))%c. Sorry!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-30 18:46

Message:
Logged In: YES 
user_id=6380

Hm.

In 2.2a2, currently, pow(a, b, c) for ints a, b, c where b <
0 is defined as pow(float(a), float(b), float(c)), IOW
(1.0/(a**b))%c. This doesn't make a lot of sense for the
three-argument version though, because the result tends to
be between 0.0 and 1.0...  But it is consistent with the
(future) rule that operations on integers and floats should
give results with the same value only a different type.

Assigning to Tim, whose mathematical sensibilities are more
refined than mine...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457066&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 06:48:27 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 30 Aug 2001 22:48:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E15chAJ-0006dT-00@usw-sf-web3.sourceforge.net>

Bugs item #457114, was opened at 2001-08-30 22:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 09:47:45 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 01:47:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-455537 ] module search in import.c
Message-ID: <E15cjxp-0005MG-00@usw-sf-web1.sourceforge.net>

Bugs item #455537, was opened at 2001-08-26 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: module search in import.c

Initial Comment:
I'm porting 2.1.1 to QNX6 and got the situation that the module 'os' could not
be be found with 'import os'

After some hacking with DDD .. I found out that the pathes used by the search
algorithm of import.c has nothing to do with the directory structure of the UNIX
distribution of Python 2.1.1 =:-/

I have installed Python in the root directory and set PYTHONHOME/PYTHONPATH to
/Python-2.1.1 -> the path to he library modules is then

                     -> /Python-2.1.1/Lib   OK ... that's not a clean place for UNIX freaks :)

The search algorithm of import.c is using the following search path sequence:

  "os.so"   -> I don't know why it should make sense to open
               a shared object with fopen ??
  "osmodule.so"
  "os.py"
  "os.pyc"

  "/Python-2.1.1/os.so" ... os.pyc

  "/Python-2.1.1/lib/python2.1/os.so" ... os.pyc
                ^^^^^^^^^^^^^^^ who got the idea that this is part of the 
                                                  UNIX tar.gz distribution ??

Also ... there are similar problems with the binaries installed by 'make install' ...

Armin

a-steinhoff@web.de

----------------------------------------------------------------------

>Comment By: Armin Steinhoff (arminsteinhoff)
Date: 2001-08-31 01:47

Message:
Logged In: YES 
user_id=64602


Hello Jeremy,

The location of the standard Phython libraries are valid for 
a binary installation ... but not for the structure of the 
source distribution, that means for the build process 
(setup.py).

For instance os.py is located in $(PYTHONHOME)/Lib and not 
in ${prefix}/lib/python<version> ! 

This creates an import error when setup.py will be executed.

.... and this is exactly the problem!

Armin 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-27 15:20

Message:
Logged In: YES 
user_id=31392

I'm not sure what the complaint is.  The man page for Python
is quite clear about what PYTHONHOME means:

Change the location of the standard Python libraries.  By
default, the
libraries are searched in ${prefix}/lib/python<version> and
${exec_prefix}/lib/python<version>, where ${prefix} and
${exec_prefix}
are installation-dependent directories, both defaulting to
\fI/usr/local\fP.  When $PYTHONHOME is set to a single
directory, its value
replaces both ${prefix} and ${exec_prefix}.  To specify
different values
for these, set $PYTHONHOME to ${prefix}:${exec_prefix}.

It sounds like Python is doing exactly what it is documented
to do.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 13:37:39 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 05:37:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-455537 ] module search in import.c
Message-ID: <E15cnYJ-0000T7-00@usw-sf-web1.sourceforge.net>

Bugs item #455537, was opened at 2001-08-26 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470

Category: Build
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Steinhoff (arminsteinhoff)
Assigned to: Nobody/Anonymous (nobody)
Summary: module search in import.c

Initial Comment:
I'm porting 2.1.1 to QNX6 and got the situation that the module 'os' could not
be be found with 'import os'

After some hacking with DDD .. I found out that the pathes used by the search
algorithm of import.c has nothing to do with the directory structure of the UNIX
distribution of Python 2.1.1 =:-/

I have installed Python in the root directory and set PYTHONHOME/PYTHONPATH to
/Python-2.1.1 -> the path to he library modules is then

                     -> /Python-2.1.1/Lib   OK ... that's not a clean place for UNIX freaks :)

The search algorithm of import.c is using the following search path sequence:

  "os.so"   -> I don't know why it should make sense to open
               a shared object with fopen ??
  "osmodule.so"
  "os.py"
  "os.pyc"

  "/Python-2.1.1/os.so" ... os.pyc

  "/Python-2.1.1/lib/python2.1/os.so" ... os.pyc
                ^^^^^^^^^^^^^^^ who got the idea that this is part of the 
                                                  UNIX tar.gz distribution ??

Also ... there are similar problems with the binaries installed by 'make install' ...

Armin

a-steinhoff@web.de

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 05:37

Message:
Logged In: YES 
user_id=6380

Ignoring your original message (which I didn't understand)
but clued in by your latest followup (which makes sense to
me):

The Unix and Windows getpath code accommodates this case
(running from the build directory) by noticing this and
choosing a different default path in that case. Maybe you
should do the same in your QNX port. The relevant code for
Unix is in Modules/getpath.c (not in import.c, which is one
of the reasons why your initial message threw me off).

Regarding the search algorithm: it uses fopen() to detect
existence of the file. Read the source and it will be clear
to you: it has a table of suffixes to try. I don't
understand your remark "who got the idea that this is part
of the UNIX tar.gz distribution ??" My feeling is that
you're jumping to conclusions based on insufficient
knowledge, which makes it hard to argue. :-)

----------------------------------------------------------------------

Comment By: Armin Steinhoff (arminsteinhoff)
Date: 2001-08-31 01:47

Message:
Logged In: YES 
user_id=64602


Hello Jeremy,

The location of the standard Phython libraries are valid for 
a binary installation ... but not for the structure of the 
source distribution, that means for the build process 
(setup.py).

For instance os.py is located in $(PYTHONHOME)/Lib and not 
in ${prefix}/lib/python<version> ! 

This creates an import error when setup.py will be executed.

.... and this is exactly the problem!

Armin 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-08-27 15:20

Message:
Logged In: YES 
user_id=31392

I'm not sure what the complaint is.  The man page for Python
is quite clear about what PYTHONHOME means:

Change the location of the standard Python libraries.  By
default, the
libraries are searched in ${prefix}/lib/python<version> and
${exec_prefix}/lib/python<version>, where ${prefix} and
${exec_prefix}
are installation-dependent directories, both defaulting to
\fI/usr/local\fP.  When $PYTHONHOME is set to a single
directory, its value
replaces both ${prefix} and ${exec_prefix}.  To specify
different values
for these, set $PYTHONHOME to ${prefix}:${exec_prefix}.

It sounds like Python is doing exactly what it is documented
to do.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=455537&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 14:10:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 06:10:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E15co49-0003YM-00@usw-sf-web2.sourceforge.net>

Bugs item #457114, was opened at 2001-08-30 22:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 06:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 20:13:55 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 12:13:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-457360 ] Nested scopes crash when tracing (v2.1)
Message-ID: <E15ctjn-0000Ki-00@usw-sf-web2.sourceforge.net>

Bugs item #457360, was opened at 2001-08-31 12:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457360&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan R.A. Deibel (sdeibel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested scopes crash when tracing (v2.1)

Initial Comment:
Python will crash on post-trace processing if
the tracer is installed during a class def nested
inside of a nest function def, under certain conditions
at least.

I tried to make a small test case but that didn't bring
out the bug.

As a result, this is best illustrated by installing
Zope 2.4.0 (I did this on Linux) and altering z2.py by
inserting the following near the top of the file:

def tracer(*args):
  print "trace"
  return tracer
import sys
sys.settrace(tracer)

Then run with the './start' command.  Python will 
segfault during the following around line 570
of z2.py:

exec "import "+MODULE in {}

The real problem is the LocalsToFast() call after
the tracer has been called while the interpreter is
doing the 'line' tracing for line 118 of
libs/python/RestrictedPython/Gaurds.py in Zope, where
"class Wrapper" is defined nested inside of a nested
function.

The innermost part of the C backtrace is:

#0  PyCell_Set (op=0x0, obj=0x8322e04) at
Objects/cellobject.c:32
(gdb) up
#1  0x808068a in dict_to_map (map=0x81d5cc4, nmap=1,
dict=0x81d269c, 
    values=0x8195db0, deref=1, clear=1) at
Objects/frameobject.c:287
(gdb) up
#2  0x8080903 in PyFrame_LocalsToFast (f=0x8195c68,
clear=1)
    at Objects/frameobject.c:371
(gdb) up
#3  0x80587e3 in call_trace (p_trace=0x8195c88,
p_newtrace=0x8195c88, 
    f=0x8195c68, msg=0x809c3a2 "line", arg=0x80b5c0c)
at Python/ceval.c:2595

I tested this under RedHat 6.1 with Python 2.1 (both
the copy that comes with Zope and one I built from
source with debug symbols).

For more info, contact via email: info at wingide.com.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457360&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 20:57:42 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 12:57:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter
Message-ID: <E15cuQA-0000xE-00@usw-sf-web2.sourceforge.net>

Bugs item #221327, was opened at 2000-11-03 12:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: threads within an embedded python interpreter

Initial Comment:
I have an application which I am required to embedd a python interpreter inside of a C++ application. The python script creates a separate thread of control to handle a TCP/IP socket connection. The thread can send data just find but hangs on the socket 'recv' fnction.

After a dya of debugging my code I went into the python socketmodule.c and at line 1082 I commented out the thread protection code:

/*Py_BEGIN_ALLOW_THREADS*/
n = recv(s->sock_fd, PyString_AsString(buf), len, flags);
/*Py_END_ALLOW_THREADS*/

I then recompiled the python library and then recompiled my C++ app and everything worked just fine.

The problem does not exist when I run the script alone using the python interpreter. Only when I embedd the interpreter, so this is some sort of configuration issue.

David Schere
Email: david_schere@yahoo.com





----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-31 12:57

Message:
Logged In: NO 

Now u pay,.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-03 12:44

Message:
Most likely, the problem is not the socket module but how you call Python code from a thread that was started from C/C++. Look at t_bootstrap() in threadmodule.c for an example on what to do. (And yes, it's tricky.) There should also be something in the Python/C API documentation about this.

I'm not closing the bug report since this is really a documentation issue; it needs to be documented better. I'll assign it to Fred.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221327&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 21:40:33 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 13:40:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-457399 ] bisect module broken in 2.1.1 ?
Message-ID: <E15cv5d-0001mG-00@usw-sf-web3.sourceforge.net>

Bugs item #457399, was opened at 2001-08-31 13:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457399&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Mahler (dmahler)
Assigned to: Nobody/Anonymous (nobody)
Summary: bisect module broken in 2.1.1 ?

Initial Comment:
given the function:

def findClause(C, SS):
    for j in range(1,len(SS)):
        assert SS[j-1] <= SS[j], (j, SS[j-1], SS[j])
    C2 = map(abs, C)
    i = bisect.bisect_left(C2, SS)
    assert C2 >= SS[i], (i, C, C2, [C3 for C3 in SS if
C3 <= C2], SS[0:4])
    return i

I get:

    i = findClause(C, SS)
  File "/home/mahler/code/scripts/oshl.py", line 248,
in findClause
    assert C2 >= SS[i], (i, C, C2, [C3 for C3 in SS if
C3 <= C2], SS[0:4])
AssertionError: (3, [5, -2, 1], [5, 2, 1], [], [[5, 3,
1], [5, 3, 2], [6, 4, 2], [7, 3, 2]])

As far as I can tell this must be a bug:
the first loop ensures that the list is sorted.
It is the bottom asertion that is throwing the
exception
The values returned with the exception show that we
were
looking for an element smaller than any in the list.
I would therefore expect 0 to be returned,
but I get 3.

Daniel Mahler
mahler@cyc.com

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457399&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 22:05:04 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 14:05:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-457399 ] bisect module broken in 2.1.1 ?
Message-ID: <E15cvTM-0001tA-00@usw-sf-web2.sourceforge.net>

Bugs item #457399, was opened at 2001-08-31 13:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457399&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Daniel Mahler (dmahler)
>Assigned to: Tim Peters (tim_one)
Summary: bisect module broken in 2.1.1 ?

Initial Comment:
given the function:

def findClause(C, SS):
    for j in range(1,len(SS)):
        assert SS[j-1] <= SS[j], (j, SS[j-1], SS[j])
    C2 = map(abs, C)
    i = bisect.bisect_left(C2, SS)
    assert C2 >= SS[i], (i, C, C2, [C3 for C3 in SS if
C3 <= C2], SS[0:4])
    return i

I get:

    i = findClause(C, SS)
  File "/home/mahler/code/scripts/oshl.py", line 248,
in findClause
    assert C2 >= SS[i], (i, C, C2, [C3 for C3 in SS if
C3 <= C2], SS[0:4])
AssertionError: (3, [5, -2, 1], [5, 2, 1], [], [[5, 3,
1], [5, 3, 2], [6, 4, 2], [7, 3, 2]])

As far as I can tell this must be a bug:
the first loop ensures that the list is sorted.
It is the bottom asertion that is throwing the
exception
The values returned with the exception show that we
were
looking for an element smaller than any in the list.
I would therefore expect 0 to be returned,
but I get 3.

Daniel Mahler
mahler@cyc.com

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-08-31 14:05

Message:
Logged In: YES 
user_id=31435

It looks like you passed arguments to bisect in the wrong 
order.  Try

i = bisect.bisect_left(SS, C2)

instead.  As is, you're looking for the position within 
list [5, 2, 1] to insert element SS (the opposite of what I 
expect you intended), and since any list *happens to* 
compare greater than any integer in 2.1, the list SS 
belongs at position C2[3].

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457399&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 23:04:08 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 15:04:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-457431 ] '-' character breaks exception handling
Message-ID: <E15cwOW-00018H-00@usw-sf-web1.sourceforge.net>

Bugs item #457431, was opened at 2001-08-31 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: '-' character breaks exception handling

Initial Comment:
Catching a string based exception containing a '-' 
character that was raised within a function call 
cannot be explicitly caught. Example :

>>> def test() :
... 	raise 'Lock-Removed'
... 
>>> try :
... 	test()
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Traceback (most recent call last):
  File "<interactive input>", line 2, in ?
  File "<interactive input>", line 2, in test
Lock-Removed
>>> try :
... 	raise 'Lock-Removed'
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Caught it!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 23:07:37 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 15:07:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-457431 ] '-' character breaks exception handling
Message-ID: <E15cwRt-0002jf-00@usw-sf-web2.sourceforge.net>

Bugs item #457431, was opened at 2001-08-31 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: '-' character breaks exception handling

Initial Comment:
Catching a string based exception containing a '-' 
character that was raised within a function call 
cannot be explicitly caught. Example :

>>> def test() :
... 	raise 'Lock-Removed'
... 
>>> try :
... 	test()
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Traceback (most recent call last):
  File "<interactive input>", line 2, in ?
  File "<interactive input>", line 2, in test
Lock-Removed
>>> try :
... 	raise 'Lock-Removed'
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Caught it!



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-31 15:07

Message:
Logged In: NO 

Found on version 1.5.2 and 2.1.1 on Windows NT 4.0 
w/Service Pack 6a.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470


From noreply@sourceforge.net  Fri Aug 31 23:10:26 2001
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 31 Aug 2001 15:10:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-457431 ] '-' character breaks exception handling
Message-ID: <E15cwUc-0001FA-00@usw-sf-web1.sourceforge.net>

Bugs item #457431, was opened at 2001-08-31 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: '-' character breaks exception handling

Initial Comment:
Catching a string based exception containing a '-' 
character that was raised within a function call 
cannot be explicitly caught. Example :

>>> def test() :
... 	raise 'Lock-Removed'
... 
>>> try :
... 	test()
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Traceback (most recent call last):
  File "<interactive input>", line 2, in ?
  File "<interactive input>", line 2, in test
Lock-Removed
>>> try :
... 	raise 'Lock-Removed'
... except 'Lock-Removed' :
... 	print 'Caught it!'
... 
Caught it!



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 15:10

Message:
Logged In: YES 
user_id=6380

Not a bug. Check the docs: string exceptions must be caught
by name, not by value. That it usually works is an accident
of implementation, and cannot be trusted across modules.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-31 15:07

Message:
Logged In: NO 

Found on version 1.5.2 and 2.1.1 on Windows NT 4.0 
w/Service Pack 6a.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457431&group_id=5470