From noreply@sourceforge.net  Fri Mar  1 08:46:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 00:46:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop
Message-ID: <E16gig7-0003Og-00@usw-sf-web2.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: bixentxo (bixentxo)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: cPickle / time.struct_time loop

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-01 08:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 13:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 20:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 18:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 16:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 14:06

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 11:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

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

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Fri Mar  1 12:22:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 04:22:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X
Message-ID: <E16gm3u-00065h-00@usw-sf-web2.sourceforge.net>

Bugs item #508779, was opened at 2002-01-26 04:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508779&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Manoj Plakal (terabaap)
Assigned to: Michael Hudson (mwh)
Summary: Disable flat namespace on MacOS X

Initial Comment:

Python: v2.2
OS: MacOS X 10.1

MacOS X 10.1 introduced two forms of linking
for loadable modules: flat namespace and
two-level namespace. 

Python 2.2 is set up to use flat namespace
by default on OS X for building extension modules.

I believe that this is a problem since
it introduces spurious run-time linking
errors when loading 2 or more modules that 
happen to have common symbols. The Linux
and Windows implementations do not allow
symbols within modules to clash with
each other. This behavior also goes against
expectations of C extension module writers.

As a reproducible example, consider
two dummy modules foo (foomodule.c)
and bar (barmodule.c) both of which
are built with a common file baz.c
that contains some data variables.
With the current Python 2.2 on OS X 10.1,
only one of foo or bar can be imported,
but NOT BOTH, into the same interpreter
session.

The files can be picked up from
these URLs:
    http://yumpee.org/python/foomodule.c
    http://yumpee.org/python/barmodule.c
    http://yumpee.org/python/baz.c
    http://yumpee.org/python/setup.py

If I run "python setup.py build" with
Python 2.2 (built from the 2.2
source tarball) and then import
foo followed by bar, I get an
ImportError: "Failure linking new
module" (from Python/dynload_next.c).
If I add a call to NSLinkEditError()
to print a more detailed error message,
I see that the problem is multiple definitions
of the data variables in baz.c.

The above example works fine with Python 2.1
on Red Hat Linux 7.2 and Python 2.2a4 on Win98.

If I then edit /usr/local/lib/python2.2/Makefile
and change LDSHARED and BLDSHARED to
not use flat_namespace:
$(CC) $(LDFLAGS) -bundle -bundle_loader
/usr/local/bin/python2.2 -undefined error
then the problem is solved and I can load
both foo and bar without problems.

More info and discussion is available at
these URLs (also search groups.google.com
for "comp.lang.python OS X import bug"):

http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python
http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html

It would be great to have this simple
change be applied to Python 2.2.1.

Manoj 
terabaap@yumpee.org


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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-01 13:22

Message:
Logged In: YES 
user_id=45365

Here's a new version of the patch, against the current state of the tree (the whitespace normalization messed it up).

And I've now tested it against Manoj's example and it works fine, so I would say we go for it.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-01 00:25

Message:
Logged In: YES 
user_id=45365

I turns out I was mistaken: BLDSHARED is used during build, LDSHARED for distutils when Python is installed. Attached is a patch (relative to release22-maint) that does two level namespaces.

It has no adverse effects on the core (i.e. make test still works fine).

Manoj: if you could test that this not only has on adverse effects but also fixes your problem that would be great. please checkout th release22-maint branch and apply this patch.

Michael: I'm assigning this to you, feel free to check it in immediately or wait for feedback from Manoj (or ignore it completely if you don't like it:-).

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 17:19

Message:
Logged In: YES 
user_id=45365

This solution still suffers from the problem we discussed on the Pythonmac-SIG, that BLDSHARED (or whatever replaces it) would need to have one value for -bundle_loader when building the standard extension modules and another during "normal operation"...

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 12:21

Message:
Logged In: YES 
user_id=45365

I usurping this bug, but I'm not sure yet whether it's a good idea to fix this for 2.2.1, as it will break other extension modules that rely on the single flat namespace.

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

Comment By: Manoj Plakal (terabaap)
Date: 2002-01-26 05:25

Message:
Logged In: YES 
user_id=150105


Another idea is to provide the option for
flat or 2-level namespace when building
extension modules on OS X, maybe as 
an extra flag passed to distutils.core.Extension
or somewhere else ...


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

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


From noreply@sourceforge.net  Fri Mar  1 13:11:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 05:11:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-517447 ] Syntax error in tixwidgets.py
Message-ID: <E16gmoc-0006Yu-00@usw-sf-web2.sourceforge.net>

Bugs item #517447, was opened at 2002-02-14 06:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517447&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Detlef Lannert (lannert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Syntax error in tixwidgets.py

Initial Comment:
tixwidgets.py reports a syntax error; the following
patch helps:
*** .../Demo/tix/tixwidgets.py.orig     Sun Nov 25
15:50:55 2001
--- .../Demo/tix/tixwidgets.py  Thu Feb 14 11:59:47
2002
***************
*** 135,142 ****
          import tkMessageBox, traceback
          while self.exit < 0:
              try:
!         while self.exit < 0:
!             self.root.tk.dooneevent(TCL_ALL_EVENTS)
              except SystemExit:
                  #print 'Exit'
                  self.exit = 1
--- 135,141 ----
          import tkMessageBox, traceback
          while self.exit < 0:
              try:
!                
self.root.tk.dooneevent(TCL_ALL_EVENTS)
              except SystemExit:
                  #print 'Exit'
                  self.exit = 1

(I.e., delete the extra while and indent the
dooneevent call.)

This is for Python 2.2, but the version from CVS
looks just the same.

BTW, when I select the Directory Listing pane, the
application freezes (with a "busy" cursor); I don't
know why (yet).

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:11

Message:
Logged In: YES 
user_id=33168

The syntax error has been fixed in 1.5 and 1.4.6.1.
If there is another bug, please open a new bug report.

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

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


From noreply@sourceforge.net  Fri Mar  1 13:18:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 05:18:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile()  coredumps
Message-ID: <E16gmvO-0006bs-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sys.setprofile()  coredumps

Initial Comment:
Verified in current CVS (also on Windows, but doubt 
the platform matters).  It's not the call proper that 
coredumps, but an eval loop's later attempt to use a 
resulting NULL pointer.  From c.l.py:

"""
From: rihad
Sent: Monday, January 21, 2002 1:19 PM
Subject: minor Python bugs

Calling sys.setprofile() (with no args) makes the 
interpreter crash, and calling sys.settrace() with no 
args succeeds, even though it is documented to take 1 
arg (tracefunc).

And yes, my version is '2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)]'
"""

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:17

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 16:46

Message:
Logged In: YES 
user_id=33168

What is the appropriate behaviour for settrace()?
Currently, it is the same as settrace(None) which
disables the trace function.

So is the doc correct or is the code correct?

I can supply another patch to doc/code for settrace()
depending on which needs to be changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 15:24

Message:
Logged In: YES 
user_id=33168

I didn't read the part that settrace was a problem.
I can take a look at the settrace problem later.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 15:02

Message:
Logged In: YES 
user_id=21627

It appears that this patches deals only with the setprofile
problem, not with the settrace problem. Is that intentional?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 17:39

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.
The patch includes a test.

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

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


From noreply@sourceforge.net  Fri Mar  1 13:18:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 05:18:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile()  coredumps
Message-ID: <E16gmvX-0006cS-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sys.setprofile()  coredumps

Initial Comment:
Verified in current CVS (also on Windows, but doubt 
the platform matters).  It's not the call proper that 
coredumps, but an eval loop's later attempt to use a 
resulting NULL pointer.  From c.l.py:

"""
From: rihad
Sent: Monday, January 21, 2002 1:19 PM
Subject: minor Python bugs

Calling sys.setprofile() (with no args) makes the 
interpreter crash, and calling sys.settrace() with no 
args succeeds, even though it is documented to take 1 
arg (tracefunc).

And yes, my version is '2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)]'
"""

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:18

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:17

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 16:46

Message:
Logged In: YES 
user_id=33168

What is the appropriate behaviour for settrace()?
Currently, it is the same as settrace(None) which
disables the trace function.

So is the doc correct or is the code correct?

I can supply another patch to doc/code for settrace()
depending on which needs to be changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 15:24

Message:
Logged In: YES 
user_id=33168

I didn't read the part that settrace was a problem.
I can take a look at the settrace problem later.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 15:02

Message:
Logged In: YES 
user_id=21627

It appears that this patches deals only with the setprofile
problem, not with the settrace problem. Is that intentional?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 17:39

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.
The patch includes a test.

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

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


From noreply@sourceforge.net  Fri Mar  1 14:04:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 06:04:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile()  coredumps
Message-ID: <E16gneR-0007Ap-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sys.setprofile()  coredumps

Initial Comment:
Verified in current CVS (also on Windows, but doubt 
the platform matters).  It's not the call proper that 
coredumps, but an eval loop's later attempt to use a 
resulting NULL pointer.  From c.l.py:

"""
From: rihad
Sent: Monday, January 21, 2002 1:19 PM
Subject: minor Python bugs

Calling sys.setprofile() (with no args) makes the 
interpreter crash, and calling sys.settrace() with no 
args succeeds, even though it is documented to take 1 
arg (tracefunc).

And yes, my version is '2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)]'
"""

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-01 14:04

Message:
Logged In: YES 
user_id=6656

Certainly.  Setting group so this doesn't get forgotten.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 13:18

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 13:17

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 21:46

Message:
Logged In: YES 
user_id=33168

What is the appropriate behaviour for settrace()?
Currently, it is the same as settrace(None) which
disables the trace function.

So is the doc correct or is the code correct?

I can supply another patch to doc/code for settrace()
depending on which needs to be changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 20:24

Message:
Logged In: YES 
user_id=33168

I didn't read the part that settrace was a problem.
I can take a look at the settrace problem later.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 20:02

Message:
Logged In: YES 
user_id=21627

It appears that this patches deals only with the setprofile
problem, not with the settrace problem. Is that intentional?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 22:39

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.
The patch includes a test.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:26:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:26:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-506679 ] Core dump subclassing long
Message-ID: <E16gvTl-00031L-00@usw-sf-web3.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nicholas Socci (nsocci)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Core dump subclassing long

Initial Comment:
The following code dumps core:

class C(long):
    pass

c=C(-1)


Note if running interactly the core dump occurs when 
you quit the interpreter. No problem for positive 
numbers of if subclassing int or float.

Version information:

Python 2.2 (#1, Dec 28 2001, 14:02:28)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on 
linux2



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:26

Message:
Logged In: YES 
user_id=6380

Fixed, using the patch pointed out by Neal Norwitz.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-02-08 08:19

Message:
Logged In: YES 
user_id=33168

There was a patch submitted for this problem:
#514641.

https://sourceforge.net/tracker/?func=detail&atid=305470&aid=514641&group_id=5470

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-21 18:24

Message:
Logged In: YES 
user_id=6380

Alas, you're right. I suspect a calculation error in the
size of the long.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 17:41

Message:
Logged In: YES 
user_id=33168

Here's a stack trace.

#0  subtype_dealloc (self=0x818598c) at Objects/typeobject.c:349
#1  0x080c33cc in PyDict_SetItem (op=0x810b8fc,
key=0x812a388, value=0x80ddc3c)
    at Objects/dictobject.c:373
#2  0x080c6189 in _PyModule_Clear (m=0x810b734) at
Objects/moduleobject.c:124
#3  0x0808a5d1 in PyImport_Cleanup () at Python/import.c:284
#4  0x08092f1e in Py_Finalize () at Python/pythonrun.c:231
#5  0x080534a6 in Py_Main (argc=1, argv=0xbffff914) at
Modules/main.c:376
#6  0x40087507 in __libc_start_main (main=0x8052d70 <main>,
argc=1, 
    ubp_av=0xbffff914, init=0x8052194 <_init>,
fini=0x80ca4c0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff90c)
    at ../sysdeps/generic/libc-start.c:129


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

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


From noreply@sourceforge.net  Fri Mar  1 22:29:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:29:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-210637 ] ihooks on windows and pythoncom (PR#294)
Message-ID: <E16gvX9-0001Xw-00@usw-sf-web1.sourceforge.net>

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

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: ihooks on windows and pythoncom (PR#294)

Initial Comment:
Jitterbug-Id: 294
Submitted-By: mak@mikroplan.com.pl
Date: Thu, 13 Apr 2000 04:09:35 -0400 (EDT)
Version: cvs
OS: windows


Hi,

Python module ihooks is not so compatible with builtin imp while importing
modules whose name is stored in registry eg. pythoncom/pywintypes.

import ihooks
ihooks.install()
import pythoncom

This code will fail inside pythonwin ide too !




====================================================================
Audit trail:
Tue Jul 11 08:29:17 2000	guido	moved from incoming to open

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:29

Message:
Logged In: YES 
user_id=31392

Mark,

Any interest in looking at this bug?  It holds the record 
for the oldest Python bug at SF.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 15:13

Message:
Logged In: NO 

i try it first,ok


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-15 23:19

Message:
Logged In: NO 

¾È³çÇϼ¼¿ä

ÀÌÁ¦ºÎÅÍ Á¦ ¼Ò°³¸¦ ÇÏ°Ú½À´Ï´Ù

ÀúÀÇ À̸§Àº ¹ÚÇýÁØ ÀÌ°í¿ä

³ªÀÌ´Â 13»ìÀÌ¿¡¿ä

±×¸®°í °¡Á·Àº ¸ðµÎ 4¸í

¾ö¸¶ ¾Æºü ´©³ª ³ª

Á¦°¡ »ç´Â °÷Àº ºÐ´ç±¸ ¾ßžµ¿ ¸ÅÈ­¸¶À» 105-1006

Á¦ ÀüÈ­¹øÈ£´Â¿© 031-704-9838

Àú´Â Çѱ¹ÀÎ ÀÔ´Ï´Ù.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-09-19 17:23

Message:
Logged In: NO 

ruoy retupmoc si daed

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

Comment By: Grzegorz Makarewicz (mpmak)
Date: 2001-03-02 12:27

Message:
Logged In: YES 
user_id=141704

BasicModuleLoader.find_module_in_dir is searching for main 
modules only in frozen and builtin. The imp searches the 
registry, too.

ModuleLoader.find_module_in_dir should call the functions 
from the inherited object.

so this patch should help:
--- V:\py21\Lib\ihooks.py	Mon Feb 12 08:55:46 2001
+++ ihooks.py	Sun Feb 18 04:39:39 2001
@@ -122,8 +122,13 @@
 
     def find_module_in_dir(self, name, dir):
         if dir is None:
-            return self.find_builtin_module(name)
-        else:
+            result = self.find_builtin_module(name)
+            if result is not None:
+                return result
+            try:
+                return imp.find_module(name, None)
+            except:
+                return None
             try:
                 return imp.find_module(name, [dir])
             except ImportError:
@@ -237,7 +242,7 @@
 
     def find_module_in_dir(self, name, dir, 
allow_packages=1):
         if dir is None:
-            return self.find_builtin_module(name)
+            return BasicModuleLoader.find_module_in_dir
(self,name,dir)
         if allow_packages:
             fullname = self.hooks.path_join(dir, name)
             if self.hooks.path_isdir(fullname):


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

Comment By: Mark Hammond (mhammond)
Date: 2000-08-31 06:23

Message:
Leaving open, but moving down the priority and resolution lists.  A patch would help bump it back up :-)

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

Comment By: Mark Hammond (mhammond)
Date: 2000-08-14 06:42

Message:
This needs a resolution.  The "registered module" code in the code also needs to support HKEY_CURRENT_USER along with the HKEY_LOCAL_MACHINE it does now.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:30:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:30:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E16gvYA-0001Yw-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: Later
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 14:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 14:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:31:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:31:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16gvZF-0001Zv-00@usw-sf-web1.sourceforge.net>

Bugs item #216388, was opened at 2000-10-09 00:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: Later
>Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-17 02:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 16:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

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

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

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 21:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 08:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


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

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


From noreply@sourceforge.net  Fri Mar  1 22:32:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:32:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-217195 ] Broken \ref link in documentation
Message-ID: <E16gvZj-0001av-00@usw-sf-web1.sourceforge.net>

Bugs item #217195, was opened at 2000-10-18 18:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=217195&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: Broken \ref link in documentation

Initial Comment:
[Report received by python-docs.]

From: Roy Smith <rsmith@micromuse.com>
Date: Wed, 18 Oct 2000 14:45:25 -0700

On the page http://www.python.org/doc/current/ref/exceptions.html, if I
click on the link for secion 7.4
(http://www.python.org/doc/current/ref/node83.html#try), I get an Error
404: file not found.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:32

Message:
Logged In: YES 
user_id=31392

Was it a LaTeX2HTML bug or not?


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-30 00:51

Message:
Logged In: NO 

ergdfvgdfdfgsdgff

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-12-12 21:54

Message:
I'll note that I think this is a LaTeX2HTML bug, but I need to spend some time digging into the \ref{} handling.  It seems to have other problems as well.  ;-(

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

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


From noreply@sourceforge.net  Fri Mar  1 22:33:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:33:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-219486 ] fcntl.lockf() is broken
Message-ID: <E16gvai-0001bb-00@usw-sf-web1.sourceforge.net>

Bugs item #219486, was opened at 2000-10-26 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=219486&group_id=5470

Category: Extension Modules
Group: Not a Bug
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Gregor Hoffleit (flight)
Assigned to: Guido van Rossum (gvanrossum)
Summary: fcntl.lockf() is broken

Initial Comment:
Another observation by James Troup <troup@debian.org>: fcntl.lockf()
seems to be severly `broken': it's acting like flock, not like lockf, 
and the code seems to be a copy/paste of flock.
(registered in the Debian Bug Tracking System as bug #74777,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=74777).

James includes a first start at filling in a correct lockf function.
Looks like it needs some more work, therefore I don't submit it as
patch. The patch is against 1.5.2, though there seem to be no changes in 2.0.

These are James' words:


fcntl.lockf() doesn't work as expected.  

        fcntl.lockf(fd, FCNTL.F_TLOCK);

will block.. looking at the source is exteremly confusing.
fcntl.lockf() appears to want flock() style arguments?!  It almost
looks like someone cut'n'wasted from the fcntl_flock() function just
above...

Anyway, here is a patch which is IMO the Right Thing,
i.e. fcnt.lockf() acting like libc lockf() and like it's documented to
do...

--- python-1.5.2/Modules/fcntlmodule.c.orig     Sat Oct 14 15:46:40 2000
+++ python-1.5.2/Modules/fcntlmodule.c  Sat Oct 14 18:31:44 2000
@@ -233,30 +233,12 @@
 {
        int fd, code, ret, whence = 0;
        PyObject *lenobj = NULL, *startobj = NULL;
+       struct flock l;
 
        if (!PyArg_ParseTuple(args, "ii|OOi", &fd, &code,
                              &lenobj, &startobj, &whence))
            return NULL;
 
-#ifndef LOCK_SH
-#define LOCK_SH                1       /* shared lock */
-#define LOCK_EX                2       /* exclusive lock */
-#define LOCK_NB                4       /* don't block when locking */
-#define LOCK_UN                8       /* unlock */
-#endif
-       {
-               struct flock l;
-               if (code == LOCK_UN)
-                       l.l_type = F_UNLCK;
-               else if (code & LOCK_SH)
-                       l.l_type = F_RDLCK;
-               else if (code & LOCK_EX)
-                       l.l_type = F_WRLCK;
-               else {
-                       PyErr_SetString(PyExc_ValueError,
-                                       "unrecognized flock argument");
-                       return NULL;
-               }
                l.l_start = l.l_len = 0;
                if (startobj != NULL) {
 #if !defined(HAVE_LARGEFILE_SUPPORT)
@@ -281,10 +263,48 @@
                                return NULL;
                }
                l.l_whence = whence;
+       switch (code)
+         {
+         case F_TEST:
+           /* Test the lock: return 0 if FD is unlocked or locked by this process;
+              return -1, set errno to EACCES, if another process holds the lock.  */
+           if (fcntl (fd, F_GETLK, &l) < 0) {
+             fprintf(stderr, "andrea: 1");
+             PyErr_SetFromErrno(PyExc_IOError);
+             return NULL;
+           }
+           if (l.l_type == F_UNLCK || l.l_pid == getpid ()) {
+             fprintf(stderr, "andrea: 2");
+             Py_INCREF(Py_None);
+             return Py_None;
+           }
+           fprintf(stderr, "andrea: 3");
+           errno = EACCES;
+           PyErr_SetFromErrno(PyExc_IOError);
+           return NULL;
+
+         case F_ULOCK:
+           l.l_type = F_UNLCK;
+           code = F_SETLK;
+           break;
+         case F_LOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLKW;
+           break;
+         case F_TLOCK:
+           l.l_type = F_WRLCK;
+           code = F_SETLK;
+           break;
+           
+         default:
+           PyErr_SetString(PyExc_ValueError,
+                           "unrecognized flock argument");
+           return NULL;
+         }
                Py_BEGIN_ALLOW_THREADS
-               ret = fcntl(fd, (code & LOCK_NB) ? F_SETLK : F_SETLKW, &l);
+         ret = fcntl(fd, code, &l);
                Py_END_ALLOW_THREADS
-       }
+
        if (ret < 0) {
                PyErr_SetFromErrno(PyExc_IOError);
                return NULL;



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-21 04:36

Message:
Logged In: YES 
user_id=6380

doko, what's going on here? I don't appreciate your
inserting foul language in our tracker.

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

Comment By: Matthias Klose (doko)
Date: 2001-12-21 00:38

Message:
Logged In: YES 
user_id=60903

[repeat a final (?) comment from the bug submitter. please 
CC 74777-submitter@bugs.debian.org on replies.

74777-submitter writes:

So...

Executive summary:

 o yes, python's lockf() is fucked

 o no, there's not a good reason for it, just the lame ass 
excuse that
   they were tying to make things easier (??)

 o No, they won't fix it because that would mean breaking 
backward
   compatibility (?? from the people who are changing the 
meaning of /
   ??)

Conclusion:

  o python upstream sucks hairy mammoths.

Bah!  Anyway, thanks for chasing this up Matthias, feel 
free to close
the bug, I guess I'll just have to work around upstream 
stupidity.


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

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

Message:
Logged In: YES 
user_id=6380

I've looked into this, and I finally have an idea what's the
matter here.

The similarity with flock is intentional; the lockf and
flock calls are an abstraction level away from the fcntl
locking call.  By using the same arguments in both cases we
hoped to make things easier for the Python user.

We may not have succeeded there, but I prefer to document
the status quo over "fixing" the interface and breaking code
that uses it.

Therefore, I'm rejecting the patch.  The documentation has
been updated, see the working docs:

http://python.sourceforge.net/devel-docs/lib/module-fcntl.html


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-01-19 03:37

Message:
I apologize. I should've looked into this earlier.  Now I won't have time to look at it before releasing 2.1a1.  I promise I'll come back to it later.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2000-12-20 01:19

Message:
Note that the docs say that lockf "is a wrapper around the \constant{FCNTL.F_SETLK} and
\constant{FCNTL.F_SETLKW} \function{fcntl()} calls."  Stevens's 
"Advanced Programming in the Unix Env." concurs, on page 367: "The System V lockf() is just an interface to fcntl()."

However, none of us are serious Unix weenies.   Unfortunately, the documented Python lockf() provides features above the libc lockf(), so
using the system lockf() seems impossible unless we break backwards compatibility.   Unfortunately none of us are serious Unix weenies, so writing a lockf() emulation that's completely correct everywhere might be very difficult.

Troup's patch attempts to fix the emulation; I haven't looked at it closely.  I'd suggest breaking backwards compatibility; if that's out, 
we should take a close look at the patch.  


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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2000-11-24 09:32

Message:
Yeah, I looked at it.  In 1996.  I don't think I looked at flock since then.
Anyway, it compiles on my system (IRIX 6.5.2), and I don't think I will have time in the near future to look any further into this.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-26 21:29

Message:
Sjoerd, you once looked at this code. Can you comment on this? If you don't have time, please assign back to me.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:34:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:34:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter
Message-ID: <E16gvbg-0001cU-00@usw-sf-web1.sourceforge.net>

Bugs item #221327, was opened at 2000-11-03 20: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: 5
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: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:34

Message:
Logged In: YES 
user_id=31392

Probably ought to fix this for 2.3


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-31 19:57

Message:
Logged In: NO 

Now u pay,.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-03 20: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 Mar  1 22:35:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:35:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-221791 ] Error for bad \x escape doesn't mention filename
Message-ID: <E16gvcq-0001dX-00@usw-sf-web1.sourceforge.net>

Bugs item #221791, was opened at 2000-11-06 16:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221791&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: Error for bad \x escape doesn't mention filename

Initial Comment:
Using:

GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I get the following 'error' message:

    from interscript.languages.interscript_languages import add_translation
  File "interscript/languages/interscript_languages.py", line 2, in ?
    from interscript.encoding.utf8 import utf8
ValueError: invalid \x escape

in known correct code (i.e. it works on Python 1.5.2).

I have examined the function 'parsestr' in
'compile.c', and added debugging prints to find out
what is going on. The function _correctly_ processes
the string 'utf8' (quotes included), and returns,
then the error is generated _without_ entering
the routine!

This almost certainly must be a bug in egcs-2.91.66. 
The code in 'parsestr' looks correct to me.

It is possible the error can be replicated by
downloading and running 'interscript' (without
any arguments). Interscript is available at

	http://interscript.sourceforge.net

[Reply to skaller@maxtal.com.au, sorry, I couldn't
figure out how to 'log on']


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:35

Message:
Logged In: YES 
user_id=31392

Tim, it looks like someone else has tackled it.  Can you 
review the patch?


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-18 22:38

Message:
Logged In: YES 
user_id=21627

A patch is available at

https://sourceforge.net/tracker/?func=detail&aid=500002&group_id=5470&atid=305470

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

Comment By: Tim Peters (tim_one)
Date: 2001-09-05 19:29

Message:
Logged In: YES 
user_id=31435

A kick in the butt won't help.  It has a higher 
effort/payback ratio than anything else on my plate, and so 
long as that's true it stays at the bottom of my priority 
list.  If someone else wants to tackle it, great.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 18:20

Message:
Logged In: YES 
user_id=6380

This one can use a kick in the butt -- it's still unsolved!


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

Comment By: Tim Peters (tim_one)
Date: 2000-12-13 16:56

Message:
I lost my changes when moving to my new machine.  Wasn't happy with them anyway -- changing the exception from ValueError to SyntaxError was purely a hack, to worm its way thru the maze of hacks already there.  As long as it's got to be a hack, better a pleasant hack <wink>.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 16:02

Message:
Tim, I remember you were looking into this.  Any luck?

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

Comment By: Tim Peters (tim_one)
Date: 2000-11-13 22:51

Message:
Just noting that this is a bit of a mess to repair:  no "2nd phase" compile-time errors report file names or line numbers unless they're SyntaxErrors.  The bad \x escape here is one path thru that code; bad \x escapes in Unicode strings are another; likewise for OverflowError due to "too large" integer literal.  A fix is in progress.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-06 17:04

Message:
The error message is legitimate: in Python 2.0, \x escapes must have exactly two hex characters following, and he uses \x0\x0 in his __init__.py module, which generates the error message.

But his bug report is also legitimate: the ValueError doesn't mention the file where this is occurring! I'm changing the bug subject to reflect this -- it has nothing to do with egcs 2.91.66.

I'm randomly assigning this to Tim.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:37:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:37:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-222395 ] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <E16gveL-0001eo-00@usw-sf-web1.sourceforge.net>

Bugs item #222395, was opened at 2000-11-14 13: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: 6
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: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:37

Message:
Logged In: YES 
user_id=31392

What should be done to fix this?  It sounds like things are 
plain broken.  If readline() doesn't work, it should raise 
an exception at the very least.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-14 14: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 14: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 14: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  Fri Mar  1 22:37:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:37:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-223599 ] Need user-centered info for Windows users.
Message-ID: <E16gveq-0001fS-00@usw-sf-web1.sourceforge.net>

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

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need user-centered info for Windows users.

Initial Comment:
Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users.  This could be similar to what the Macintosh Modules Reference is becoming.  This should be part of the standard documentation and could acquire the Windows module documentation.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:37

Message:
Logged In: YES 
user_id=31392

Can we move this out of bugs and into feature requests?


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-22 16:04

Message:
Another question that should be answered in this document:  "How do I create/recall modules?"  This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?).

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

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


From noreply@sourceforge.net  Fri Mar  1 22:38:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:38:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-223616 ] compiler package needs better documentation.
Message-ID: <E16gvf6-0001fs-00@usw-sf-web1.sourceforge.net>

Bugs item #223616, was opened at 2000-11-27 18: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: compiler package needs better 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: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:38

Message:
Logged In: YES 
user_id=31392

jeremy, get your butt in gear on this!


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-21 18:19

Message:
Logged In: YES 
user_id=3066

I'll note that Jeremy has written basic docs, and they are
in the Library Reference.  But he really needs to polish
them a bit as well, so this stays open but gets a new summary.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-08-10 21: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-08 03: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 Mar  1 22:38:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:38:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows DLL/C++ info needs review
Message-ID: <E16gvfl-0001gP-00@usw-sf-web1.sourceforge.net>

Bugs item #225003, was opened at 2000-12-08 15: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 DLL/C++ info needs review

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: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:38

Message:
Logged In: YES 
user_id=31392

Fred, It sounds like this task is done or almost done.  Can 
we close the bug report?


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

Comment By: Alex Martelli (aleax)
Date: 2001-12-14 12:44

Message:
Logged In: YES 
user_id=60314

I have reviewed Doc/ext/windows.tex, rev=1.3.  Every issue I
had noticed seems fixed very well.  The only remaining
problem I can see are many mentions of python15.lib at the
end of the documents; these should presumably be changed
to python22.lib (a mention of version dependency of these
numbers would probably be a good idea).

Great job!



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-13 17:23

Message:
Logged In: YES 
user_id=3066

The instructions for building extensions on Windows have
been completely replaced in Doc/ext/windows.tex revision
1.3.  The DLL discussion and C++ usage documentation still
needs to be reviewed, but the known-broken docs have been
corrected.

Lowering the priority of the remaining aspects of this
report, and changing the summary line.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-12 05:53

Message:
Logged In: YES 
user_id=3066

This is closely related to SF bug #221671.  Bumping the
priority to match.

I'll plan to get this done for 2.2rc1; Alex, I'll expect you
to review the updated material once the release candidate is
out so I can get your comments before the final release.  ;-)

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

Comment By: Alex Martelli (aleax)
Date: 2001-08-17 07: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 Mar  1 22:39:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:39:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-225476 ] Codec naming scheme and aliasing support
Message-ID: <E16gvgJ-0001gz-00@usw-sf-web1.sourceforge.net>

Bugs item #225476, was opened at 2000-12-12 14: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: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:39

Message:
Logged In: YES 
user_id=31392

Is this a bug?  Or should you just write a PEP?


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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-16 10: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  Fri Mar  1 22:40:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:40:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-225744 ] httplib does not check if port is valid (easy to fix?)
Message-ID: <E16gvhI-0001hn-00@usw-sf-web1.sourceforge.net>

Bugs item #225744, was opened at 2000-12-14 04: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: Jeremy Hylton (jhylton)
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 21: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 22: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 22: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 14: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 Mar  1 22:48:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:48:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E16gvpY-0005us-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Greg Stein (gstein)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 15:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 09:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

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

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 20:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

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

Comment By: Greg Stein (gstein)
Date: 2001-01-06 20:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

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

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


From noreply@sourceforge.net  Fri Mar  1 22:49:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:49:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown
Message-ID: <E16gvqb-0005vh-00@usw-sf-web2.sourceforge.net>

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

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

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

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

from Tkinter import *

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

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

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

Problem also manifests using the PythonWare 2.0 release on Win98.

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

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

Message:
Logged In: YES 
user_id=31392

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


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

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

Message:
Logged In: NO 

i won't to be a hacker

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

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

Message:
Logged In: NO 

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

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


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

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

Message:
Logged In: YES 
user_id=20954

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

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

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

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

import Tkinter
import tkFileDialog
import Pmw

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

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

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

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

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

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

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

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

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

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

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


From noreply@sourceforge.net  Fri Mar  1 22:50:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:50:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] cPickle / time.struct_time loop
Message-ID: <E16gvrH-0001qB-00@usw-sf-web1.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: bixentxo (bixentxo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: cPickle / time.struct_time loop

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:50

Message:
Logged In: YES 
user_id=6380

MWH, I don't understand your comment.

I've already checked in a bugfix for this (long ago). The
references are below in my comment of 12/27/01. Did you copy
those into 2.2.1 already?

I'm not sure I have time to come up with a way to make these
types actually picklable...

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 03:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 08:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 15:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 13:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 11:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

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

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 06:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 01:06

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:51:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:51:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-232398 ] Emacs Python mode bugs
Message-ID: <E16gvsW-0005xf-00@usw-sf-web2.sourceforge.net>

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

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Emacs Python mode bugs

Initial Comment:
1. I wish that Emacs Python mode, when I run a buffer with ^C^C,
looked at the #! line (if there is one) to choose a Python interpreter,
rather than blindly using the default.

2. Also, when I set the variable python-command to "python1.5", this apparently has no effect -- it still uses "python".

3. Maybe I've submitted this before; each time I use ^C^CF a new buffer with a name like /usr/tmp/python-uKA1TJ is created; these buffers just collect dust.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:51

Message:
Logged In: YES 
user_id=31392

Barry,

Are you still planning to work on this?  Or should we move 
it to feature requests and close the bug report?


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 18:37

Message:
I've fixed #3 in 3.110 of python-mode.el.  The other two will require some non-trivial recoding py-execute-region and the py-which-* variables.  I'm not immediately sure of the best way to do this, but I'll work on this for 2.1 final.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:52:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:52:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-233259 ] Ugly traceback for DistutilsPlatformError
Message-ID: <E16gvsr-0005y7-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Ward (gward)
>Assigned to: Michael Hudson (mwh)
Summary: Ugly traceback for DistutilsPlatformError

Initial Comment:
>From Chad Lester:

> I was setting up a new redhat machine, and had forgotten to install the
> python-devel rpm.  The distutils provide a fairly ugly stack trace / error
> message.  Luckily, it meant something to me... but it's not terribly user
> friendly!
>    
> ...
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 368, in get_config_vars
>     func()
>   File "/usr/lib/python1.5/site-packages/distutils/sysconfig.py", line
> 280, in _init_posix
>     raise DistutilsPlatformError, my_msg
> distutils.errors.DistutilsPlatformError: invalid Python
> installation: unable to open /usr/lib/python1.5/config/Makefile (No such
> file or directory)
> 
> 



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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-12-06 16:18

Message:
Logged In: YES 
user_id=11375

Greg, I don't understand your last comment on this bug.  
Surely the traceback will still be ugly for people running
Python 2.2 or whatever who don't have the python-devel RPM
installed?  I don't see how this is only a 1.5.2 or a
"installing Distutils" question. 


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

Comment By: Greg Ward (gward)
Date: 2001-02-20 16:24

Message:
This only applies for people installing Distutils
under Python 1.5.2, so it will only be fixed if
there is another Distutils release to support 1.5.2 --
which is unlikely.


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

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


From noreply@sourceforge.net  Fri Mar  1 22:53:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:53:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E16gvuS-0005zS-00@usw-sf-web2.sourceforge.net>

Bugs item #405939, was opened at 2001-03-05 05: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: 6
Submitted By: Ernie Sasaki (esasaki)
>Assigned to: Jeremy Hylton (jhylton)
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 10: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 23: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 20: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 08: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  Fri Mar  1 22:54:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:54:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16gvvF-00060G-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:54

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-27 22:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 20:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




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

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


From noreply@sourceforge.net  Fri Mar  1 22:55:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:55:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E16gvvj-00060q-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: Later
Priority: 4
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

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

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

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

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

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


From noreply@sourceforge.net  Fri Mar  1 22:58:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 14:58:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-221327 ] threads within an embedded python interpreter
Message-ID: <E16gvyU-0001w6-00@usw-sf-web1.sourceforge.net>

Bugs item #221327, was opened at 2000-11-03 15: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: 5
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: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:58

Message:
Logged In: YES 
user_id=6380

but is it a doco bug or not?

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

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

Message:
Logged In: YES 
user_id=31392

Probably ought to fix this for 2.3


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

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

Message:
Logged In: NO 

Now u pay,.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-03 15: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 Mar  1 23:03:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 15:03:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-232398 ] Emacs Python mode bugs
Message-ID: <E16gw3T-000687-00@usw-sf-web2.sourceforge.net>

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

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Emacs Python mode bugs

Initial Comment:
1. I wish that Emacs Python mode, when I run a buffer with ^C^C,
looked at the #! line (if there is one) to choose a Python interpreter,
rather than blindly using the default.

2. Also, when I set the variable python-command to "python1.5", this apparently has no effect -- it still uses "python".

3. Maybe I've submitted this before; each time I use ^C^CF a new buffer with a name like /usr/tmp/python-uKA1TJ is created; these buffers just collect dust.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-01 18:03

Message:
Logged In: YES 
user_id=12800

I'll handle it.  I've got a bunch of minor python-mode
requests backed up, just waiting for a lull to be attacked.
 Please keep this open.

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

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

Message:
Logged In: YES 
user_id=31392

Barry,

Are you still planning to work on this?  Or should we move 
it to feature requests and close the bug report?


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 13:37

Message:
I've fixed #3 in 3.110 of python-mode.el.  The other two will require some non-trivial recoding py-execute-region and the py-which-* variables.  I'm not immediately sure of the best way to do this, but I'll work on this for 2.1 final.

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

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


From noreply@sourceforge.net  Fri Mar  1 23:12:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 15:12:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E16gwCo-0006Fh-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Greg Stein (gstein)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



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

>Comment By: Greg Stein (gstein)
Date: 2002-03-01 15:12

Message:
Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 07:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 01:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

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

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 12:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

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

Comment By: Greg Stein (gstein)
Date: 2001-01-06 12:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

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

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


From noreply@sourceforge.net  Fri Mar  1 23:44:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 15:44:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16gwhR-0006ex-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

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


From noreply@sourceforge.net  Sat Mar  2 00:15:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 01 Mar 2002 16:15:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-227361 ] httplib problem with '100 Continue'
Message-ID: <E16gxBP-0002tc-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Fort (dougfort)
Assigned to: Greg Stein (gstein)
Summary: httplib problem with '100 Continue'

Initial Comment:
I believe there is a bug in httplib 

IIS 4 and 5 are subject to send an unsolicited result code of '100 Continue' with a couple of headers and a blank line before sending '302 Object Moved'.

The 100 response is totally worthless and should be ignored.  Unfortunately, httplib.HTTPConnection is unwilling to go back and read more headers when it
already has a response object.

I was able to get past this with the following kludge:

    while 1:
        response = self._client.getresponse()
        if response.status != 100:
            break
        # 2000-12-30 djf -- drop bogus 100 response
        # by kludging httplib
        self._client._HTTPConnection__state = httplib._CS_REQ_SENT
        self._client._HTTPConnection__response = None



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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-03-01 18:15

Message:
Logged In: YES 
user_id=67930

I did submit a patch for this, not sure if you noticed. I've
been using it for quite a while and it seems to be working
flawlessly, granted I'm always pretty much using it in the
same context.

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

Comment By: Greg Stein (gstein)
Date: 2002-03-01 17:12

Message:
Logged In: YES 
user_id=6501

Yup, I'll clear out all the httplib bugs... not a problem. I
didn't get free time until the end of the 2.2 cycle, so I
punted until now.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 16:48

Message:
Logged In: YES 
user_id=31392

Greg,

Will you be able to work on this for 2.3?


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

Comment By: Jens B. Jorgensen (jensbjorgensen)
Date: 2002-02-11 09:58

Message:
Logged In: YES 
user_id=67930

Whether or not the library transparently consumes 100
responses (which I believe it should) or not there is no
question the current behavior represents a bug. When a 100
response is received the connection get's "stuck" because it
believes it has already read a response and refuses to read
another until another request is sent. Once you hit this
with the HTTPConnection you cannot do anything with it
unless you modify its internal state data.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-11 03:54

Message:
Logged In: NO 

This may not be a problem at all, depending on how the 
authors of httplib intended to process this header. I 
haven't read their spec so I don't know what they intended.

Here is the section on response code 100 from RFC 2616 
(HTTP 1.1) so you can make up your own mind:

10.1.1 100 Continue

#######################################################
The client SHOULD continue with its request. This interim 
response is used to inform the client that the initial part 
of the request has been received and has not yet been 
rejected by the server. The client SHOULD continue by 
sending the remainder of the request or, if the request has 
already been completed, ignore this response. The server 
MUST send a final response after the request has been 
completed. See section 8.2.3 for detailed discussion of the 
use and handling of this status code.
#######################################################

If you take a look at section 8.2.3, you will find some 
very good reasons why this header responds as it does. You 
might also be able to solve your problem just by reading 
these to section of the spec.

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

Comment By: Doug Fort (dougfort)
Date: 2001-01-06 14:14

Message:
I'm not sure httplib should know anything about the actual status.  Right now it is elegantly decoupled from the content it handles. Perhaps just a 'discardresponse()' function.

BTW, I've had very good results with the HTTP 1.1 functionality in general.  This is a small nit.

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

Comment By: Greg Stein (gstein)
Date: 2001-01-06 14:04

Message:
Agreed -- this is a problem in httplib. I was hoping to get the "chewing up" of 100 (Continue) responses into httplib before the 2.0 release.

It should be possible to do this in HTTPResponse.begin()

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

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


From noreply@sourceforge.net  Sat Mar  2 15:44:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 02 Mar 2002 07:44:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] file iterators: unintuitive behavior
Message-ID: <E16hBgF-0004Fo-00@usw-sf-web1.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: file iterators: unintuitive behavior

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


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

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


From noreply@sourceforge.net  Sat Mar  2 16:19:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 02 Mar 2002 08:19:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile()  coredumps
Message-ID: <E16hCEO-0006bH-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: sys.setprofile()  coredumps

Initial Comment:
Verified in current CVS (also on Windows, but doubt 
the platform matters).  It's not the call proper that 
coredumps, but an eval loop's later attempt to use a 
resulting NULL pointer.  From c.l.py:

"""
From: rihad
Sent: Monday, January 21, 2002 1:19 PM
Subject: minor Python bugs

Calling sys.setprofile() (with no args) makes the 
interpreter crash, and calling sys.settrace() with no 
args succeeds, even though it is documented to take 1 
arg (tracefunc).

And yes, my version is '2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)]'
"""

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-02 11:19

Message:
Logged In: YES 
user_id=3066

This is the right approach, please check this in.  An
equivalent change to sys.settrace() would be appropriate as
well. 

The changes should be committed on both the trucnk and
release22-branch.

Thanks!

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 09:04

Message:
Logged In: YES 
user_id=6656

Certainly.  Setting group so this doesn't get forgotten.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:18

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:17

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 16:46

Message:
Logged In: YES 
user_id=33168

What is the appropriate behaviour for settrace()?
Currently, it is the same as settrace(None) which
disables the trace function.

So is the doc correct or is the code correct?

I can supply another patch to doc/code for settrace()
depending on which needs to be changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 15:24

Message:
Logged In: YES 
user_id=33168

I didn't read the part that settrace was a problem.
I can take a look at the settrace problem later.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 15:02

Message:
Logged In: YES 
user_id=21627

It appears that this patches deals only with the setprofile
problem, not with the settrace problem. Is that intentional?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 17:39

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.
The patch includes a test.

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

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


From noreply@sourceforge.net  Sun Mar  3 13:10:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 05:10:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-525121 ] tty shipped in win32 distribution
Message-ID: <E16hVl5-0001vc-00@usw-sf-web1.sourceforge.net>

Bugs item #525121, was opened at 2002-03-03 13:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525121&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Stenberg (fredriks)
Assigned to: Nobody/Anonymous (nobody)
Summary: tty shipped in win32 distribution

Initial Comment:

Hi,

tty is shipped with the windows distribution..
if one tries to import it (which ofcourse should not
work) you get,

>>> import tty
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python21\lib\tty.py", line 5, in ?
    from termios import *
ImportError: No module named termios

this is true for the following versions atleast, 

Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

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

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


From noreply@sourceforge.net  Sun Mar  3 15:17:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 07:17:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-506611 ] sys.setprofile()  coredumps
Message-ID: <E16hXjz-0000Kp-00@usw-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Neal Norwitz (nnorwitz)
Summary: sys.setprofile()  coredumps

Initial Comment:
Verified in current CVS (also on Windows, but doubt 
the platform matters).  It's not the call proper that 
coredumps, but an eval loop's later attempt to use a 
resulting NULL pointer.  From c.l.py:

"""
From: rihad
Sent: Monday, January 21, 2002 1:19 PM
Subject: minor Python bugs

Calling sys.setprofile() (with no args) makes the 
interpreter crash, and calling sys.settrace() with no 
args succeeds, even though it is documented to take 1 
arg (tracefunc).

And yes, my version is '2.2 (#28, Dec 21 2001, 
12:21:22) [MSC 32 bit (Intel)]'
"""

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-03 10:17

Message:
Logged In: YES 
user_id=33168

Updated both setprofile() and settrace().
Checked in as sysmodule.c 2.101 & 2.98.6.3,
test_profilehooks.py 1.7 & 1.6.10.1, test_scope.py 1.25 and
1.24.4.1.



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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-02 11:19

Message:
Logged In: YES 
user_id=3066

This is the right approach, please check this in.  An
equivalent change to sys.settrace() would be appropriate as
well. 

The changes should be committed on both the trucnk and
release22-branch.

Thanks!

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 09:04

Message:
Logged In: YES 
user_id=6656

Certainly.  Setting group so this doesn't get forgotten.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:18

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-01 08:17

Message:
Logged In: YES 
user_id=33168

We should try to fix the core dump for 2.2.1.


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 16:46

Message:
Logged In: YES 
user_id=33168

What is the appropriate behaviour for settrace()?
Currently, it is the same as settrace(None) which
disables the trace function.

So is the doc correct or is the code correct?

I can supply another patch to doc/code for settrace()
depending on which needs to be changed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-24 15:24

Message:
Logged In: YES 
user_id=33168

I didn't read the part that settrace was a problem.
I can take a look at the settrace problem later.

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 15:02

Message:
Logged In: YES 
user_id=21627

It appears that this patches deals only with the setprofile
problem, not with the settrace problem. Is that intentional?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-01-21 17:39

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem.
The patch includes a test.

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

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


From noreply@sourceforge.net  Sun Mar  3 16:48:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 08:48:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] structseqs unpicklable
Message-ID: <E16hZ9g-000729-00@usw-sf-web3.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: bixentxo (bixentxo)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: structseqs unpicklable

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-03 16:48

Message:
Logged In: YES 
user_id=6656

You seem to have divined my intent, but I've changed the 
summary to be clearer.

Found a spare hour or so; can you find the time to review 
the attached patch?  I would really like to get this into 
2.2.1 -- I think having pickle.dumps(time.localtime())
break is a bit gratuitous.

I haven't written a proper test-suite yet, but hand tests
suggest it does the job for os.stat_result, os.statvfs_result
& time.struct_time both for cPickle and pickle.

There's still a gremlin in here; os.stat_result can have a
varying number of fields & so a varying number of constructor
arguments across platforms which will mean stat_results
pickled on one platform may not unpickle on another.  Not 
sure what to do about that.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 22:50

Message:
Logged In: YES 
user_id=6380

MWH, I don't understand your comment.

I've already checked in a bugfix for this (long ago). The
references are below in my comment of 12/27/01. Did you copy
those into 2.2.1 already?

I'm not sure I have time to come up with a way to make these
types actually picklable...

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 08:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 13:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 20:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 18:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 16:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 14:06

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 11:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

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

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Sun Mar  3 18:13:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 10:13:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-523825 ] python-mode.el: honor-comment-indent bug
Message-ID: <E16haU3-0002S4-00@usw-sf-web2.sourceforge.net>

Bugs item #523825, was opened at 2002-02-28 12:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523825&group_id=5470

Category: Demos and Tools
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Stork (cst)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode.el: honor-comment-indent bug

Initial Comment:
Minor bug in the Python Emacs mode (simple patch provided):

Choosing neither t nor nil for the custom variable
py-honor-comment-indentation prevents proper indention
after unindented code.  Also it wrongly honors
block-comments wrt indention.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-03 18:13

Message:
Logged In: YES 
user_id=6656

Barry, is this sensible?  Is it a 2.2.1 candidate?

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

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


From noreply@sourceforge.net  Sun Mar  3 18:21:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 10:21:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-511655 ] Readline: unwanted filename completion
Message-ID: <E16habq-0002XD-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
>Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tjabo Kloppenburg (tapo)
>Assigned to: Michael Hudson (mwh)
Summary: Readline: unwanted filename completion

Initial Comment:
Hi all.

Something is broken with the completion of readline:

simon@ping-pong:~$ python
Python 2.1.1+ (#1, Jan  8 2002, 00:37:12) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import rlcompleter
>>> rlcompleter.readline.parse_and_bind ("tab:
complete")
>>> foo<TAB><TAB> foo.gif     foo.txt     foo2.gif   
foobar.jpg
>>> foo.gif
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
NameError: name 'foo' is not defined

[the "foo.gif", "foo.txt", "foo2.gif" and "foobar.jpg"
are files
in my current working directory]

It seems that readline has a fallback to filename
completion when
no matches are available. Even if I use my own
completion function:

>>> def nullcompleter (text, state):
...    print "\nBuh!"
...    return None
... 
>>> rlcompleter.readline.set_completer(nullcompleter)
>>> foo<TAB>
Buh!
<TAB>
Buh!

foo.gif     foo.txt     foo2.gif    foobar.jpg 
foot        
>>> foo

there is this filename fallback.

Is this a known Problem? Is there an evil hack to avoid
this?

Thanks,
        Simon

-- 
      Simon.Budig@unix-ag.org      
http://www.home.unix-ag.org/simon/

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-03 18:21

Message:
Logged In: YES 
user_id=6656

And I commited the patch, so close the bug.

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

Comment By: Michael Hudson (mwh)
Date: 2002-02-05 14:11

Message:
Logged In: YES 
user_id=6656

I've submitted Simon's patch to fix this as patch #513235.

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

Comment By: Tjabo Kloppenburg (tapo)
Date: 2002-02-01 11:03

Message:
Logged In: YES 
user_id=309048

simon is a friend of mine. He tried to submit the bug
without sourceforge account, but he failed.


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

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


From noreply@sourceforge.net  Sun Mar  3 18:27:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 10:27:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher
Message-ID: <E16hai4-0002c1-00@usw-sf-web2.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 22: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: Nobody/Anonymous (nobody)
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: 2002-03-03 18:27

Message:
Logged In: YES 
user_id=6656

Is there any realistic chance of anything happening on this
front in the 2.2.1 timeframe?

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

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

Message:
Logged In: YES 
user_id=6380

Sigh. I wished I'd picked this up earlier, but I haven't.
After 2.2.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-04 18:43

Message:
Logged In: YES 
user_id=6380

I'm not so interested in the list.sort crasher, so I'm
lowering the priority and unassigning it.

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

Comment By: Michael Hudson (mwh)
Date: 2001-08-30 14: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 12: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-30 06: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 07: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 Mar  3 19:34:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 11:34:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-525121 ] tty shipped in win32 distribution
Message-ID: <E16hbkv-0000ZB-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 1
Submitted By: Fredrik Stenberg (fredriks)
Assigned to: Nobody/Anonymous (nobody)
Summary: tty shipped in win32 distribution

Initial Comment:

Hi,

tty is shipped with the windows distribution..
if one tries to import it (which ofcourse should not
work) you get,

>>> import tty
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python21\lib\tty.py", line 5, in ?
    from termios import *
ImportError: No module named termios

this is true for the following versions atleast, 

Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-03 14:34

Message:
Logged In: YES 
user_id=6380

I'm not sure I understand your complaint.  We ship all .py
modules with Windows.  The "import tty" *does* fail, doesn't
it?  So what's the bug?

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

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


From noreply@sourceforge.net  Sun Mar  3 19:42:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 11:42:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher
Message-ID: <E16hbsJ-0003Qu-00@usw-sf-web2.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 18: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: 1
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
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: 2002-03-03 13:27

Message:
Logged In: YES 
user_id=6656

Is there any realistic chance of anything happening on this
front in the 2.2.1 timeframe?

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

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

Message:
Logged In: YES 
user_id=6380

Sigh. I wished I'd picked this up earlier, but I haven't.
After 2.2.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-04 14:43

Message:
Logged In: YES 
user_id=6380

I'm not so interested in the list.sort crasher, so I'm
lowering the priority and unassigning it.

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

Comment By: Michael Hudson (mwh)
Date: 2001-08-30 10: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 08: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-30 02: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 03: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 Mar  3 21:34:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 13:34:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-221791 ] Error for bad \x escape doesn't mention filename
Message-ID: <E16hdcx-0004tI-00@usw-sf-web2.sourceforge.net>

Bugs item #221791, was opened at 2000-11-06 17:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=221791&group_id=5470

Category: Parser/Compiler
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Martin v. Löwis (loewis)
Summary: Error for bad \x escape doesn't mention filename

Initial Comment:
Using:

GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2

I get the following 'error' message:

    from interscript.languages.interscript_languages import add_translation
  File "interscript/languages/interscript_languages.py", line 2, in ?
    from interscript.encoding.utf8 import utf8
ValueError: invalid \x escape

in known correct code (i.e. it works on Python 1.5.2).

I have examined the function 'parsestr' in
'compile.c', and added debugging prints to find out
what is going on. The function _correctly_ processes
the string 'utf8' (quotes included), and returns,
then the error is generated _without_ entering
the routine!

This almost certainly must be a bug in egcs-2.91.66. 
The code in 'parsestr' looks correct to me.

It is possible the error can be replicated by
downloading and running 'interscript' (without
any arguments). Interscript is available at

	http://interscript.sourceforge.net

[Reply to skaller@maxtal.com.au, sorry, I couldn't
figure out how to 'log on']


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 22:34

Message:
Logged In: YES 
user_id=21627

Fixed through #50002 for both 2.3 and 2.2.1.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:35

Message:
Logged In: YES 
user_id=31392

Tim, it looks like someone else has tackled it.  Can you 
review the patch?


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-18 23:38

Message:
Logged In: YES 
user_id=21627

A patch is available at

https://sourceforge.net/tracker/?func=detail&aid=500002&group_id=5470&atid=305470

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

Comment By: Tim Peters (tim_one)
Date: 2001-09-05 21:29

Message:
Logged In: YES 
user_id=31435

A kick in the butt won't help.  It has a higher 
effort/payback ratio than anything else on my plate, and so 
long as that's true it stays at the bottom of my priority 
list.  If someone else wants to tackle it, great.


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

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

Message:
Logged In: YES 
user_id=6380

This one can use a kick in the butt -- it's still unsolved!


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

Comment By: Tim Peters (tim_one)
Date: 2000-12-13 17:56

Message:
I lost my changes when moving to my new machine.  Wasn't happy with them anyway -- changing the exception from ValueError to SyntaxError was purely a hack, to worm its way thru the maze of hacks already there.  As long as it's got to be a hack, better a pleasant hack <wink>.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 17:02

Message:
Tim, I remember you were looking into this.  Any luck?

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

Comment By: Tim Peters (tim_one)
Date: 2000-11-13 23:51

Message:
Just noting that this is a bit of a mess to repair:  no "2nd phase" compile-time errors report file names or line numbers unless they're SyntaxErrors.  The bad \x escape here is one path thru that code; bad \x escapes in Unicode strings are another; likewise for OverflowError due to "too large" integer literal.  A fix is in progress.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-06 18:04

Message:
The error message is legitimate: in Python 2.0, \x escapes must have exactly two hex characters following, and he uses \x0\x0 in his __init__.py module, which generates the error message.

But his bug report is also legitimate: the ValueError doesn't mention the file where this is occurring! I'm changing the bug subject to reflect this -- it has nothing to do with egcs 2.91.66.

I'm randomly assigning this to Tim.

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

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


From noreply@sourceforge.net  Sun Mar  3 21:47:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 13:47:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16hdpN-0002FL-00@usw-sf-web3.sourceforge.net>

Bugs item #524600, was opened at 2002-03-02 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 22:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

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

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


From noreply@sourceforge.net  Sun Mar  3 22:35:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 14:35:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-453523 ] list.sort crasher
Message-ID: <E16hea9-0005i9-00@usw-sf-web2.sourceforge.net>

Bugs item #453523, was opened at 2001-08-20 18: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: 1
Submitted By: Gregory H. Ball (greg_ball)
Assigned to: Nobody/Anonymous (nobody)
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: Tim Peters (tim_one)
Date: 2002-03-03 17:35

Message:
Logged In: YES 
user_id=31435

Assuming "this front" means the list.sort() crasher, not 
unless Guido raises the priority from 1 to, oh, at least 8 
<wink>.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-03 13:27

Message:
Logged In: YES 
user_id=6656

Is there any realistic chance of anything happening on this
front in the 2.2.1 timeframe?

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

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

Message:
Logged In: YES 
user_id=6380

Sigh. I wished I'd picked this up earlier, but I haven't.
After 2.2.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-04 14:43

Message:
Logged In: YES 
user_id=6380

I'm not so interested in the list.sort crasher, so I'm
lowering the priority and unassigning it.

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

Comment By: Michael Hudson (mwh)
Date: 2001-08-30 10: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 08: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-30 02: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 03: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  Mon Mar  4 06:47:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 03 Mar 2002 22:47:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] file iterators: unintuitive behavior
Message-ID: <E16hmGA-000887-00@usw-sf-web1.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Nobody/Anonymous (nobody)
Summary: file iterators: unintuitive behavior

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


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

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 06:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


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

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


From noreply@sourceforge.net  Mon Mar  4 09:50:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 01:50:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-525439 ] tcl: encoding not found
Message-ID: <E16hp6y-0001rt-00@usw-sf-web1.sourceforge.net>

Bugs item #525439, was opened at 2002-03-04 09:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525439&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Skorsky (y5f)
Assigned to: Nobody/Anonymous (nobody)
Summary: tcl: encoding not found

Initial Comment:
In the current installation of Python 2.2, tcl 
encodings are not found. This occurs, when Python is 
used by WinCVS 1.3.7b1 (macro 'build changelog').
If the folder 'tcl8.3' is moved from 'tcl' to 'lib', 
it works.

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

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


From noreply@sourceforge.net  Mon Mar  4 12:02:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 04:02:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-525481 ] long double causes compiler warnings
Message-ID: <E16hrAl-0003Tl-00@usw-sf-web1.sourceforge.net>

Bugs item #525481, was opened at 2002-03-04 13:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Tim Peters (tim_one)
Summary: long double causes compiler warnings

Initial Comment:
The 2.44 changes to objimpl.h, especially the "long double" bit, causes numerous warnings on Mac OS X (and possible on other gcc-based platforms). Maybe the suggestion of adding the -Wno-long-double option should be taken, maybe something else should be done (adding a config-based define for the type with the biggest alignment requirement?).

/Users/jack/src/python/Include/objimpl.h:275: warning: use of `long double' type; its size may change in a future release
/Users/jack/src/python/Include/objimpl.h:275: warning: (Long double usage is reported only once for each file.
/Users/jack/src/python/Include/objimpl.h:275: warning: To disable this warning, use -Wno-long-double.)


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

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


From noreply@sourceforge.net  Mon Mar  4 14:16:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 06:16:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-525520 ] httplib/HTTPConnetion: wrong HOST header
Message-ID: <E16htGD-0005Io-00@usw-sf-web1.sourceforge.net>

Bugs item #525520, was opened at 2002-03-04 09:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525520&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib/HTTPConnetion: wrong HOST header

Initial Comment:
h = httplib.HTTPConnection('blabla.xx.com:5000")
h.request('GET','/',{},{'host':'www.foo.com'})

should produce a HTTP header "HOST: www.foo.com".
Instead HTTPConnection sends two HOST headers:

HOST: blabla.xx.com:5000

and 

HOST:www.foo.com

A host header in the headers dictionary should override
the default host header in any case.



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

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


From noreply@sourceforge.net  Mon Mar  4 14:24:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 06:24:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-525520 ] httplib/HTTPConnetion: wrong HOST header
Message-ID: <E16htNi-0000Nv-00@usw-sf-web2.sourceforge.net>

Bugs item #525520, was opened at 2002-03-04 09:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525520&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib/HTTPConnetion: wrong HOST header

Initial Comment:
h = httplib.HTTPConnection('blabla.xx.com:5000")
h.request('GET','/',{},{'host':'www.foo.com'})

should produce a HTTP header "HOST: www.foo.com".
Instead HTTPConnection sends two HOST headers:

HOST: blabla.xx.com:5000

and 

HOST:www.foo.com

A host header in the headers dictionary should override
the default host header in any case.



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

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


From noreply@sourceforge.net  Mon Mar  4 15:38:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 07:38:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-525548 ] __add__ returning NotImplemented broken
Message-ID: <E16huY6-0001N7-00@usw-sf-web2.sourceforge.net>

Bugs item #525548, was opened at 2002-03-04 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525548&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: __add__ returning NotImplemented broken

Initial Comment:
A new-style class that returns NotImplemented
from its __add__ method misbehaves; this should
raise a TypeError but in fact the NotImplemented
value is kept as the return value.

This only seems to be a problem with __add__;
I bet it's because the code goes through a path
intended for sequence concatenation.

Old-style classes do the right thing.


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

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


From noreply@sourceforge.net  Mon Mar  4 22:45:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 14:45:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-525684 ] Need character macro cheat sheet
Message-ID: <E16i1Cc-0005Rs-00@usw-sf-web2.sourceforge.net>

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

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need character macro cheat sheet

Initial Comment:
For those of us without a lot of LaTeX experience
it would be helpful if Documenting Python had a
table listing the various macros used to generate
various special characters outside math mode.  For
example:

    macro                produces
    \e                   \
    \textless            <
    \textgreater         >
    \textasciicircum     ^

Skip


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

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


From noreply@sourceforge.net  Mon Mar  4 23:14:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 15:14:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] structseqs unpicklable
Message-ID: <E16i1fD-0002l2-00@usw-sf-web1.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: bixentxo (bixentxo)
>Assigned to: Michael Hudson (mwh)
Summary: structseqs unpicklable

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-04 18:14

Message:
Logged In: YES 
user_id=6380

The patch looks OK to me.

I wonder if the solution to the varying size isn't to fix
the size, and simply supply -1 for the fields a platform
doesn't have?


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-03 11:48

Message:
Logged In: YES 
user_id=6656

You seem to have divined my intent, but I've changed the 
summary to be clearer.

Found a spare hour or so; can you find the time to review 
the attached patch?  I would really like to get this into 
2.2.1 -- I think having pickle.dumps(time.localtime())
break is a bit gratuitous.

I haven't written a proper test-suite yet, but hand tests
suggest it does the job for os.stat_result, os.statvfs_result
& time.struct_time both for cPickle and pickle.

There's still a gremlin in here; os.stat_result can have a
varying number of fields & so a varying number of constructor
arguments across platforms which will mean stat_results
pickled on one platform may not unpickle on another.  Not 
sure what to do about that.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:50

Message:
Logged In: YES 
user_id=6380

MWH, I don't understand your comment.

I've already checked in a bugfix for this (long ago). The
references are below in my comment of 12/27/01. Did you copy
those into 2.2.1 already?

I'm not sure I have time to come up with a way to make these
types actually picklable...

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 03:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 08:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 15:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 13:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 11:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

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

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 06:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 01:06

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Mon Mar  4 23:56:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 15:56:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] underflow raise OverflowException
Message-ID: <E16i2JN-0003J6-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 23:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Nobody/Anonymous (nobody)
Summary: underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


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

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


From noreply@sourceforge.net  Tue Mar  5 00:48:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 04 Mar 2002 16:48:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] underflow raise OverflowException
Message-ID: <E16i38S-0006vL-00@usw-sf-web2.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Nobody/Anonymous (nobody)
Summary: underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

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

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


From noreply@sourceforge.net  Tue Mar  5 13:29:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 05:29:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] structseqs unpicklable
Message-ID: <E16iF0Z-0004ph-00@usw-sf-web3.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: bixentxo (bixentxo)
Assigned to: Michael Hudson (mwh)
Summary: structseqs unpicklable

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-05 13:29

Message:
Logged In: YES 
user_id=6656

Checked in a very-slightly different patch & simple test case.

Yes, that's what I thought too.  I wonder why that wasn't
done originally?  Time to dig into archives, I guess.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-04 23:14

Message:
Logged In: YES 
user_id=6380

The patch looks OK to me.

I wonder if the solution to the varying size isn't to fix
the size, and simply supply -1 for the fields a platform
doesn't have?


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-03 16:48

Message:
Logged In: YES 
user_id=6656

You seem to have divined my intent, but I've changed the 
summary to be clearer.

Found a spare hour or so; can you find the time to review 
the attached patch?  I would really like to get this into 
2.2.1 -- I think having pickle.dumps(time.localtime())
break is a bit gratuitous.

I haven't written a proper test-suite yet, but hand tests
suggest it does the job for os.stat_result, os.statvfs_result
& time.struct_time both for cPickle and pickle.

There's still a gremlin in here; os.stat_result can have a
varying number of fields & so a varying number of constructor
arguments across platforms which will mean stat_results
pickled on one platform may not unpickle on another.  Not 
sure what to do about that.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 22:50

Message:
Logged In: YES 
user_id=6380

MWH, I don't understand your comment.

I've already checked in a bugfix for this (long ago). The
references are below in my comment of 12/27/01. Did you copy
those into 2.2.1 already?

I'm not sure I have time to come up with a way to make these
types actually picklable...

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 08:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 13:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 20:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 18:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 16:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 14:06

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 11:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

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

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Tue Mar  5 13:32:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 05:32:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-496873 ] structseqs unpicklable
Message-ID: <E16iF36-0004j4-00@usw-sf-web1.sourceforge.net>

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

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: bixentxo (bixentxo)
Assigned to: Michael Hudson (mwh)
Summary: structseqs unpicklable

Initial Comment:
The following code produces and endless loop
on python 2.2 ( ok on python 2.1 ). The
file being saved by cPickle.dump grows
indefinetely.

-----------------------------
import time, cPickle

created = time.localtime()

fd = open('/tmp/bla.pickle','w')
cPickle.dump(created,fd)
[...endless loop... ]

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-05 08:32

Message:
Logged In: YES 
user_id=6380

Thanks!  I think the change to fixed size would have to be a
2.3 feature.

I guess it wasn't done that way because nobody realized it
had any advantage.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-05 08:29

Message:
Logged In: YES 
user_id=6656

Checked in a very-slightly different patch & simple test case.

Yes, that's what I thought too.  I wonder why that wasn't
done originally?  Time to dig into archives, I guess.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-04 18:14

Message:
Logged In: YES 
user_id=6380

The patch looks OK to me.

I wonder if the solution to the varying size isn't to fix
the size, and simply supply -1 for the fields a platform
doesn't have?


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-03 11:48

Message:
Logged In: YES 
user_id=6656

You seem to have divined my intent, but I've changed the 
summary to be clearer.

Found a spare hour or so; can you find the time to review 
the attached patch?  I would really like to get this into 
2.2.1 -- I think having pickle.dumps(time.localtime())
break is a bit gratuitous.

I haven't written a proper test-suite yet, but hand tests
suggest it does the job for os.stat_result, os.statvfs_result
& time.struct_time both for cPickle and pickle.

There's still a gremlin in here; os.stat_result can have a
varying number of fields & so a varying number of constructor
arguments across platforms which will mean stat_results
pickled on one platform may not unpickle on another.  Not 
sure what to do about that.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:50

Message:
Logged In: YES 
user_id=6380

MWH, I don't understand your comment.

I've already checked in a bugfix for this (long ago). The
references are below in my comment of 12/27/01. Did you copy
those into 2.2.1 already?

I'm not sure I have time to come up with a way to make these
types actually picklable...

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-01 03:46

Message:
Logged In: YES 
user_id=6656

I think Guido is the only person who knows how to fix this.

Anyone else who does is encouraged to jump in, of course!

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

Comment By: Simo Salminen (frangen)
Date: 2002-01-31 08:13

Message:
Logged In: YES 
user_id=291461

os.stat results cant be pickled either.

>>> pickle.dump(os.stat('.'), open('foo', 'w'))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 969, in dump
    Pickler(file, bin).dump(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 115, in dump
    self.save(object)
  File "/opt/local/lang/python2.2/lib/python2.2/pickle.py", 
line 185, in save
    tup = reduce()
  
File "/opt/local/lang/python2.2/lib/python2.2/copy_reg.py", 
line 56, in _reduce
    state = base(self)
TypeError: constructor takes exactly 13 arguments (10 given)


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

Comment By: bixentxo (bixentxo)
Date: 2001-12-27 15:31

Message:
Logged In: YES 
user_id=395354

As for me, it is not a problem anymore
as I found the 'tuple' solution straight away.

It is not that I needed pickling struct_time
is that I had no reason why not doing it.

Only that it DID break my code.

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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 13:02

Message:
Logged In: YES 
user_id=31435

Re "does anybody need to pickle time structs?", I think a 
better question is "does anybody pickle time.localtime() 
results?".  The existence of the bug report suggests yes, 
and the OP is right that this worked in 2.1 (and 2.0, 
and ...).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 11:32

Message:
Logged In: YES 
user_id=6380

Actually, the bug was in copy_reg._reduce: it was possible
that this would not make any progress, returning an instance
of the same type that it was passed, thus causing the
infinite recursion. I've checked in a fix that raises an
exception when this situation is detected.
(copy_reg.py:1.10)

Now, the question is, does anybody need to pickle time
structs? I would recommend converting them into a tuple
before pickling: pickle.dumps(tuple(time.localtime())) works
fine.

The statvfs issue was an unrelated bug; I've checked in a
fix for that too. (posixmodule.c:2.217)

Both are 2.2.1 candidates (I only noted this in the
posixmodule.c CVS checkin message by mistake).

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

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

Message:
Logged In: YES 
user_id=6380

It gets in an infinite loop with pickle too, so I think this
is definitely a bug in the magical type used for localtime.
The stacktrack looks like this:

  File "/usr/local/lib/python2.2/pickle.py", line 370, in
save_tuple
    save(element)
  File "/usr/local/lib/python2.2/pickle.py", line 215, in
save
    self.save_reduce(callable, arg_tup, state)
  File "/usr/local/lib/python2.2/pickle.py", line 241, in
save_reduce
    save(arg_tup)
  File "/usr/local/lib/python2.2/pickle.py", line 221, in
save
    f(self, object)

repeated an infinite number of times.

Note that we should look at the other objects that use
structseq.c/h too. pickle.dumps(os.stat("/")) gives

TypeError: constructor takes exactly 13 arguments (10 given)

pickle.dumps(os.statvfs("/")) gives

pickle.PicklingError: Can't pickle <type
'posix.statvfs_result'>: it's not the same object as
posix.statvfs_result

Looks like a variety of bugs. :-(



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

Comment By: Michael Hudson (mwh)
Date: 2001-12-27 06:50

Message:
Logged In: YES 
user_id=6656

Another factoid: if you back out the change that renamed the 
"struct_time" type to "time.struct_time", the crash goes 
away, to be replaced with 

cPickle.PicklingError: Can't pickle <type 'struct_time'>: 
it's not found as __builtin__.struct_time

so I suspect this bug has been lurking for some time.


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

Comment By: Tim Peters (tim_one)
Date: 2001-12-27 01:06

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Guido.

A stack fault is faster to produce via the one-liner

cPickle.dumps(time.localtime())

There's unbounded recursion.

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

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


From noreply@sourceforge.net  Tue Mar  5 16:45:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 08:45:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-222395 ] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <E16iI4X-0007Jj-00@usw-sf-web1.sourceforge.net>

Bugs item #222395, was opened at 2000-11-14 13: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: 6
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: 2002-03-05 16:45

Message:
Logged In: YES 
user_id=38388

Uhm... it does raise an exception ;-)

It is hard to fix this bug, since Unicode line breaking
is much more elaborate than standard C lib type
line breaking. The only way I see to handle this
properly is by introducing line buffering. However,
this can slow down the codec considerably.

Perhaps we should simply have the .readline()
method raise a NotImplementedError ?!

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:37

Message:
Logged In: YES 
user_id=31392

What should be done to fix this?  It sounds like things are 
plain broken.  If readline() doesn't work, it should raise 
an exception at the very least.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-14 14: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 14: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 14: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  Tue Mar  5 16:47:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 08:47:12 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-514532 ] Add "eu#" parser marker
Message-ID: <E16iI5o-0007L2-00@usw-sf-web1.sourceforge.net>

Feature Requests item #514532, was opened at 2002-02-07 21:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=514532&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: Add "eu#" parser marker

Initial Comment:
As requested by Jack Janssen:
"""
Recently, "M.-A. Lemburg" <mal@lemburg.com> said:
> How about this: we add a wchar_t codec to Python and the "eu#" parser
> marker. Then you could write:
> 
>       wchar_t value = NULL;
>       int len = 0;
>       if (PyArg_ParseTuple(tuple, "eu#", "wchar_t", &value, &len) < 0)
>                 return NULL;

I like it!
"""

The parser marker should return Py_UNICODE* instead of char* and work much like "et#" does now for 
strings.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-17 00:11

Message:
Logged In: YES 
user_id=21627

Because of the memory management issues, I don't think
having such a feature is desirable.

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

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


From noreply@sourceforge.net  Tue Mar  5 16:51:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 08:51:11 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494854 ] add platform.py
Message-ID: <E16iI9f-0007Nr-00@usw-sf-web1.sourceforge.net>

Feature Requests item #494854, was opened at 2001-12-19 01:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494854&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: M.-A. Lemburg (lemburg)
Summary: add platform.py

Initial Comment:
Here's a request to add Marc-Andre Lemburg's
platform.py to the Python standard library.

It provides more complete platform information
than either sys.platform or
distutils.util.get_platform()

For more info, see:
http://www.lemburg.com/files/python/platform.py


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 16:51

Message:
Logged In: YES 
user_id=38388

Guido has already approved the addition; so it's basically
just the docs that are currently missing...

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-19 09:27

Message:
Logged In: YES 
user_id=38388

No problem from here :-)

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

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


From noreply@sourceforge.net  Tue Mar  5 18:06:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 10:06:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-526039 ] devious code can crash structseqs
Message-ID: <E16iJKR-00081F-00@usw-sf-web3.sourceforge.net>

Bugs item #526039, was opened at 2002-03-05 18:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526039&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: devious code can crash structseqs

Initial Comment:
Some days you feel that whenever you look closely at
something, you find bugs in it.

>>> import time
>>> class C:
...  def __getitem__(self, i):
...   raise IndexError
...  def __len__(self):
...   return 9
...
>>> time.struct_time(C())
Segmentation fault (core dumped)

This isn't hard to fix (use the PySequence_Fast API),
but I have all sorts of changes in my copy of
Objects/structseq.c and I don't want to forget this.

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

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


From noreply@sourceforge.net  Tue Mar  5 20:30:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 12:30:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-526102 ] Namespace error with UserList
Message-ID: <E16iLZk-0001dM-00@usw-sf-web1.sourceforge.net>

Bugs item #526102, was opened at 2002-03-05 20:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526102&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charlie Fly (cfly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Namespace error with UserList

Initial Comment:
I may be misunderstanding something about the merging 
of type/class and this may not be a bug.  But here 
goes.

import UserList

class A( UserList ):
   def __init__( self ):
      UserList.UserList.__init__( self )

a = A()

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'module' object is not callable

It appears that the name UserList being both module 
and class name is getting confused in the module 
namespace.


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

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


From noreply@sourceforge.net  Tue Mar  5 21:08:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 13:08:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16iMAW-00024p-00@usw-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


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

>Comment By: Thomas Heller (theller)
Date: 2002-03-05 22:08

Message:
Logged In: YES 
user_id=11105

I expect nobody will install from a zip-file on windows, 
either.

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:54

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-28 00:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 22:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




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

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


From noreply@sourceforge.net  Tue Mar  5 21:01:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 13:01:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-526102 ] Namespace error with UserList
Message-ID: <E16iM41-0003R2-00@usw-sf-web2.sourceforge.net>

Bugs item #526102, was opened at 2002-03-05 20:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526102&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Charlie Fly (cfly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Namespace error with UserList

Initial Comment:
I may be misunderstanding something about the merging 
of type/class and this may not be a bug.  But here 
goes.

import UserList

class A( UserList ):
   def __init__( self ):
      UserList.UserList.__init__( self )

a = A()

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'module' object is not callable

It appears that the name UserList being both module 
and class name is getting confused in the module 
namespace.


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

>Comment By: Charlie Fly (cfly)
Date: 2002-03-05 21:01

Message:
Logged In: YES 
user_id=149625

This is not a bug.  I just inherited from a module.  Opps.  
I don't know how to withdraw this thing.

cfly

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

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


From noreply@sourceforge.net  Tue Mar  5 23:24:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 15:24:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-525439 ] tcl: encoding not found
Message-ID: <E16iOHy-0003ti-00@usw-sf-web1.sourceforge.net>

Bugs item #525439, was opened at 2002-03-04 10:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525439&group_id=5470

Category: Installation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Skorsky (y5f)
Assigned to: Nobody/Anonymous (nobody)
Summary: tcl: encoding not found

Initial Comment:
In the current installation of Python 2.2, tcl 
encodings are not found. This occurs, when Python is 
used by WinCVS 1.3.7b1 (macro 'build changelog').
If the folder 'tcl8.3' is moved from 'tcl' to 'lib', 
it works.

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-06 00:24

Message:
Logged In: YES 
user_id=21627

This is fixed in the CVS, for both Python 2.3 and 2.2.1

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

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


From noreply@sourceforge.net  Wed Mar  6 00:01:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 05 Mar 2002 16:01:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16iOrw-0004NY-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Nobody/Anonymous (nobody)
>Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-05 19:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

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

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


From noreply@sourceforge.net  Wed Mar  6 08:55:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 00:55:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-526298 ] _socket unimportable
Message-ID: <E16iXCP-0002ip-00@usw-sf-web3.sourceforge.net>

Bugs item #526298, was opened at 2002-03-06 16:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526298&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Crispin Wellington (wongfeihung)
Assigned to: Nobody/Anonymous (nobody)
Summary: _socket unimportable

Initial Comment:
During build get the following a number of times

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-DUSE_SSL=1 -I. -I/bigfree/Python-2.2/./Include 
-I/usr/local/include -IInclude/ -c 
/bigfree/Python-2.2/Modules/socketmodule.c -o 
build/temp.linux-i686-2.2/socketmodule.o
gcc -shared 
build/temp.linux-i686-2.2/socketmodule.o 
-L/usr/local/lib -lssl -lcrypto -o 
build/lib.linux-i686-2.2/_socket.so
WARNING: removing "_socket" since importing it 
failed

_socket.so builds ok. Trying to import it gives...

Python 2.2 (#2, Mar  6 2002, 16:22:26) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" 
for more information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./_socket.so: undefined symbol: 
RAND_add

System info:

uname -a
Linux water 2.2.18pre21 #1 Thu Mar 8 18:04:07 WST 
2001 i686 unknown

openssl version
OpenSSL 0.9.6 24 Sep 2000

More info email Crispin Wellington 
<crispin@aeonline.net>


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

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


From noreply@sourceforge.net  Wed Mar  6 09:07:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 01:07:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-526298 ] _socket unimportable
Message-ID: <E16iXOE-0002sQ-00@usw-sf-web3.sourceforge.net>

Bugs item #526298, was opened at 2002-03-06 16:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526298&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Crispin Wellington (wongfeihung)
Assigned to: Nobody/Anonymous (nobody)
Summary: _socket unimportable

Initial Comment:
During build get the following a number of times

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-DUSE_SSL=1 -I. -I/bigfree/Python-2.2/./Include 
-I/usr/local/include -IInclude/ -c 
/bigfree/Python-2.2/Modules/socketmodule.c -o 
build/temp.linux-i686-2.2/socketmodule.o
gcc -shared 
build/temp.linux-i686-2.2/socketmodule.o 
-L/usr/local/lib -lssl -lcrypto -o 
build/lib.linux-i686-2.2/_socket.so
WARNING: removing "_socket" since importing it 
failed

_socket.so builds ok. Trying to import it gives...

Python 2.2 (#2, Mar  6 2002, 16:22:26) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" 
for more information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./_socket.so: undefined symbol: 
RAND_add

System info:

uname -a
Linux water 2.2.18pre21 #1 Thu Mar 8 18:04:07 WST 
2001 i686 unknown

openssl version
OpenSSL 0.9.6 24 Sep 2000

More info email Crispin Wellington 
<crispin@aeonline.net>


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

>Comment By: Crispin Wellington (wongfeihung)
Date: 2002-03-06 17:07

Message:
Logged In: YES 
user_id=329215

got it working. Had to uncomment one of the _socket lines 
in setup. Im surprised the default non-SSL one isn't 
uncommented by default. Perhaps it should be.



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

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


From noreply@sourceforge.net  Wed Mar  6 09:42:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 01:42:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-526298 ] _socket unimportable
Message-ID: <E16iXwI-0003Gg-00@usw-sf-web3.sourceforge.net>

Bugs item #526298, was opened at 2002-03-06 08:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526298&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Crispin Wellington (wongfeihung)
Assigned to: Nobody/Anonymous (nobody)
Summary: _socket unimportable

Initial Comment:
During build get the following a number of times

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-DUSE_SSL=1 -I. -I/bigfree/Python-2.2/./Include 
-I/usr/local/include -IInclude/ -c 
/bigfree/Python-2.2/Modules/socketmodule.c -o 
build/temp.linux-i686-2.2/socketmodule.o
gcc -shared 
build/temp.linux-i686-2.2/socketmodule.o 
-L/usr/local/lib -lssl -lcrypto -o 
build/lib.linux-i686-2.2/_socket.so
WARNING: removing "_socket" since importing it 
failed

_socket.so builds ok. Trying to import it gives...

Python 2.2 (#2, Mar  6 2002, 16:22:26) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" 
for more information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./_socket.so: undefined symbol: 
RAND_add

System info:

uname -a
Linux water 2.2.18pre21 #1 Thu Mar 8 18:04:07 WST 
2001 i686 unknown

openssl version
OpenSSL 0.9.6 24 Sep 2000

More info email Crispin Wellington 
<crispin@aeonline.net>


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

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-06 09:42

Message:
Logged In: YES 
user_id=38388

In Python 2.3, the socket module setup was made smarter 
and the SSL support is now optional in the sense that if
the module fails to import (e.g. due to version problems with
the installed SSL libs), socket still imports but without SSL
support.

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

Comment By: Crispin Wellington (wongfeihung)
Date: 2002-03-06 09:07

Message:
Logged In: YES 
user_id=329215

got it working. Had to uncomment one of the _socket lines 
in setup. Im surprised the default non-SSL one isn't 
uncommented by default. Perhaps it should be.



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

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


From noreply@sourceforge.net  Wed Mar  6 12:09:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 04:09:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-523041 ] Robotparser incorrectly applies regex
Message-ID: <E16iaF2-00053Z-00@usw-sf-web2.sourceforge.net>

Bugs item #523041, was opened at 2002-02-26 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523041&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Costas Malamas (cmalamas)
Assigned to: Nobody/Anonymous (nobody)
Summary: Robotparser incorrectly applies regex

Initial Comment:
Robotparser uses re to evaluate the Allow/Disallow 
directives: nowhere in the RFC is it specified that 
these directives can be regular expressions. As a 
result, directives such as the following are mis-
interpreted:
User-Agent: *
Disallow: /.

The directive (which is actually syntactically 
incorrect according to the RFC) denies access to the 
root directory, but not the entire site; it should 
pass robotparser but it fails (e.g. 
http://www.pbs.org/robots.txt)

>From the draft RFC 
(http://www.robotstxt.org/wc/norobots.html):
"The value of this field specifies a partial URL that 
is not to be visited. This can be a full path, or a 
partial path; any URL that starts with this value will 
not be retrieved. For example, Disallow: /help 
disallows both /help.html"

Also the final RFC excludes * as valid in the path 
directive (http://www.robotstxt.org/wc/norobots-
rfc.html).

Suggested fix (also fixes bug #522898):
robotparser.RuleLine.applies_to becomes:

    def applies_to(self, filename):
        if not self.path:
           self.allowance = 1
        return self.path=="*" or self.path.find
(filename) == 0

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

>Comment By: Costas Malamas (cmalamas)
Date: 2002-03-06 12:09

Message:
Logged In: YES 
user_id=71233

calvin is right; the patch was incorrect.  A better one 
(and more tested by now):

    def applies_to(self, filename):
        if not self.path:
           self.allowance = 1
        return self.path=="*" or urllib.quote
(filename).startswith(self.path)

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-28 15:25

Message:
Logged In: YES 
user_id=21627

This has been fixed in robotparser.py 1.11.

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

Comment By: Bastian Kleineidam (calvin)
Date: 2002-02-27 14:11

Message:
Logged In: YES 
user_id=9205

Patch is not good:
>>> print RuleLine("/tmp", 0).applies_to("/")
1
>>>
This would apply the filename "/" to rule "Disallow: /tmp".

I think it should be:
return self.path=="*" or filename.startswith(self.path)

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

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


From noreply@sourceforge.net  Wed Mar  6 12:51:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 04:51:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-526357 ] cmd.py does not flush stdout
Message-ID: <E16iat9-0005XI-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: cmd.py does not flush stdout

Initial Comment:
The module cmd (located in cmd.py in the library) does not flush stdout 
before it waits for input.

What does that mean? That means that unless you are running cmd 
from the terminal, or unless stdout happens to magically flush before it 
waits for new input, that there will be no data written to stdout before it 
waits for input.

This is a problem if you want to fork() a module that uses cmd, or set it 
up to work with sockets as stdout and stdin.

When running in no_rawinput=1 mode (should that be renamed to 
no_raw_input?) , it executes the following code:

79                    sys.stdout.write(self.prompt)
80                    line = sys.stdin.readline()

It should read:

79                    sys.stdout.write(self.prompt)
80                    sys.stdout.flush()
81                    line = sys.stdin.readline(79

There may also be a problem with raw_input(). raw_input should flush 
stdout before asking for input. I'll submit a seperate bug report for that.


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

>Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 21:51

Message:
Logged In: YES 
user_id=126343

no_rawinput should be use_rawinput.




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

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


From noreply@sourceforge.net  Wed Mar  6 13:36:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:36:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-526384 ] Bug reports are ignored
Message-ID: <E16ibaS-0006NA-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug reports are ignored

Initial Comment:
Why are bug reports being ignored? Are you guys busy? Do you need 
help? There are a lot of people in the community who would love to 
help you. Please ask us if you need help.




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

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


From noreply@sourceforge.net  Wed Mar  6 13:37:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:37:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
Message-ID: <E16ibbc-0006Nz-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 9
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout

Initial Comment:
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)






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

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


From noreply@sourceforge.net  Wed Mar  6 13:44:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:44:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-526384 ] Bug reports are ignored
Message-ID: <E16ibiQ-0005zV-00@usw-sf-web1.sourceforge.net>

Bugs item #526384, was opened at 2002-03-06 08:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526384&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bug reports are ignored

Initial Comment:
Why are bug reports being ignored? Are you guys busy? Do you need 
help? There are a lot of people in the community who would love to 
help you. Please ask us if you need help.




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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 08:44

Message:
Logged In: YES 
user_id=6380

We're volunteers.  There are a *lot* of bug reports.  Some
of them are incorrect.  It takes a lot of time to decide
whether a reported bug deserves fixing or not.  You can help
by being patient and by adding useful information to other
bug reports (such as "confirmed on platform X.Y.Z" or "works
for me in Python 2.2", please with as much info as you can),
and by submitting patches to the patch manager (please add
an entry in the bug pointing to the patch and vice versa).

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

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


From noreply@sourceforge.net  Wed Mar  6 13:49:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:49:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-526357 ] cmd.py does not flush stdout
Message-ID: <E16ibnV-0006Fj-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: cmd.py does not flush stdout

Initial Comment:
The module cmd (located in cmd.py in the library) does not flush stdout 
before it waits for input.

What does that mean? That means that unless you are running cmd 
from the terminal, or unless stdout happens to magically flush before it 
waits for new input, that there will be no data written to stdout before it 
waits for input.

This is a problem if you want to fork() a module that uses cmd, or set it 
up to work with sockets as stdout and stdin.

When running in no_rawinput=1 mode (should that be renamed to 
no_raw_input?) , it executes the following code:

79                    sys.stdout.write(self.prompt)
80                    line = sys.stdin.readline()

It should read:

79                    sys.stdout.write(self.prompt)
80                    sys.stdout.flush()
81                    line = sys.stdin.readline(79

There may also be a problem with raw_input(). raw_input should flush 
stdout before asking for input. I'll submit a seperate bug report for that.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 08:49

Message:
Logged In: YES 
user_id=6380

Might it have occurred to you that you're the first person
ever who's using cmd in a situation where it's not talking
directly to a real human user? I agree that this should
probably be fixed, but it's got low priority compared to
many other bugs.

PS. The convention is that if you have a fix for a bug, you
submit a patch, not a bug report. And please use context
diffs in attachments, never out the patch in the initial bug
description.

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

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 07:51

Message:
Logged In: YES 
user_id=126343

no_rawinput should be use_rawinput.




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

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


From noreply@sourceforge.net  Wed Mar  6 13:50:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:50:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-526384 ] Bug reports are ignored
Message-ID: <E16iboN-00064J-00@usw-sf-web1.sourceforge.net>

Bugs item #526384, was opened at 2002-03-06 08:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526384&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Bug reports are ignored

Initial Comment:
Why are bug reports being ignored? Are you guys busy? Do you need 
help? There are a lot of people in the community who would love to 
help you. Please ask us if you need help.




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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 08:44

Message:
Logged In: YES 
user_id=6380

We're volunteers.  There are a *lot* of bug reports.  Some
of them are incorrect.  It takes a lot of time to decide
whether a reported bug deserves fixing or not.  You can help
by being patient and by adding useful information to other
bug reports (such as "confirmed on platform X.Y.Z" or "works
for me in Python 2.2", please with as much info as you can),
and by submitting patches to the patch manager (please add
an entry in the bug pointing to the patch and vice versa).

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

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


From noreply@sourceforge.net  Wed Mar  6 13:47:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:47:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
Message-ID: <E16iblN-0006Vb-00@usw-sf-web3.sourceforge.net>

Bugs item #526382, was opened at 2002-03-06 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout

Initial Comment:
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)






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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 08:47

Message:
Logged In: YES 
user_id=6380

No reason to get so upset about this. Nobody that I know
uses raw_input() in non-interactive programs. You can help
yourself by using sys.stdin.readline() instead of
raw_input(), and using an explicit sys.stdout.flush() in
your program. If you're not reading interactive input from a
real human user, that's what you should do.

PS. Don't play games with the priority.

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

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


From noreply@sourceforge.net  Wed Mar  6 13:55:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 05:55:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-526390 ] Incomplete list of escape sequences
Message-ID: <E16ibt7-0006d8-00@usw-sf-web3.sourceforge.net>

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

Category: XML
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Carter (comcol)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete list of escape sequences

Initial Comment:
There exist some special character tags (i.e. 
beginning with &) that cause exceptions in minidom - 
and probably in other modeules, too. Example below:

=== PYTHON CODE ===
import xml.dom.minidom 

def do(text):
	print "Processing: ", text
	dom = xml.dom.minidom.parseString(text)
	print "... ok"

do("<body> this is ok </body>") #ok
do("<body> &lt; &gt; &amp; &quot; </body>") #ok
do("<body> &pound;  </body>") # error


=== STDOUT ===
Processing:  <body> this is ok </body>
... ok
Processing:  <body> &lt; &gt; &amp; &quot; </body>
... ok
Processing:  <body> &pound;  </body>

=== STDERR ===
Traceback (most recent call last):
  File "err.py", line 10, in ?
    do("<body> &pound;  </body>") # exception
  File "err.py", line 5, in do
    dom = xml.dom.minidom.parseString(text)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 965, 
in parseString
    return _doparse(pulldom.parseString, args, kwargs)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 952, 
in _doparse
    toktype, rootNode = events.getEvent()
  File "C:\PYTHON22\lib\xml\dom\pulldom.py", line 255, 
in getEvent
    self.parser.feed(buf)
  File "C:\PYTHON22\lib\xml\sax\expatreader.py", line 
111, in feed
    self._err_handler.fatalError(exc)
  File "C:\PYTHON22\lib\xml\sax\handler.py", line 38, 
in fatalError
    raise exception
xml.sax._exceptions.SAXParseException: <unknown>:1:7: 
undefined entity

=== COMMENTS ===
It is also my observation that special character tags 
(aka HTML escape 
sequences) translations are scattered "hither and 
thither" throughout 
modules
in the XML subdirectory, and that it would be better 
if they were all
put in one place.

I might be persuaded to help with the maintenance work 
that this 
would require!

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

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


From noreply@sourceforge.net  Wed Mar  6 15:39:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 07:39:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
Message-ID: <E16idVm-0007aX-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout

Initial Comment:
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)






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

>Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-07 00:39

Message:
Logged In: YES 
user_id=126343

Here's some more info on the subject for those who are interested.

First off, C behaves the way Python does in this regard. So it is consistent with 
the way most programs work in Unix.

Second off, what I really should be doing is using a pseudo-tty, not plain old 
pipes. Tk has something called "expect" that does what you would expect. 
There is a project for expect for python at expectpy - 
http://sf.net/projects/expectpy

Third off, the reason why I got so excited was because I had been screwing 
around with this for a very long time. I knew it was something that was done 
elsewhere in the Unix world, I just didn't know how to do it properly. The 
behavior is totally unexpected for a newbie like me. And when I finally 
climbed through the hole at the top and understood what was happening, I 
was really upset that things were the way they were.



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 22:47

Message:
Logged In: YES 
user_id=6380

No reason to get so upset about this. Nobody that I know
uses raw_input() in non-interactive programs. You can help
yourself by using sys.stdin.readline() instead of
raw_input(), and using an explicit sys.stdout.flush() in
your program. If you're not reading interactive input from a
real human user, that's what you should do.

PS. Don't play games with the priority.

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

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


From noreply@sourceforge.net  Wed Mar  6 17:18:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 09:18:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-526039 ] devious code can crash structseqs
Message-ID: <E16if3q-00008M-00@usw-sf-web2.sourceforge.net>

Bugs item #526039, was opened at 2002-03-05 18:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526039&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: devious code can crash structseqs

Initial Comment:
Some days you feel that whenever you look closely at
something, you find bugs in it.

>>> import time
>>> class C:
...  def __getitem__(self, i):
...   raise IndexError
...  def __len__(self):
...   return 9
...
>>> time.struct_time(C())
Segmentation fault (core dumped)

This isn't hard to fix (use the PySequence_Fast API),
but I have all sorts of changes in my copy of
Objects/structseq.c and I don't want to forget this.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-06 17:18

Message:
Logged In: YES 
user_id=6656

Fixed in revision 1.5 of Objects/structseq.c.
Test in revision 1.3 of Lib/test/test_structseq.py.

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

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


From noreply@sourceforge.net  Wed Mar  6 17:19:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 09:19:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-526488 ] MachO time.daylight incorrect
Message-ID: <E16if4c-0000Wb-00@usw-sf-web3.sourceforge.net>

Bugs item #526488, was opened at 2002-03-06 12:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526488&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Jack Jansen (jackjansen)
Summary: MachO time.daylight incorrect

Initial Comment:
The MachO time.daylight variable is wrong and
MacClassic is correct.

Here are examples from both versions:

[localhost:~] dgrassi% python
Python 2.2 (#11, Jan  6 2002, 01:00:42) 
[GCC 2.95.2 19991024 (release)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> from time import *
daylight
timezone
tzname
asctime()
>>> 1
>>> 18000
>>> ('EST', 'EDT')
>>> 'Wed Mar  6 11:40:58 2002'


Python 2.2 (#124, Dec 22 2001, 17:36:41)  [CW CARBON
GUSI2 THREADS GC] on mac
Type "copyright", "credits" or "license" for more
information.
>>> from time import *
daylight
timezone
tzname
asctime()
>>> 0
>>> 18000
>>> ('', '')
>>> 'Wed Mar  6 11:40:09 2002'


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

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


From noreply@sourceforge.net  Wed Mar  6 18:07:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 10:07:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-526518 ] str(cStringIO.StringIO)
Message-ID: <E16ifoj-0000kG-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: str(cStringIO.StringIO)

Initial Comment:
The module docstring for cStringIO states
that extracting the value of an output stream
is possible via str(). This doesn't seem to
work in Python 2.2:

>>> import cStringIO
>>> s = cStringIO.StringIO()
>>> s.write("foo")
>>> s.getvalue()
'foo'
>>> str(s)
'<cStringIO.StringO object at 0x8225110>'

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

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


From noreply@sourceforge.net  Wed Mar  6 18:48:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 10:48:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-526548 ] tixwidgets.py improperly indented
Message-ID: <E16igT6-0001ge-00@usw-sf-web3.sourceforge.net>

Bugs item #526548, was opened at 2002-03-06 10:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526548&group_id=5470

Category: Demos and Tools
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Don Rozenberg (rozen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tixwidgets.py improperly indented

Initial Comment:
Python-2.2/Demo/tix/tixwidgets.py is improperly 
indented and will not run.

I am attaching a working version.

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

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


From noreply@sourceforge.net  Wed Mar  6 20:33:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 12:33:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16ii69-0002Ny-00@usw-sf-web1.sourceforge.net>

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

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2002-03-06 15:33

Message:
Logged In: YES 
user_id=149084

I'm not sure what is meant by "everyone should install from
source or the native binary for his platform."  My
understanding is that Distutils was created to provide a
uniform way to install third party packages.

It seems that bdist_dumb has problems building a package
distribution which will install properly.  What about
non-Linux or Windows systems? It rather looks like the code
is unfinished....

To quote the TODO (DISTUTILS 1.1 PLANS):

"* bdist_dumb should grow a little intelligence: let
packager choose 
whether to make archive relative to prefix or the root
(prefix is essential for proper Windows support )"

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

Comment By: Thomas Heller (theller)
Date: 2002-03-05 16:08

Message:
Logged In: YES 
user_id=11105

I expect nobody will install from a zip-file on windows, 
either.

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.


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

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

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


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

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-27 17:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 15:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




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

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


From noreply@sourceforge.net  Wed Mar  6 21:51:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 13:51:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-441279 ] ConfigParser.options return default opts
Message-ID: <E16ijJg-0003tb-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser.options return default opts

Initial Comment:
I have a config file which has the following sections

------------------
[DEFAULT]

logLevel = 9
port = 17870

[SECURITY]
user = hello

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

On python, if I do the followings:

Python 2.0 (#1, Oct 16 2000, 18:10:03) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> from ConfigParser import *
>>> f = open('/tmp/testrc', 'r')
>>> a = ConfigParser()
>>> a.defaults()
{}
>>> a.readfp(f)
>>> a.defaults()
{'port': '17870', 'loglevel': '9'}
>>> a.options("SECURITY")    
['port', 'user', 'loglevel']     <<<<<<<<!!!!!!!!!
>>> 

I thought a.options("SECURITY") will only return
['user'], however it returns everything including the
default options.

I am a bit confused.

Thanks
Joe

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 13:51

Message:
Logged In: YES 
user_id=37132

how do you see the implementation being changed?  Looking through the python bug list, it is not always 
clear where help is desired or able to be accepted.


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

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

Message:
Logged In: YES 
user_id=3066

This is an accident of the implementation; had your DEFAULT
section been named anything else (such as DEFAULT-OPTIONS),
you would not have been bitten by this.  It should not be
hard to rearrange the implementation to make the acquistion
of information from the set of default values less prone to
accidental interactions.

Assigning to myself.

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

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


From noreply@sourceforge.net  Wed Mar  6 21:58:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 13:58:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-526390 ] Incomplete list of escape sequences
Message-ID: <E16ijQc-0003Yw-00@usw-sf-web2.sourceforge.net>

Bugs item #526390, was opened at 2002-03-06 14:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526390&group_id=5470

Category: XML
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Carter (comcol)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incomplete list of escape sequences

Initial Comment:
There exist some special character tags (i.e. 
beginning with &) that cause exceptions in minidom - 
and probably in other modeules, too. Example below:

=== PYTHON CODE ===
import xml.dom.minidom 

def do(text):
	print "Processing: ", text
	dom = xml.dom.minidom.parseString(text)
	print "... ok"

do("<body> this is ok </body>") #ok
do("<body> &lt; &gt; &amp; &quot; </body>") #ok
do("<body> &pound;  </body>") # error


=== STDOUT ===
Processing:  <body> this is ok </body>
... ok
Processing:  <body> &lt; &gt; &amp; &quot; </body>
... ok
Processing:  <body> &pound;  </body>

=== STDERR ===
Traceback (most recent call last):
  File "err.py", line 10, in ?
    do("<body> &pound;  </body>") # exception
  File "err.py", line 5, in do
    dom = xml.dom.minidom.parseString(text)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 965, 
in parseString
    return _doparse(pulldom.parseString, args, kwargs)
  File "C:\PYTHON22\lib\xml\dom\minidom.py", line 952, 
in _doparse
    toktype, rootNode = events.getEvent()
  File "C:\PYTHON22\lib\xml\dom\pulldom.py", line 255, 
in getEvent
    self.parser.feed(buf)
  File "C:\PYTHON22\lib\xml\sax\expatreader.py", line 
111, in feed
    self._err_handler.fatalError(exc)
  File "C:\PYTHON22\lib\xml\sax\handler.py", line 38, 
in fatalError
    raise exception
xml.sax._exceptions.SAXParseException: <unknown>:1:7: 
undefined entity

=== COMMENTS ===
It is also my observation that special character tags 
(aka HTML escape 
sequences) translations are scattered "hither and 
thither" throughout 
modules
in the XML subdirectory, and that it would be better 
if they were all
put in one place.

I might be persuaded to help with the maintenance work 
that this 
would require!

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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-06 22:58

Message:
Logged In: YES 
user_id=21627

I cannot understand the problem. The parser rightfully
complains about &pound; - this is not one of the predefined
entities of XML. Please refer to the XML spec; only amp, lt,
and gt are predefined in XML. Everything else should and
does produce an error.

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

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


From noreply@sourceforge.net  Wed Mar  6 22:01:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 14:01:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-523301 ] ConfigParser.write(): linebreak handling
Message-ID: <E16ijT7-0003SD-00@usw-sf-web1.sourceforge.net>

Bugs item #523301, was opened at 2002-02-27 01:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523301&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Rahlf (rahlf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ConfigParser.write(): linebreak handling

Initial Comment:
ConfigParser.read() accepts line rfc822-like line
continuations:

[xxx]
line: this line is longer than my editor
   likes it

ConfigParser.write() does not handle these linebreaks
and produces:

[xxx]
line: this line is longer than my editor
likes it

which can not be read by ConfigParser.read().
This can be fixed easily by adding a
"value.replace('\n', '\n\t')" in ConfigParser.py.

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 14:01

Message:
Logged In: YES 
user_id=37132

This seems like a valid approach.  One of the pythoners want to comment?


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

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


From noreply@sourceforge.net  Wed Mar  6 22:01:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 14:01:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-526298 ] _socket unimportable
Message-ID: <E16ijTR-0003Se-00@usw-sf-web1.sourceforge.net>

Bugs item #526298, was opened at 2002-03-06 09:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526298&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Crispin Wellington (wongfeihung)
Assigned to: Nobody/Anonymous (nobody)
Summary: _socket unimportable

Initial Comment:
During build get the following a number of times

building '_socket' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC 
-DUSE_SSL=1 -I. -I/bigfree/Python-2.2/./Include 
-I/usr/local/include -IInclude/ -c 
/bigfree/Python-2.2/Modules/socketmodule.c -o 
build/temp.linux-i686-2.2/socketmodule.o
gcc -shared 
build/temp.linux-i686-2.2/socketmodule.o 
-L/usr/local/lib -lssl -lcrypto -o 
build/lib.linux-i686-2.2/_socket.so
WARNING: removing "_socket" since importing it 
failed

_socket.so builds ok. Trying to import it gives...

Python 2.2 (#2, Mar  6 2002, 16:22:26) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2
Type "help", "copyright", "credits" or "license" 
for more information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./_socket.so: undefined symbol: 
RAND_add

System info:

uname -a
Linux water 2.2.18pre21 #1 Thu Mar 8 18:04:07 WST 
2001 i686 unknown

openssl version
OpenSSL 0.9.6 24 Sep 2000

More info email Crispin Wellington 
<crispin@aeonline.net>


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-06 23:01

Message:
Logged In: YES 
user_id=21627

I believe this problem does not need fixing for Python 2.2.
Anybody running into can either update the SSL version, use
modify Modules/Setup; that setup.py tries to build all
extensions is merely for convenience.

As MAL says, this is fixed for 2.3.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-06 10:42

Message:
Logged In: YES 
user_id=38388

In Python 2.3, the socket module setup was made smarter 
and the SSL support is now optional in the sense that if
the module fails to import (e.g. due to version problems with
the installed SSL libs), socket still imports but without SSL
support.

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

Comment By: Crispin Wellington (wongfeihung)
Date: 2002-03-06 10:07

Message:
Logged In: YES 
user_id=329215

got it working. Had to uncomment one of the _socket lines 
in setup. Im surprised the default non-SSL one isn't 
uncommented by default. Perhaps it should be.



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

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


From noreply@sourceforge.net  Wed Mar  6 22:04:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 14:04:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-526102 ] Namespace error with UserList
Message-ID: <E16ijWQ-00043r-00@usw-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Charlie Fly (cfly)
Assigned to: Nobody/Anonymous (nobody)
Summary: Namespace error with UserList

Initial Comment:
I may be misunderstanding something about the merging 
of type/class and this may not be a bug.  But here 
goes.

import UserList

class A( UserList ):
   def __init__( self ):
      UserList.UserList.__init__( self )

a = A()

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'module' object is not callable

It appears that the name UserList being both module 
and class name is getting confused in the module 
namespace.


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

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-06 23:04

Message:
Logged In: YES 
user_id=21627

Closed on request of submitter.

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

Comment By: Charlie Fly (cfly)
Date: 2002-03-05 22:01

Message:
Logged In: YES 
user_id=149625

This is not a bug.  I just inherited from a module.  Opps.  
I don't know how to withdraw this thing.

cfly

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

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


From noreply@sourceforge.net  Wed Mar  6 22:16:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 14:16:08 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16ijhg-0003q0-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 01:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 14:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


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

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


From noreply@sourceforge.net  Wed Mar  6 22:15:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 14:15:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-420476 ] Python 2.1 'make test' failures: AIX 4.2
Message-ID: <E16ijhG-0003d4-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: Nobody/Anonymous (nobody)
Date: 2002-03-06 14:15

Message:
Logged In: NO 

test_pty failed for me as well - AIX 4.3.2, trying to build
python 2.2. The test tallied about 48 cpu seconds then hung
on a "close".

Mike Beddo

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

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 (Albert Chin) (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 Mar  7 00:43:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 16:43:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-526726 ] Possible bug in import.c (2.1.2)
Message-ID: <E16ilzr-0005XL-00@usw-sf-web2.sourceforge.net>

Bugs item #526726, was opened at 2002-03-06 19:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526726&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Sasmor (jeffsasmor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible bug in import.c (2.1.2)

Initial Comment:
Referencing the source distribution; file 
Python/import.c:

lines 1881 through 1884 read:

if (parent == NULL) {
 PyErr_Format(PyExc_ImportError,
 "reload(): parent %.200s not in sys.modules",name); 

It might be more correct to subsitute the variable
parentname here (rather than 'name') since it is
the parentname'd module that wasn't found.  Perhaps
there was some other intent in mind.....

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

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


From noreply@sourceforge.net  Thu Mar  7 02:07:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 18:07:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-502557 ] hmac module: default to sha, not md5
Message-ID: <E16inJa-0006tI-00@usw-sf-web3.sourceforge.net>

Bugs item #502557, was opened at 2002-01-12 01:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502557&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: hmac module: default to sha, not md5

Initial Comment:
Currently the hmac module defaults to using the md5
module as its "digest module" (digestmod).  I think a
better idea is to default to sha instead for the
following reasons:

* Unlike SHA-1, some partial breaks have been found in
the security of MD5.  Section 1 of RFC 2104 describes
this and admits that SHA-1 is a cryptographically
stronger hash function.

* There is nothing in RFC 2104 that specifies or even
alludes to which hash function should be used by 
default.  So, given the weaknesses in MD5 and the fact 
that we already have SHA-1 available, I think it makes 
sense to use that by default instead.

I'll contribute a patch for this change if you'd like.


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

Comment By: Gerhard Häring (ghaering)
Date: 2002-03-07 03:07

Message:
Logged In: YES 
user_id=163326

As the one who submitted the hmac module originally, I
confess that defaulting to md5 probably wasn't a very good
idea. As for the background: I wrote the hmac module in the
context of an smtp auth patch to smtplib, where I only
really needed auth-cram md5. I also haven't yet seen hmac
used for sha or ripemd160 in the wild. But that's not my point.

The module is part of Python since 2.2 and people might
already using the hmac module with its current defaults. So,
changing the defaults at this point will almost certainly
break existing code, which is unacceptable.

Btw. people who are into security and need a bullet-proof
hmac algorithm aren't very likely to use the defaults anyway.

Next time I submit something to the Python standard library,
I'll try to remember that "explicit is better than
implicit", as Tim Peters put it once.

I propose to close this as "WontFix".

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

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


From noreply@sourceforge.net  Thu Mar  7 02:43:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 18:43:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-520644 ] __slots__ are not pickled
Message-ID: <E16insV-0006sn-00@usw-sf-web2.sourceforge.net>

Bugs item #520644, was opened at 2002-02-20 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520644&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Samuele Pedroni (pedronis)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ are not pickled

Initial Comment:
[Posted on behalf of Kevin Jacobs]

I have been hacking on ways to make lighter-weight 
Python objects using the
__slots__ mechanism that came with Python 2.2 new-
style class.  Everything
has gone swimmingly until I noticed that slots do not 
get pickled/cPickled
at all!

Here is a simple test case:

  import pickle,cPickle
  class Test(object):
    __slots__ = ['x']
    def __init__(self):
      self.x = 66666

  test = Test()

  pickle_str  = pickle.dumps( test )
  cpickle_str = cPickle.dumps( test )

  untest  = pickle.loads( pickle_str )
  untestc = cPickle.loads( cpickle_str )

  print untest.x    # raises AttributeError
  print untextc.x   # raises AttributeError

...

see 

http://aspn.activestate.com/ASPN/Mail/Message/python-
dev/1031499

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 21:43

Message:
Logged In: YES 
user_id=6380

I've decided on a "fix" that will go into 2.2.1.

When a new-style class defines slots and does not define
__getstate__, a dummy __getstate__ will be inserted into the
class that raises an exception. If the class wants slots to
be pickled, it should define a __getstate__ method.

In 2.3, we may revise this decision. The solution space is
large, and I don't want to rush it, hence the decision to
make it fail cleanly in 2.2.1 -- that's the best I can do.
The 2.2.1 solution will be compatible with whatever we
decide to do in 2.3.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-28 14:36

Message:
Logged In: YES 
user_id=6380

Good point. So maybe it should be up to the class to define
how to pickle slots.

An alternative idea could look at the type of descriptors;
slots use a different type than properties.

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

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-28 14:29

Message:
Logged In: YES 
user_id=61408

[Guido on python-dev]
In particular, the fact that instances of classes with 
__slots__
appear picklable but lose all their slot values is a bug -- 
these
should either not be picklable unless you add a __reduce__ 
method, or
they should be pickled properly. ...
  I haven't made up my mind on how to fix this -- it would 
be
nice if __slots__ would automatically be pickled, but it's 
tricky
(although I think it's doable -- without ever referencing 
the
__slots__ variable :-).


[pedronis - my 2cts]
unless you plan some low-level (non-python-level) solution,
I think a main question is whether member and properties
are distinguishable and maybe whether among members
basic type members (file.softspace etc) and __slots__
members are distinguishable

It would be somehow strange and redundant if properties 
value would be automatically pickled (I see them as
computed value)

In java (bean) properties are not pickled and even
fields (= slots) can be marked as transient to avoid
their serialization.

In your picture it seems that all those things are
not to be dinstinguished, so probably no automatic
serialization, if there are members and given that
actually files for example cannot be pickled, would
be a reasonable solution.

Otherwise (distinguishable case) other 
automatic approaches can make sense too.

Just some - I hope valuable -  input and my opinion.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 10:03

Message:
Logged In: YES 
user_id=459565

Oops.  Please ignore the last paragraph of point #5.
Samuele's __allslots__ is fine with regard to the
example I presented.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 09:52

Message:
Logged In: YES 
user_id=459565

Samuele's sltattr.py is an interesting approach, though I 
am not entirely
sure it is necessary or feasible sufficiently address the 
significant
problems with slots via proxying __dict__ (see #5 below).  
Here is a mostly
complete list of smaller changes that are somewhat 
orthogonal to how we
address accesses to __dict__:

  1) Flatten slot lists:  Change obj.__class__.__slots__ to 
return an
     immutable list of all slot descriptors in the object 
(including all
     those of base classes).  The motivation for this is 
similar in spirit
     to storing a flattened __mro__.

     The advantages of this change are:

     a) allows for fast and explicit object reflection that 
correctly finds
        all dict attributes, all slot attributes.

     b) allows reflection implementations (like vars
(object) and pickle) to
        treat dict and slot attrs differently if we choose 
not to proxy
        __dict__.  This has several advantages, as 
explained in change #2.
        Also importantly, this way it is not possible 
to "lose" descriptors
        permanently by deleting them from 
obj.__class__.__dict__.

  2) Update reflection API even if we do not choose to 
proxy __dict__: Alter
     vars(object) to return a dictionary of all attributes, 
including both
     the contents of the non-proxied __dict__ and the valid 
attributes that
     result from iterating over __slots__ and evaluating 
the descriptors.
     The details of how this is best implemented depend on 
how we wish to
     define the behavior of modifying the resulting 
dictionary.  It could be
     either:

           a) explicitly immutable, which involves creating 
proxy objects
           b) mutable, which involves copying
           c) undefined, which means implicitly immutable

     Aside from the questions over the nature of the return 
type, this
     implementation (coupled with #1) has distinct 
advantages.  Specifically
     the native object.__dict__ has a very natural internal 
representation
     that pairs attribute names directly with values.  In 
contrast, a fair
     amount of additional work is needed to extract the 
slots that store
     values and create a dictionary of their names and 
values.  Other
     implementations will require a great deal more work 
since they would
     have to traverse though base classes to collecting 
slot descriptors.

  3) Flatten slot inheritance:  Update the new-style object 
inheritance
     mechanism to re-use slots of the same name, rather 
than creating a new
     slot and hiding the old.  This makes the inheritance 
semantics of slots
     equivalent to those of normal instance attributes and 
avoids
     introducing an ad-hoc and obscure method of data 
hiding.

  4) Update standard library to use new reflection API (and 
make them robust
     to properies at the same time) if we choose not to 
proxy __dict__.
     Virtually all of the changes are simple and involve 
updating these
     constructs:

           a) obj.__dict__
           b) obj.__dict__[blah]
           c) obj.__dict__[blah] = x

     (What these will become depends on other factors, 
including the context
      and semantics of vars(obj).)

     Here is a fairly complete list of Python 2.2 modules 
that will need to
     be updated:

       copy, copy_reg, inspect, pickle, pydoc, cPickle, 
Bastion, codeop,
       dis, doctest, gettext, ihooks, imputil, knee, pdb, 
profile, rexec,
       rlcompleter, tempfile, unittest, xmllib, xmlrpclib

    5) (NB: potentially controversial and not required) We 
could alter the
       descriptor protocol to make slots (and properties) 
more transparent
       when the values they reference do not exist.  Here 
is an example to
       illustrate this:

           class A(object):
             foo = 1

           class B(A):
             __slots__ = ('foo',)

           b = B()
           print b.foo
           > 1 or AttributeError?

        Currently an AttributeError is raised.  However, it 
is a fairly easy
        change to make AttributeErrors signal that 
attribute resolution is
        to continue until either a valid descriptor is 
evaluated, an
        instance-attribute is found, or until the 
resolution fails after
        search the meta-type, the type and the instance 
dictionary.

        The problem illustrated by the above code also 
occurs when trying to
        create proxies for __dict__, if the proxy worked on 
the basis of the
        collected slot descriptors (__allslots__ in 
Samuele's example).

I am prepared to submit patches to address each of these 
issues.  However, I
do want feedback beforehand, so that I do not waste time 
implementing
something that will never be accepted.


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

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-21 20:33

Message:
Logged In: YES 
user_id=61408

some slots more like attrs illustrative python code

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-21 12:51

Message:
Logged In: YES 
user_id=459565

This bug raises questions about what a slot really is.
After a fair amount of discussion on Python-dev, we
have come up with basically two answers:

  1) a slot is a struct-member that is part of the
     private implementation of an object.  Slots should
     have their own semantics and not be expected to
     act like Python instance attributes.

  2) slots should be treated just like dict instance
     attributes except they are allocated statically
     within the object itself, and require slightly 
     different reflection methods.

Under (1), this bug isn't really a bug.  The class should
implement a __reduce__ function or otherwise hook into
the copy_reg system.

Under (2), this bug is just the tip of the iceberg. 
There are about 8 other problems with the current 
slot implementation that need to be resolved before
slots act almost identically to normal instance attributes.
Thankfully, I am fairly confident that I can supply 
patches that can achieve this, though I am waiting for
Guido to comment on this issue when he returns from his
trip.


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

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


From noreply@sourceforge.net  Thu Mar  7 04:16:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 20:16:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-502557 ] hmac module: default to sha, not md5
Message-ID: <E16ipKh-0007kO-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: hmac module: default to sha, not md5

Initial Comment:
Currently the hmac module defaults to using the md5
module as its "digest module" (digestmod).  I think a
better idea is to default to sha instead for the
following reasons:

* Unlike SHA-1, some partial breaks have been found in
the security of MD5.  Section 1 of RFC 2104 describes
this and admits that SHA-1 is a cryptographically
stronger hash function.

* There is nothing in RFC 2104 that specifies or even
alludes to which hash function should be used by 
default.  So, given the weaknesses in MD5 and the fact 
that we already have SHA-1 available, I think it makes 
sense to use that by default instead.

I'll contribute a patch for this change if you'd like.


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

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-06 21:16

Message:
Logged In: YES 
user_id=85984

> I confess that defaulting to md5 probably wasn't a 
> very good idea.

[...]

> I propose to close this as "WontFix".

So, you make a poor decision, and Python users are
stuck with it forever?  Forget about Python 2.2, 
but why not change it for 2.3 and beyond?



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 19:17

Message:
Logged In: YES 
user_id=6380

OK, closed as suggested by Gerhard. (I suppose that there's
no easy way to tell which algorithm was used to create a
digest? Otherwise changing the default wouldn't be a
problem.)

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-03-06 19:07

Message:
Logged In: YES 
user_id=163326

As the one who submitted the hmac module originally, I
confess that defaulting to md5 probably wasn't a very good
idea. As for the background: I wrote the hmac module in the
context of an smtp auth patch to smtplib, where I only
really needed auth-cram md5. I also haven't yet seen hmac
used for sha or ripemd160 in the wild. But that's not my point.

The module is part of Python since 2.2 and people might
already using the hmac module with its current defaults. So,
changing the defaults at this point will almost certainly
break existing code, which is unacceptable.

Btw. people who are into security and need a bullet-proof
hmac algorithm aren't very likely to use the defaults anyway.

Next time I submit something to the Python standard library,
I'll try to remember that "explicit is better than
implicit", as Tim Peters put it once.

I propose to close this as "WontFix".

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

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


From noreply@sourceforge.net  Thu Mar  7 04:21:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 20:21:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-502557 ] hmac module: default to sha, not md5
Message-ID: <E16ipPh-0008PC-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: hmac module: default to sha, not md5

Initial Comment:
Currently the hmac module defaults to using the md5
module as its "digest module" (digestmod).  I think a
better idea is to default to sha instead for the
following reasons:

* Unlike SHA-1, some partial breaks have been found in
the security of MD5.  Section 1 of RFC 2104 describes
this and admits that SHA-1 is a cryptographically
stronger hash function.

* There is nothing in RFC 2104 that specifies or even
alludes to which hash function should be used by 
default.  So, given the weaknesses in MD5 and the fact 
that we already have SHA-1 available, I think it makes 
sense to use that by default instead.

I'll contribute a patch for this change if you'd like.


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

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-06 21:21

Message:
Logged In: YES 
user_id=85984

> (I suppose that there's no easy way to tell
> which algorithm was used to create a digest? 
> Otherwise changing the default wouldn't be a
> problem.)

Well, the digests are different sizes depending on
which hash function was used.  16-byte string 
for md5 and a 20-byte string for sha.

I suppose I don't see what you are getting at
though?



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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-06 21:16

Message:
Logged In: YES 
user_id=85984

> I confess that defaulting to md5 probably wasn't a 
> very good idea.

[...]

> I propose to close this as "WontFix".

So, you make a poor decision, and Python users are
stuck with it forever?  Forget about Python 2.2, 
but why not change it for 2.3 and beyond?



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 19:17

Message:
Logged In: YES 
user_id=6380

OK, closed as suggested by Gerhard. (I suppose that there's
no easy way to tell which algorithm was used to create a
digest? Otherwise changing the default wouldn't be a
problem.)

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-03-06 19:07

Message:
Logged In: YES 
user_id=163326

As the one who submitted the hmac module originally, I
confess that defaulting to md5 probably wasn't a very good
idea. As for the background: I wrote the hmac module in the
context of an smtp auth patch to smtplib, where I only
really needed auth-cram md5. I also haven't yet seen hmac
used for sha or ripemd160 in the wild. But that's not my point.

The module is part of Python since 2.2 and people might
already using the hmac module with its current defaults. So,
changing the defaults at this point will almost certainly
break existing code, which is unacceptable.

Btw. people who are into security and need a bullet-proof
hmac algorithm aren't very likely to use the defaults anyway.

Next time I submit something to the Python standard library,
I'll try to remember that "explicit is better than
implicit", as Tim Peters put it once.

I propose to close this as "WontFix".

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

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


From noreply@sourceforge.net  Thu Mar  7 04:44:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 06 Mar 2002 20:44:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-502557 ] hmac module: default to sha, not md5
Message-ID: <E16iplL-0008Es-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Nobody/Anonymous (nobody)
Summary: hmac module: default to sha, not md5

Initial Comment:
Currently the hmac module defaults to using the md5
module as its "digest module" (digestmod).  I think a
better idea is to default to sha instead for the
following reasons:

* Unlike SHA-1, some partial breaks have been found in
the security of MD5.  Section 1 of RFC 2104 describes
this and admits that SHA-1 is a cryptographically
stronger hash function.

* There is nothing in RFC 2104 that specifies or even
alludes to which hash function should be used by 
default.  So, given the weaknesses in MD5 and the fact 
that we already have SHA-1 available, I think it makes 
sense to use that by default instead.

I'll contribute a patch for this change if you'd like.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 23:44

Message:
Logged In: YES 
user_id=6380

It depends on what software is on the other end, to verify
the checksum.  If it always applies MD5 by default, we can't
change that.  But the data declares which checksum is used
in some header and the receiver reads that header, our
changing the default shouldn't cause any problems.  

I guess I don't know enough of how this is used to be able
to tell whether changing the default will cause
incompatibilities or not...

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-06 23:21

Message:
Logged In: YES 
user_id=85984

> (I suppose that there's no easy way to tell
> which algorithm was used to create a digest? 
> Otherwise changing the default wouldn't be a
> problem.)

Well, the digests are different sizes depending on
which hash function was used.  16-byte string 
for md5 and a 20-byte string for sha.

I suppose I don't see what you are getting at
though?



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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=85984

> I confess that defaulting to md5 probably wasn't a 
> very good idea.

[...]

> I propose to close this as "WontFix".

So, you make a poor decision, and Python users are
stuck with it forever?  Forget about Python 2.2, 
but why not change it for 2.3 and beyond?



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 21:17

Message:
Logged In: YES 
user_id=6380

OK, closed as suggested by Gerhard. (I suppose that there's
no easy way to tell which algorithm was used to create a
digest? Otherwise changing the default wouldn't be a
problem.)

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

Comment By: Gerhard Häring (ghaering)
Date: 2002-03-06 21:07

Message:
Logged In: YES 
user_id=163326

As the one who submitted the hmac module originally, I
confess that defaulting to md5 probably wasn't a very good
idea. As for the background: I wrote the hmac module in the
context of an smtp auth patch to smtplib, where I only
really needed auth-cram md5. I also haven't yet seen hmac
used for sha or ripemd160 in the wild. But that's not my point.

The module is part of Python since 2.2 and people might
already using the hmac module with its current defaults. So,
changing the defaults at this point will almost certainly
break existing code, which is unacceptable.

Btw. people who are into security and need a bullet-proof
hmac algorithm aren't very likely to use the defaults anyway.

Next time I submit something to the Python standard library,
I'll try to remember that "explicit is better than
implicit", as Tim Peters put it once.

I propose to close this as "WontFix".

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

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


From noreply@sourceforge.net  Thu Mar  7 08:33:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 00:33:50 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16itLS-0002G6-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 09:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

>Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

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

>Comment By: Simon Brunning (brunns)
Date: 2002-03-07 08:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 22:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


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

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


From noreply@sourceforge.net  Thu Mar  7 09:24:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 01:24:35 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16iu8Z-0002qA-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 08:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-07 09:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

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

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 08:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 22:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


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

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


From noreply@sourceforge.net  Thu Mar  7 10:01:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 02:01:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X
Message-ID: <E16iuiC-0003Fu-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Manoj Plakal (terabaap)
Assigned to: Michael Hudson (mwh)
Summary: Disable flat namespace on MacOS X

Initial Comment:

Python: v2.2
OS: MacOS X 10.1

MacOS X 10.1 introduced two forms of linking
for loadable modules: flat namespace and
two-level namespace. 

Python 2.2 is set up to use flat namespace
by default on OS X for building extension modules.

I believe that this is a problem since
it introduces spurious run-time linking
errors when loading 2 or more modules that 
happen to have common symbols. The Linux
and Windows implementations do not allow
symbols within modules to clash with
each other. This behavior also goes against
expectations of C extension module writers.

As a reproducible example, consider
two dummy modules foo (foomodule.c)
and bar (barmodule.c) both of which
are built with a common file baz.c
that contains some data variables.
With the current Python 2.2 on OS X 10.1,
only one of foo or bar can be imported,
but NOT BOTH, into the same interpreter
session.

The files can be picked up from
these URLs:
    http://yumpee.org/python/foomodule.c
    http://yumpee.org/python/barmodule.c
    http://yumpee.org/python/baz.c
    http://yumpee.org/python/setup.py

If I run "python setup.py build" with
Python 2.2 (built from the 2.2
source tarball) and then import
foo followed by bar, I get an
ImportError: "Failure linking new
module" (from Python/dynload_next.c).
If I add a call to NSLinkEditError()
to print a more detailed error message,
I see that the problem is multiple definitions
of the data variables in baz.c.

The above example works fine with Python 2.1
on Red Hat Linux 7.2 and Python 2.2a4 on Win98.

If I then edit /usr/local/lib/python2.2/Makefile
and change LDSHARED and BLDSHARED to
not use flat_namespace:
$(CC) $(LDFLAGS) -bundle -bundle_loader
/usr/local/bin/python2.2 -undefined error
then the problem is solved and I can load
both foo and bar without problems.

More info and discussion is available at
these URLs (also search groups.google.com
for "comp.lang.python OS X import bug"):

http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python
http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html

It would be great to have this simple
change be applied to Python 2.2.1.

Manoj 
terabaap@yumpee.org


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:01

Message:
Logged In: YES 
user_id=6656

OK, checked in as 
setup.py revision 1.84
configure.in revision 1.293
(configure revision 1.284)
will move across to the branch shortly -- I presume you
wanted them on the trunk too?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-01 12:22

Message:
Logged In: YES 
user_id=45365

Here's a new version of the patch, against the current state of the tree (the whitespace normalization messed it up).

And I've now tested it against Manoj's example and it works fine, so I would say we go for it.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-28 23:25

Message:
Logged In: YES 
user_id=45365

I turns out I was mistaken: BLDSHARED is used during build, LDSHARED for distutils when Python is installed. Attached is a patch (relative to release22-maint) that does two level namespaces.

It has no adverse effects on the core (i.e. make test still works fine).

Manoj: if you could test that this not only has on adverse effects but also fixes your problem that would be great. please checkout th release22-maint branch and apply this patch.

Michael: I'm assigning this to you, feel free to check it in immediately or wait for feedback from Manoj (or ignore it completely if you don't like it:-).

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 16:19

Message:
Logged In: YES 
user_id=45365

This solution still suffers from the problem we discussed on the Pythonmac-SIG, that BLDSHARED (or whatever replaces it) would need to have one value for -bundle_loader when building the standard extension modules and another during "normal operation"...

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 11:21

Message:
Logged In: YES 
user_id=45365

I usurping this bug, but I'm not sure yet whether it's a good idea to fix this for 2.2.1, as it will break other extension modules that rely on the single flat namespace.

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

Comment By: Manoj Plakal (terabaap)
Date: 2002-01-26 04:25

Message:
Logged In: YES 
user_id=150105


Another idea is to provide the option for
flat or 2-level namespace when building
extension modules on OS X, maybe as 
an extra flag passed to distutils.core.Extension
or somewhere else ...


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

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


From noreply@sourceforge.net  Thu Mar  7 10:01:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 02:01:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-508779 ] Disable flat namespace on MacOS X
Message-ID: <E16iuhs-0003Fm-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Manoj Plakal (terabaap)
Assigned to: Michael Hudson (mwh)
Summary: Disable flat namespace on MacOS X

Initial Comment:

Python: v2.2
OS: MacOS X 10.1

MacOS X 10.1 introduced two forms of linking
for loadable modules: flat namespace and
two-level namespace. 

Python 2.2 is set up to use flat namespace
by default on OS X for building extension modules.

I believe that this is a problem since
it introduces spurious run-time linking
errors when loading 2 or more modules that 
happen to have common symbols. The Linux
and Windows implementations do not allow
symbols within modules to clash with
each other. This behavior also goes against
expectations of C extension module writers.

As a reproducible example, consider
two dummy modules foo (foomodule.c)
and bar (barmodule.c) both of which
are built with a common file baz.c
that contains some data variables.
With the current Python 2.2 on OS X 10.1,
only one of foo or bar can be imported,
but NOT BOTH, into the same interpreter
session.

The files can be picked up from
these URLs:
    http://yumpee.org/python/foomodule.c
    http://yumpee.org/python/barmodule.c
    http://yumpee.org/python/baz.c
    http://yumpee.org/python/setup.py

If I run "python setup.py build" with
Python 2.2 (built from the 2.2
source tarball) and then import
foo followed by bar, I get an
ImportError: "Failure linking new
module" (from Python/dynload_next.c).
If I add a call to NSLinkEditError()
to print a more detailed error message,
I see that the problem is multiple definitions
of the data variables in baz.c.

The above example works fine with Python 2.1
on Red Hat Linux 7.2 and Python 2.2a4 on Win98.

If I then edit /usr/local/lib/python2.2/Makefile
and change LDSHARED and BLDSHARED to
not use flat_namespace:
$(CC) $(LDFLAGS) -bundle -bundle_loader
/usr/local/bin/python2.2 -undefined error
then the problem is solved and I can load
both foo and bar without problems.

More info and discussion is available at
these URLs (also search groups.google.com
for "comp.lang.python OS X import bug"):

http://groups.google.com/groups?hl=en&threadm=j4sn8uu517.fsf%40informatik.hu-berlin.de&prev=/groups%3Fnum%3D25%26hl%3Den%26group%3Dcomp.lang.python%26start%3D75%26group%3Dcomp.lang.python
http://mail.python.org/pipermail/pythonmac-sig/2002-January/004977.html

It would be great to have this simple
change be applied to Python 2.2.1.

Manoj 
terabaap@yumpee.org


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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:01

Message:
Logged In: YES 
user_id=6656

OK, checked in as 
setup.py revision 1.84
configure.in revision 1.293
(configure revision 1.284)
will move across to the branch shortly -- I presume you
wanted them on the trunk too?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-01 12:22

Message:
Logged In: YES 
user_id=45365

Here's a new version of the patch, against the current state of the tree (the whitespace normalization messed it up).

And I've now tested it against Manoj's example and it works fine, so I would say we go for it.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-28 23:25

Message:
Logged In: YES 
user_id=45365

I turns out I was mistaken: BLDSHARED is used during build, LDSHARED for distutils when Python is installed. Attached is a patch (relative to release22-maint) that does two level namespaces.

It has no adverse effects on the core (i.e. make test still works fine).

Manoj: if you could test that this not only has on adverse effects but also fixes your problem that would be great. please checkout th release22-maint branch and apply this patch.

Michael: I'm assigning this to you, feel free to check it in immediately or wait for feedback from Manoj (or ignore it completely if you don't like it:-).

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 16:19

Message:
Logged In: YES 
user_id=45365

This solution still suffers from the problem we discussed on the Pythonmac-SIG, that BLDSHARED (or whatever replaces it) would need to have one value for -bundle_loader when building the standard extension modules and another during "normal operation"...

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 11:21

Message:
Logged In: YES 
user_id=45365

I usurping this bug, but I'm not sure yet whether it's a good idea to fix this for 2.2.1, as it will break other extension modules that rely on the single flat namespace.

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

Comment By: Manoj Plakal (terabaap)
Date: 2002-01-26 04:25

Message:
Logged In: YES 
user_id=150105


Another idea is to provide the option for
flat or 2-level namespace when building
extension modules on OS X, maybe as 
an extra flag passed to distutils.core.Extension
or somewhere else ...


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

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


From noreply@sourceforge.net  Thu Mar  7 10:45:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 02:45:46 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16ivP8-0003b8-00@usw-sf-web1.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 09:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

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

>Comment By: Simon Brunning (brunns)
Date: 2002-03-07 10:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 09:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

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

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 08:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 22:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


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

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


From noreply@sourceforge.net  Thu Mar  7 13:38:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 05:38:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E16iy6j-0006Hz-00@usw-sf-web3.sourceforge.net>

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

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

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

Comment By: Mathias Palm (monos)
Date: 2002-03-07 14:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 13:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

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

Comment By: Mathias Palm (monos)
Date: 2001-10-29 12:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



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

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 20:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

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

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


From noreply@sourceforge.net  Thu Mar  7 14:59:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 06:59:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-524066 ] Override sys.stdout.write newstyle class
Message-ID: <E16izMn-0006cy-00@usw-sf-web1.sourceforge.net>

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

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Override sys.stdout.write newstyle class

Initial Comment:
Posted to python-help.

Using Python 2.2, I'm trying to create a file-like class that write in a file and on standard output. But I'm having a problem, since 'print' statement doesn't seems to call the write method when I  assign an object inheriting from 'file' to 'sys.stdout'.

The following code shows the problem:

>>> import sys
>>> class test (file):
...	def write (_, s):
...		sys.__stdout__.write (s)
...
>>> log = test ('log', 'r')
>>> log.write ('hello\n')
hello
>>> sys.stdout = log
>>> print 'hello'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor

As you can see, I'm getting error, since Python try to write to a file opened in read-only mode, and so don't call my redefined 'write' method ...

On the contrary, when using a standard class, only defining the 'write' method, I'm getting the desired behaviour.

>>> import sys
>>> class test:
...	def write (_, s):
...		sys.__stdout__.write (s)
...
>>> log = test ()
>>> log.write ('hello\n')
hello
>>> sys.stdout = log
>>> print 'hello'
hello


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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 14:59

Message:
Logged In: YES 
user_id=4923

Changing the mode to 'w' avoids the exception. However, 
even then "print 'hello'" is silent 
(though "sys.stdout.write('hello\n')" works). So perhaps 
there's a bug in print, but this is a pretty silly use
of subclassing file. And the major complaint (that Python 
throws an exception when you try to write to a file 
opened 'r') is just bogus. Of course it should throw an 
exception.

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

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


From noreply@sourceforge.net  Thu Mar  7 15:31:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 07:31:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16izs2-0006y9-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Mark Hammond (mhammond)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 15:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 08:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

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

Comment By: Gary Herron (herron)
Date: 2002-02-11 08:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 18:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 23:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 23:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 22:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


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

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


From noreply@sourceforge.net  Thu Mar  7 15:36:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 07:36:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-511261 ] WIN32 os.path.normpath('./') incorrect
Message-ID: <E16izw3-00071C-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Knight (stevenknight)
Assigned to: Nobody/Anonymous (nobody)
Summary: WIN32 os.path.normpath('./') incorrect

Initial Comment:
os.path.normpath() on WIN32 systems returns a null 
string for . followed by a directory separator:

>>> os.path.normpath('./')
''
>>> os.path.normpath('.\')
''
>>> os.path.normpath('.')
'.'
>>>

Contrast with what happens on Linux:

>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.')
'.'
>>>

Sorry, I don't have a later version than 2.1.1 
available to check whether this is fixed in a later 
version, but I did do a search for other reports of 
this bug and found none.

    --SK




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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 15:36

Message:
Logged In: YES 
user_id=4923

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.normpath('./')
'.'
>>> os.path.normpath('.\')
'.'
>>> os.path.normpath('.')
'.'
>>>


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

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


From noreply@sourceforge.net  Thu Mar  7 16:05:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 08:05:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-524066 ] Override sys.stdout.write newstyle class
Message-ID: <E16j0OX-0007T9-00@usw-sf-web2.sourceforge.net>

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

Category: Type/class unification
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Override sys.stdout.write newstyle class

Initial Comment:
Posted to python-help.

Using Python 2.2, I'm trying to create a file-like class that write in a file and on standard output. But I'm having a problem, since 'print' statement doesn't seems to call the write method when I  assign an object inheriting from 'file' to 'sys.stdout'.

The following code shows the problem:

>>> import sys
>>> class test (file):
...	def write (_, s):
...		sys.__stdout__.write (s)
...
>>> log = test ('log', 'r')
>>> log.write ('hello\n')
hello
>>> sys.stdout = log
>>> print 'hello'
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 9] Bad file descriptor

As you can see, I'm getting error, since Python try to write to a file opened in read-only mode, and so don't call my redefined 'write' method ...

On the contrary, when using a standard class, only defining the 'write' method, I'm getting the desired behaviour.

>>> import sys
>>> class test:
...	def write (_, s):
...		sys.__stdout__.write (s)
...
>>> log = test ()
>>> log.write ('hello\n')
hello
>>> sys.stdout = log
>>> print 'hello'
hello


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-07 11:05

Message:
Logged In: YES 
user_id=6380

What happens with mode 'w' is that the print statement
(actually PyFile_WriteObject()) sees that stdout is derived
from a file object, and then takes a shortcut that writes to
the underlying stdio FILE.  It's debatable whether that
could be called a bug in print.

There's so much wrong with the example that I'll just close
it as Invalid.

Try inheriting from object instead of file, then your
example works.

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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 09:59

Message:
Logged In: YES 
user_id=4923

Changing the mode to 'w' avoids the exception. However, 
even then "print 'hello'" is silent 
(though "sys.stdout.write('hello\n')" works). So perhaps 
there's a bug in print, but this is a pretty silly use
of subclassing file. And the major complaint (that Python 
throws an exception when you try to write to a file 
opened 'r') is just bogus. Of course it should throw an 
exception.

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

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


From noreply@sourceforge.net  Thu Mar  7 16:32:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 08:32:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-527022 ] raw_input non-ascii failure on Linux/KDE
Message-ID: <E16j0oS-00085H-00@usw-sf-web3.sourceforge.net>

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

Category: IDLE
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input non-ascii failure on Linux/KDE

Initial Comment:
With default encoding left as 'ascii', interactively
doing x=raw_input('say something funny: ') and 
entering a non-ascii character seems to work OK
in a textmode interactive interpreter (Linux 
Mandrake
8.1 and KDE Console, Win98) and on IDLE on Win98.  
On
IDLE with Linux Mandrake 8.1 and KDE, though:

Python 2.2 (#1, Dec 23 2001, 20:09:01) 
[GCC 2.96 20000731 (Mandrake Linux 8.1 
2.96-0.62mdk)] on linux2
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> palö
UnicodeError: ASCII encoding error: ordinal not in 
range(128)
>>> x=raw_input('say something funny: ')
say something funny: palö
Traceback (most recent call last):
  File "<pyshell#1>", line 1, in ?
    x=raw_input('say something funny: ')
TypeError: object.readline() returned non-string
>>> 

This came up on python-help (not sure what platform 
the querant was using), I originally didn't think of
it as a bug and told the querant to change the 
default encoding in site.py, but Skip doubted that
was OK and asked on python-list, where Martin said:

"In IDLE, I'd say there is a bug somewhere. I'm not 
sure what ... If there is a bug, it is ok to work 
around it with any means you find.
It would be better to report it to SF, though."

so here it is, the SF bug report as requested.


Alex


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

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


From noreply@sourceforge.net  Thu Mar  7 16:46:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 08:46:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-223599 ] Need user-centered info for Windows users.
Message-ID: <E16j11u-0007gm-00@usw-sf-web1.sourceforge.net>

Bugs item #223599, was opened at 2000-11-27 08:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=223599&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 6
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need user-centered info for Windows users.

Initial Comment:
Users ask questions like "How do I write batch files using Python?"; there should be a document that acts as a user's guide specifically for Windows users.  This could be similar to what the Macintosh Modules Reference is becoming.  This should be part of the standard documentation and could acquire the Windows module documentation.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-07 08:46

Message:
Logged In: NO 

hello! i am wantin! plz

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:37

Message:
Logged In: YES 
user_id=31392

Can we move this out of bugs and into feature requests?


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

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

Message:
Another question that should be answered in this document:  "How do I create/recall modules?"  This one comes up most with first time programmers and users from environments that don't expose source code as editable text files (VB?).

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

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


From noreply@sourceforge.net  Thu Mar  7 17:40:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 09:40:43 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16j1sh-0002TA-00@usw-sf-web2.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


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

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 10:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 15:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 15:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 08:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

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

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


From noreply@sourceforge.net  Thu Mar  7 17:45:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 09:45:19 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16j1x9-0002cZ-00@usw-sf-web2.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 20:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 12:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 17:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 17:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 10:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

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

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


From noreply@sourceforge.net  Thu Mar  7 17:49:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 09:49:21 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16j213-0000MZ-00@usw-sf-web3.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 20:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 12:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 17:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 17:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 10:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

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

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


From noreply@sourceforge.net  Thu Mar  7 18:07:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 10:07:04 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16j2IC-0008VT-00@usw-sf-web1.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


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

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 11:07

Message:
Logged In: YES 
user_id=85984

Yes, I think formataddr() is a much better
name.  dump_address_pair() is not very intuitive
at all IMO.




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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 10:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 15:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

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

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 15:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 08:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

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

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


From noreply@sourceforge.net  Thu Mar  7 18:07:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 10:07:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-527059 ] ZODB cores with 2.2.1 CVS
Message-ID: <E16j2IN-0000Yp-00@usw-sf-web3.sourceforge.net>

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

Category: None
>Group: 3rd Party
>Status: Closed
>Resolution: Invalid
>Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ZODB cores with 2.2.1 CVS

Initial Comment:
As summary.  May happen with other extension packages;
this is the first I've tried.

Obviously 2.2.1 can't go out until we figure out why
this is happening.  Currently backing out changes and
working by binary chop, but help appreciated!

Verification also appreciated.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:07

Message:
Logged In: YES 
user_id=6656

That would seem to be it, yes.

Should probably try to work out why, but I'm not sure it's
going to be our problem.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 17:57

Message:
Logged In: YES 
user_id=6656

Or maybe it's --with-pymalloc that does it?

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

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


From noreply@sourceforge.net  Thu Mar  7 18:17:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 10:17:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-527059 ] ZODB cores with 2.2.1 CVS
Message-ID: <E16j2Ro-0003ia-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: 3rd Party
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ZODB cores with 2.2.1 CVS

Initial Comment:
As summary.  May happen with other extension packages;
this is the first I've tried.

Obviously 2.2.1 can't go out until we figure out why
this is happening.  Currently backing out changes and
working by binary chop, but help appreciated!

Verification also appreciated.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-07 13:17

Message:
Logged In: YES 
user_id=31435

--with-pymalloc problems shouldn't hold up anything.  
obmalloc is still experimental, and it appears hard for 
large C extensions *not* to screw up when it's enabled 
(thanks to widespread misues of Python's mem-mgmt API).

It would help if you attached an example that provokes ZODB 
failure.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 13:08

Message:
Logged In: YES 
user_id=6656

I'll leave this open, just in case.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 13:07

Message:
Logged In: YES 
user_id=6656

That would seem to be it, yes.

Should probably try to work out why, but I'm not sure it's
going to be our problem.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 12:57

Message:
Logged In: YES 
user_id=6656

Or maybe it's --with-pymalloc that does it?

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

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


From noreply@sourceforge.net  Thu Mar  7 18:26:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 10:26:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-527059 ] ZODB cores with 2.2.1 CVS
Message-ID: <E16j2ar-0000m1-00@usw-sf-web3.sourceforge.net>

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

Category: None
Group: 3rd Party
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ZODB cores with 2.2.1 CVS

Initial Comment:
As summary.  May happen with other extension packages;
this is the first I've tried.

Obviously 2.2.1 can't go out until we figure out why
this is happening.  Currently backing out changes and
working by binary chop, but help appreciated!

Verification also appreciated.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:26

Message:
Logged In: YES 
user_id=6656

The ZODB test-suite?

I got the impression "roughly anything at all".

I could be more helpful :) but I don't have a pymalloc-ed
binary around anymore and it's home time here.

Agree it's likely to be exactly the sort of thing I fixed in
the _cursesmodule.c a whiles back PyMem_Del vs PyObject_Del.

Good grief, sf is having a bad day today!

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-07 18:17

Message:
Logged In: YES 
user_id=31435

--with-pymalloc problems shouldn't hold up anything.  
obmalloc is still experimental, and it appears hard for 
large C extensions *not* to screw up when it's enabled 
(thanks to widespread misues of Python's mem-mgmt API).

It would help if you attached an example that provokes ZODB 
failure.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:08

Message:
Logged In: YES 
user_id=6656

I'll leave this open, just in case.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:07

Message:
Logged In: YES 
user_id=6656

That would seem to be it, yes.

Should probably try to work out why, but I'm not sure it's
going to be our problem.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 17:57

Message:
Logged In: YES 
user_id=6656

Or maybe it's --with-pymalloc that does it?

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

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


From noreply@sourceforge.net  Thu Mar  7 20:44:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 12:44:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E16j4kV-0001pV-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

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

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


From noreply@sourceforge.net  Fri Mar  8 00:54:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 16:54:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-527064 ] bogus URLs cause exception in httplib
Message-ID: <E16j8ej-0001PE-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Cox (brian_cox)
>Assigned to: Jeremy Hylton (jhylton)
Summary: bogus URLs cause exception in httplib

Initial Comment:
This is a partial HTTP header from IIS:

HTTP/1.1 302 Redirect
Server: Microsoft-IIS/5.0
Date: Wed, 06 Mar 2002 19:41:34 GMT
P3P: CP='ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo 
PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE 
PUR UNI'
Location: 
http://www.microsoft.comhttp://support.microsoft.com/de
fault.aspx?LN=RU

Notice the 'Location:'; this causes a ValueError 
exception in httplib in class HTTPConnection, method
_set_hostport(): port = int(host[i+1:])

I fixed this by doing:

  try: port = int(host[i+1:])
  except ValueError: raise InvalidHost(host)

and adding: 

class InvalidHost(HTTPException):
	def __init__(self, host):
		self.host = host
	def __str__(self):
		return "invalid host- '%s'" % self.host





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

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


From noreply@sourceforge.net  Fri Mar  8 00:55:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 16:55:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-527059 ] ZODB cores with 2.2.1 CVS
Message-ID: <E16j8fX-0001RS-00@usw-sf-web1.sourceforge.net>

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

Category: None
Group: 3rd Party
Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ZODB cores with 2.2.1 CVS

Initial Comment:
As summary.  May happen with other extension packages;
this is the first I've tried.

Obviously 2.2.1 can't go out until we figure out why
this is happening.  Currently backing out changes and
working by binary chop, but help appreciated!

Verification also appreciated.

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 00:55

Message:
Logged In: YES 
user_id=31392

Does this patch fix the problem?  I've been meaning to look 
at it since I noticed it yesterday, but haven't had time.

http://sourceforge.net/tracker/index.php?
func=detail&aid=516768&group_id=15628&atid=315628



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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:26

Message:
Logged In: YES 
user_id=6656

The ZODB test-suite?

I got the impression "roughly anything at all".

I could be more helpful :) but I don't have a pymalloc-ed
binary around anymore and it's home time here.

Agree it's likely to be exactly the sort of thing I fixed in
the _cursesmodule.c a whiles back PyMem_Del vs PyObject_Del.

Good grief, sf is having a bad day today!

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-07 18:17

Message:
Logged In: YES 
user_id=31435

--with-pymalloc problems shouldn't hold up anything.  
obmalloc is still experimental, and it appears hard for 
large C extensions *not* to screw up when it's enabled 
(thanks to widespread misues of Python's mem-mgmt API).

It would help if you attached an example that provokes ZODB 
failure.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:08

Message:
Logged In: YES 
user_id=6656

I'll leave this open, just in case.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:07

Message:
Logged In: YES 
user_id=6656

That would seem to be it, yes.

Should probably try to work out why, but I'm not sure it's
going to be our problem.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 17:57

Message:
Logged In: YES 
user_id=6656

Or maybe it's --with-pymalloc that does it?

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

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


From noreply@sourceforge.net  Fri Mar  8 01:00:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 17:00:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-526518 ] str(cStringIO.StringIO)
Message-ID: <E16j8kk-0005ni-00@usw-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Jeremy Hylton (jhylton)
Summary: str(cStringIO.StringIO)

Initial Comment:
The module docstring for cStringIO states
that extracting the value of an output stream
is possible via str(). This doesn't seem to
work in Python 2.2:

>>> import cStringIO
>>> s = cStringIO.StringIO()
>>> s.write("foo")
>>> s.getvalue()
'foo'
>>> str(s)
'<cStringIO.StringO object at 0x8225110>'

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 01:00

Message:
Logged In: YES 
user_id=31392

Can you quote exactly what in the module doc string says 
that str() works?  The code never worked this way, so I'll 
fix the doc string if you tell me what to fix.


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

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


From noreply@sourceforge.net  Fri Mar  8 01:06:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 17:06:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] file iterators: unintuitive behavior
Message-ID: <E16j8pl-0001xD-00@usw-sf-web1.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: file iterators: unintuitive behavior

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 01:06

Message:
Logged In: YES 
user_id=31392

If I understand the checkin message Guido wrote for 2.113, 
he didn't intend the current behavior.

> file_getiter(): make iter(file) be equivalent to 
>file.xreadlines().
> This should be faster.
>
> This means:
>
> (1) "for line in file:" won't work if the xreadlines 
module can't be
>    imported.
>
> (2) The body of "for line in file:" shouldn't use the 
file directly;
>     the effects (e.g. of file.readline(), file.seek() or 
even
>     file.tell()) would be undefined because of the 
buffering that goes
>     on in the xreadlines module.


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

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 06:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


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

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


From noreply@sourceforge.net  Fri Mar  8 01:06:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 17:06:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-525520 ] httplib/HTTPConnetion: wrong HOST header
Message-ID: <E16j8qK-0001yz-00@usw-sf-web1.sourceforge.net>

Bugs item #525520, was opened at 2002-03-04 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525520&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 5
Submitted By: Andreas Jung (ajung)
>Assigned to: Jeremy Hylton (jhylton)
Summary: httplib/HTTPConnetion: wrong HOST header

Initial Comment:
h = httplib.HTTPConnection('blabla.xx.com:5000")
h.request('GET','/',{},{'host':'www.foo.com'})

should produce a HTTP header "HOST: www.foo.com".
Instead HTTPConnection sends two HOST headers:

HOST: blabla.xx.com:5000

and 

HOST:www.foo.com

A host header in the headers dictionary should override
the default host header in any case.



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

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


From noreply@sourceforge.net  Fri Mar  8 04:45:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 20:45:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-515943 ] searching for data with \0 in mmapf
Message-ID: <E16jCFr-0007X2-00@usw-sf-web3.sourceforge.net>

Bugs item #515943, was opened at 2002-02-11 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515943&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
>Assigned to: A.M. Kuchling (akuchling)
Summary: searching for data with \0 in mmapf

Initial Comment:

searching for values with embeded nulls returns
incorrect results, eg:

import mmap,os
fp=open('foo','w+')
fp.write('foo')
fp.write('\1'*(mmap.PAGESIZE-3))
data='foo\0data'
fp.write(data)fp.write('\1'*(mmap.PAGESIZE-len(data)))
m=mmap.mmap(fp.fileno(),2*mmap.PAGESIZE)
fp.close()
print 'data found at:',m.find(data)
m.close()
os.unlink(foo)

returns 0 where mmap.PAGESIZE is required


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

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


From noreply@sourceforge.net  Fri Mar  8 05:20:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 21:20:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-515943 ] searching for data with \0 in mmapf
Message-ID: <E16jCnu-00020a-00@usw-sf-web1.sourceforge.net>

Bugs item #515943, was opened at 2002-02-11 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515943&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
>Assigned to: Tim Peters (tim_one)
Summary: searching for data with \0 in mmapf

Initial Comment:

searching for values with embeded nulls returns
incorrect results, eg:

import mmap,os
fp=open('foo','w+')
fp.write('foo')
fp.write('\1'*(mmap.PAGESIZE-3))
data='foo\0data'
fp.write(data)fp.write('\1'*(mmap.PAGESIZE-len(data)))
m=mmap.mmap(fp.fileno(),2*mmap.PAGESIZE)
fp.close()
print 'data found at:',m.find(data)
m.close()
os.unlink(foo)

returns 0 where mmap.PAGESIZE is required


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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-08 00:20

Message:
Logged In: YES 
user_id=31435

Reassigned to me since I believe I already fixed it.  The 
code here uses s# to parse the needle, but ignores the 
length, stopping at a null byte instead.  Fixing it is 
straightforward.

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

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


From noreply@sourceforge.net  Fri Mar  8 05:45:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 07 Mar 2002 21:45:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-515943 ] searching for data with \0 in mmapf
Message-ID: <E16jDBh-0002c7-00@usw-sf-web1.sourceforge.net>

Bugs item #515943, was opened at 2002-02-11 10:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515943&group_id=5470

Category: Extension Modules
>Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Grzegorz Makarewicz (makaron)
Assigned to: Tim Peters (tim_one)
Summary: searching for data with \0 in mmapf

Initial Comment:

searching for values with embeded nulls returns
incorrect results, eg:

import mmap,os
fp=open('foo','w+')
fp.write('foo')
fp.write('\1'*(mmap.PAGESIZE-3))
data='foo\0data'
fp.write(data)fp.write('\1'*(mmap.PAGESIZE-len(data)))
m=mmap.mmap(fp.fileno(),2*mmap.PAGESIZE)
fp.close()
print 'data found at:',m.find(data)
m.close()
os.unlink(foo)

returns 0 where mmap.PAGESIZE is required


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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-08 00:45

Message:
Logged In: YES 
user_id=31435

Fixed, in

Lib/test/test_mmap.py; new revision: 1.20
Modules/mmapmodule.c; new revision: 2.38

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 00:20

Message:
Logged In: YES 
user_id=31435

Reassigned to me since I believe I already fixed it.  The 
code here uses s# to parse the needle, but ignores the 
length, stopping at a null byte instead.  Fixing it is 
straightforward.

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

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


From noreply@sourceforge.net  Fri Mar  8 09:08:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 01:08:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] breaking file iter loop leaves file in stale state
Message-ID: <E16jGMI-0000iJ-00@usw-sf-web1.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: breaking file iter loop leaves file in stale state

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


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

>Comment By: Just van Rossum (jvr)
Date: 2002-03-08 10:08

Message:
Logged In: YES 
user_id=92689

At the cost of, what, sensible, predictable semantics?
- fast is better than slow
- but slow is better than unpredictable
Or something...

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 02:16

Message:
Logged In: YES 
user_id=31435

I'm sure Guido was aware of this.  Making the simplest-to-
spell idiom as fast as possible was a deliberate decision 
at the time.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 02:06

Message:
Logged In: YES 
user_id=31392

If I understand the checkin message Guido wrote for 2.113, 
he didn't intend the current behavior.

> file_getiter(): make iter(file) be equivalent to 
>file.xreadlines().
> This should be faster.
>
> This means:
>
> (1) "for line in file:" won't work if the xreadlines 
module can't be
>    imported.
>
> (2) The body of "for line in file:" shouldn't use the 
file directly;
>     the effects (e.g. of file.readline(), file.seek() or 
even
>     file.tell()) would be undefined because of the 
buffering that goes
>     on in the xreadlines module.


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

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 07:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


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

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


From noreply@sourceforge.net  Fri Mar  8 09:59:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 01:59:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-527059 ] ZODB cores with 2.2.1 CVS
Message-ID: <E16jH9d-0002oW-00@usw-sf-web2.sourceforge.net>

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

Category: None
Group: 3rd Party
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ZODB cores with 2.2.1 CVS

Initial Comment:
As summary.  May happen with other extension packages;
this is the first I've tried.

Obviously 2.2.1 can't go out until we figure out why
this is happening.  Currently backing out changes and
working by binary chop, but help appreciated!

Verification also appreciated.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-08 09:59

Message:
Logged In: YES 
user_id=6656

Yep, with the patch the test suite runs successfully.

Closing (again).

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 00:55

Message:
Logged In: YES 
user_id=31392

Does this patch fix the problem?  I've been meaning to look 
at it since I noticed it yesterday, but haven't had time.

http://sourceforge.net/tracker/index.php?
func=detail&aid=516768&group_id=15628&atid=315628



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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:26

Message:
Logged In: YES 
user_id=6656

The ZODB test-suite?

I got the impression "roughly anything at all".

I could be more helpful :) but I don't have a pymalloc-ed
binary around anymore and it's home time here.

Agree it's likely to be exactly the sort of thing I fixed in
the _cursesmodule.c a whiles back PyMem_Del vs PyObject_Del.

Good grief, sf is having a bad day today!

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-07 18:17

Message:
Logged In: YES 
user_id=31435

--with-pymalloc problems shouldn't hold up anything.  
obmalloc is still experimental, and it appears hard for 
large C extensions *not* to screw up when it's enabled 
(thanks to widespread misues of Python's mem-mgmt API).

It would help if you attached an example that provokes ZODB 
failure.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:08

Message:
Logged In: YES 
user_id=6656

I'll leave this open, just in case.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 18:07

Message:
Logged In: YES 
user_id=6656

That would seem to be it, yes.

Should probably try to work out why, but I'm not sure it's
going to be our problem.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 17:57

Message:
Logged In: YES 
user_id=6656

Or maybe it's --with-pymalloc that does it?

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

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


From noreply@sourceforge.net  Fri Mar  8 11:39:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 03:39:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-526518 ] str(cStringIO.StringIO)
Message-ID: <E16jIiX-0003BJ-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Jeremy Hylton (jhylton)
Summary: str(cStringIO.StringIO)

Initial Comment:
The module docstring for cStringIO states
that extracting the value of an output stream
is possible via str(). This doesn't seem to
work in Python 2.2:

>>> import cStringIO
>>> s = cStringIO.StringIO()
>>> s.write("foo")
>>> s.getvalue()
'foo'
>>> str(s)
'<cStringIO.StringO object at 0x8225110>'

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

>Comment By: Walter Dörwald (doerwalter)
Date: 2002-03-08 12:39

Message:
Logged In: YES 
user_id=89016

Here is the relevant line from the docstring:
"""
  value=an_output_stream.getvalue() # str(an_output_stream) 
works too!
"""



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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 02:00

Message:
Logged In: YES 
user_id=31392

Can you quote exactly what in the module doc string says 
that str() works?  The code never worked this way, so I'll 
fix the doc string if you tell me what to fix.


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

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


From noreply@sourceforge.net  Fri Mar  8 13:43:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 05:43:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-522393 ] Doesn't build on SGI
Message-ID: <E16jKeX-0004gm-00@usw-sf-web3.sourceforge.net>

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

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Doesn't build on SGI

Initial Comment:
On the SGI I can't build the current 2.2.1 from CVS.
I get an undefined error on pthread_detach in the link step for python:
ld32: ERROR 33: Unresolved text symbol "pthread_detach" -- 1st referenced by libpython2.2.a(thread.o).


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

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-08 14:43

Message:
Logged In: YES 
user_id=45365

Checked in as configure.in 1.294, configure 1.285.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-07 21:39

Message:
Logged In: YES 
user_id=6380

This works for me on Linux.  Jack, I suggest that you check
it in and mark it as a bugfix candidate; hopefully if there
are problems with it  on other platforms will be found out
by someone on a different platform. Make sure to mark it as
a bugfix candidate, unless you want to check it in on the
2.2 maintenance branch yourself.

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-27 00:04

Message:
Logged In: YES 
user_id=45365

Guido, I'm assigning this to you as 90% of the checkins relating to pthreads are yours. I've attached a patch to configure.in which not only tests availability of pthread_create without special options but also of pthread_detach. If you think has a good chance of being safe for other OSes too please let me know.

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

Comment By: Michael Hudson (mwh)
Date: 2002-02-25 14:55

Message:
Logged In: YES 
user_id=6656

Oh, the joy of unix.  Special case the snot out of SGI in
configure.in?

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

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-25 14:24

Message:
Logged In: YES 
user_id=45365

Ouch! You are right: the trunk also doesn't build, and probably 2.2 doesn't build either. I've never checked this, because I always build --without-thread on SGI.

I've found the problem: libc contains a partial implementation of pthreads, which does include pthread_create but not pthread_detach. For the full implementation you need to add -lpthread to your link step.

But the autoconf test tests only for pthread_create(), so it thinks no extra link options are needed.

I think we should reassign this to a pthread guru, but I'm not sure who qualifies. Simply adding a pthread_detach() call to the autotest may be worse, if I read thread_pthread.h correctly thread_detach() isn't defined in all flavors of pthreads.

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

Comment By: Michael Hudson (mwh)
Date: 2002-02-25 13:35

Message:
Logged In: YES 
user_id=6656

OK, this is odd.  Does the trunk build?  Did 2.2 build?  I
can't easily find any branch changes that would account for
this.  I haven't looked very hard yet.   Will do so later.

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

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


From noreply@sourceforge.net  Fri Mar  8 13:48:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 05:48:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-527384 ] test_descr coredumps on OSX framewk bl
Message-ID: <E16jKj8-0005QJ-00@usw-sf-web2.sourceforge.net>

Bugs item #527384, was opened at 2002-03-08 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527384&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 8
Submitted By: Jack Jansen (jackjansen)
Assigned to: Michael Hudson (mwh)
Summary: test_descr coredumps on OSX framewk bl

Initial Comment:
As of today test_descr started coredumping when doing a build with --enable-framework on Mac OS X. (it was fine last wednesday). If you run the test standalone (import test.test_descr; test.test_descr.test_main()) the crash happens after output
Testing inheritance from basic types...

The non-framework build has no problems.

I have no idea what has changed and you probably do, so please give me a lead...

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

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


From noreply@sourceforge.net  Fri Mar  8 14:08:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 06:08:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-527384 ] test_descr coredumps on OSX framewk bl
Message-ID: <E16jL37-0005eF-00@usw-sf-web2.sourceforge.net>

Bugs item #527384, was opened at 2002-03-08 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527384&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 8
Submitted By: Jack Jansen (jackjansen)
Assigned to: Michael Hudson (mwh)
Summary: test_descr coredumps on OSX framewk bl

Initial Comment:
As of today test_descr started coredumping when doing a build with --enable-framework on Mac OS X. (it was fine last wednesday). If you run the test standalone (import test.test_descr; test.test_descr.test_main()) the crash happens after output
Testing inheritance from basic types...

The non-framework build has no problems.

I have no idea what has changed and you probably do, so please give me a lead...

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

>Comment By: Michael Hudson (mwh)
Date: 2002-03-08 14:08

Message:
Logged In: YES 
user_id=6656

Well, the obvious candidate would seem to be the "disable
flat namespace" patch, no?

I'm not likely to get to this before Monday, now.

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

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


From noreply@sourceforge.net  Fri Mar  8 17:03:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 09:03:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-212317 ] os.rename transparent handling of cross-filesystem issues
Message-ID: <E16jNm1-0003VK-00@usw-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Closed
Resolution: Later
Priority: 3
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: os.rename transparent handling of cross-filesystem issues

Initial Comment:
On some systems (specifically, Linux), the rename system call will throw
an EXDEV error if rename is used across filesystems.  It would be convenient for the user if os.rename were extended to handle this transparently (like most mv commands do).

The benefits of this. . .getting rid of code like the following:

try:
    os.rename('ff','/tmp/ff')
except:
    open('/tmp/ff','w').write(open('ff','r').read())
    os.unlink('ff')

Actually, the real benefit is that code (written by morons like myself) using os.rename will continue to work even after the administrator moves the target directory to another filesystem.

I took a quick look at posixmodule.c.  A quick hack changes posix_2str's
signature to the following:

PyObject *args
char *format
int (*func)(const char*, const char *)
int (*special_handler)(const char *, const char *)

and the inner function to:

if (res != 0)
    if ((! special_handler) || (*special_handler)(path1,path2))
         return posix_error()

Of course, then a smart copy routine (includes an unlink step).  The most unclear thing at this point is what to do with the errno.  Would a failure in
the errorhandler report the original errno or its own errno???

Personally, a more general solution would allow the user (python-level) to optionally pass in *their own* error handling function/method.




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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-08 09:03

Message:
Logged In: NO 

also unix weenies expect rename() to be atomic. making
it non-atomic can break lots of code that is carefully
crafted to survive nfs, or do locking with rename(), etc.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-30 10:43

Message:
Copying files (and directories) properly is a very platform specific task -- there are lots of pitfalls that the copying code has to watch out for, e.g. copying files with "holes", properly copying all metadata, copying special files... I think that the os.rename() call is not the proper place to implement all this. But it's a useful feature nevertheless, and could perhaps be accommodated by a higher level function in the shutil module (which has the basic copying primitives).


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2000-09-15 13:01

Message:
Moved to PEP 42 as a feature request for a post-2.0 version of Python.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-09-07 15:05

Message:
Please do triage on this bug.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2000-08-25 07:44

Message:
revisit this after 2.0


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

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


From noreply@sourceforge.net  Fri Mar  8 17:13:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 09:13:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-479469 ] File copy fails on True64 AFS file syste
Message-ID: <E16jNvi-0007aY-00@usw-sf-web2.sourceforge.net>

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

Category: Distutils
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: A.M. Kuchling (akuchling)
Summary: File copy fails on True64 AFS file syste

Initial Comment:
The following report comes from an MMTK user who has a peculiar installation problem which is probably caused by some Distutils bug/feature:

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

As an aside, I'm having problems with the installation of MMTK itself on Alpha/Tru64.  I keep getting these:

copying MMTK/Database/Groups/aspartic_acid_uni2 -> /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups
error: /afs/bi/v/@sys/languages/python/latest/lib/python2.0/site-packages/MMTK/Database/Groups/aspartic_acid_uni2: Not owner

The file is copied, but the installation process halts there. I am able to proceed by rerunning the python setup.py install; it notices that that file got there OK, copies the next one, and halts again.

As you notice, we have the AFS file system (whose chmod/chown semantics are quite different from regular UNIX). This is not a problem on Linux, HP, SGI or Sun, only on Alpha. Also, it does not matter whether I have my normal account or the administrator account on AFS. What is the installation program trying to do and is it altogether necessary?

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

The setup.py script is attached. The file mentioned above is one of the data files that end up in the data_files variable.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 12:13

Message:
Logged In: YES 
user_id=11375

No response to last question from me, so I'm marking this
bug as closed.


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

Comment By: A.M. Kuchling (akuchling)
Date: 2002-02-01 13:31

Message:
Logged In: YES 
user_id=11375

Revision 1.12 of Lib/distutils/file_util.py now unlinks the
destination file
before copying to it.  Perhaps this will fix the problems on
AFS.

(Let me know if it doesn't.)


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

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


From noreply@sourceforge.net  Fri Mar  8 17:47:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 09:47:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-486527 ] xmlrpclib can produce ill-formed XML
Message-ID: <E16jOSY-00071t-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: xmlrpclib can produce ill-formed XML

Initial Comment:
I discovered this when a control character got into a 
string.

import xmlrpclib
data = xmlrpclib.dumps( (chr(17),) )
print data

The resulting XML output isn't well-formed, because 
chr(17) isn't a legal character.  The fix is 
conceptually simple -- just check for illegal 
characters in the dump_string() method -- but I'm not 
sure how to do this check efficiently.  Fredrik, 
would it be OK with you to use a regex?






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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 12:47

Message:
Logged In: YES 
user_id=11375

Added some text to rev. 1.6 of libxmlrpclib.tex to 
explain this issue.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2001-11-28 14:31

Message:
Logged In: YES 
user_id=11375

An xmlescape codec wouldn't help with this; it could turn 
chr(17) into &#17;, but that character is still illegal.
Fixing the docs seems the most reasonable thing to do;
I'll try to contribute a documentation patch.






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

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-28 14:10

Message:
Logged In: YES 
user_id=38388

I suppose a xmlescape codec would be a good addition to the
set of codecs in Python. Maybe for 2.3...

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

Comment By: Fredrik Lundh (effbot)
Date: 2001-11-28 13:22

Message:
Logged In: YES 
user_id=38376

I ignored this on purpose: instead of forcing everyone to 
pay a (rather big) performance penalty, the application 
must make sure to use the right data type.  The 
documentation probably needs fixing, though...

</F>

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

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


From noreply@sourceforge.net  Fri Mar  8 17:57:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 09:57:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-523301 ] ConfigParser.write(): linebreak handling
Message-ID: <E16jOce-00078B-00@usw-sf-web3.sourceforge.net>

Bugs item #523301, was opened at 2002-02-27 04:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523301&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Rahlf (rahlf)
>Assigned to: A.M. Kuchling (akuchling)
Summary: ConfigParser.write(): linebreak handling

Initial Comment:
ConfigParser.read() accepts line rfc822-like line
continuations:

[xxx]
line: this line is longer than my editor
   likes it

ConfigParser.write() does not handle these linebreaks
and produces:

[xxx]
line: this line is longer than my editor
likes it

which can not be read by ConfigParser.read().
This can be fixed easily by adding a
"value.replace('\n', '\n\t')" in ConfigParser.py.

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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:01

Message:
Logged In: YES 
user_id=37132

This seems like a valid approach.  One of the pythoners want to comment?


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

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


From noreply@sourceforge.net  Fri Mar  8 18:12:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 10:12:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-523301 ] ConfigParser.write(): linebreak handling
Message-ID: <E16jOr1-0008Cc-00@usw-sf-web2.sourceforge.net>

Bugs item #523301, was opened at 2002-02-27 04:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523301&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Rahlf (rahlf)
Assigned to: A.M. Kuchling (akuchling)
Summary: ConfigParser.write(): linebreak handling

Initial Comment:
ConfigParser.read() accepts line rfc822-like line
continuations:

[xxx]
line: this line is longer than my editor
   likes it

ConfigParser.write() does not handle these linebreaks
and produces:

[xxx]
line: this line is longer than my editor
likes it

which can not be read by ConfigParser.read().
This can be fixed easily by adding a
"value.replace('\n', '\n\t')" in ConfigParser.py.

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 13:12

Message:
Logged In: YES 
user_id=11375

Your patch isn't quite correct, as the same translation also
has to be performed on the keys being written out to the 
[DEFAULT] section.  It also needs to call str() on the value 
in case it's an integer or something like that.

A corrected version of the patch has been checked in to CVS 
as rev. 1.39 of ConfigParser.py.  Thanks!



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

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:01

Message:
Logged In: YES 
user_id=37132

This seems like a valid approach.  One of the pythoners want to comment?


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

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


From noreply@sourceforge.net  Fri Mar  8 18:27:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 10:27:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-491820 ] asynchat.async_chat missing methods
Message-ID: <E16jP5e-0007Pq-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: asynchat.async_chat missing methods

Initial Comment:
asynchat.ascync_chat is an abstract class.  To use it
you have to 
subclass it and define (at least)
collect_incoming_data and 
found_terminator.  These
methods are both called from other 
asynchat_chat
methods.  They should probably be defined to 
raise
NotImplementedError.  This shuts up a couple
pychecker 
errors, but more importantly, makes it 
obvious to people 
reading the source code or running
pydoc that they are part of the 
formal interface.

I can't check anything in right now, but here 
are
a couple methods that I think should work.

def 
collect_incoming_data(self, data):
        raise 
NotImplementedError, "must be implemented in subclass"

def 
found_terminator(self):
        raise NotImplementedError, "must 
be implemented in subclass"



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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 13:27

Message:
Logged In: YES 
user_id=11375

Good idea; done in rev. 1.16 of asynchat.py.


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

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


From noreply@sourceforge.net  Fri Mar  8 18:47:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 10:47:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-522682 ] pydoc: HTML not escaped
Message-ID: <E16jPOt-0007aG-00@usw-sf-web3.sourceforge.net>

Bugs item #522682, was opened at 2002-02-25 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522682&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc: HTML not escaped

Initial Comment:
In the part 'Data and non-method functions', the 
variables are not escaped for HTML. I discovered this 
while looking at pyweblib.forms[1], which uses some 
HTML like <form>, <input>, etc. in it's docstrings. 
Also, \n isn't replaced by <br>.

I'm not sure what the new behavior should be, but I do 
know that this is quite ugly to see(and it can break 
all of the layout, with a nicely placed </table>).

[1]
http://www.stroeder.com/pylib/PyWebLib/pydoc/pyweblib.f
orms.html

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 13:47

Message:
Logged In: YES 
user_id=11375

It looks like this bug was fixed by a recent checkin (rev.
1.58 of pydoc.py).  Can you please grab a copy of pydoc.py
from the current CVS and see if the problem is fixed?


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

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


From noreply@sourceforge.net  Fri Mar  8 19:39:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 11:39:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-405939 ] HTTPConnection Host hdr wrong w/ proxy
Message-ID: <E16jQD5-00081i-00@usw-sf-web3.sourceforge.net>

Bugs item #405939, was opened at 2001-03-05 05: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: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Ernie Sasaki (esasaki)
Assigned to: Jeremy Hylton (jhylton)
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: Jeremy Hylton (jhylton)
Date: 2002-03-08 19:39

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.45 of httplib.py.


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

Comment By: Greg Stein (gstein)
Date: 2001-08-18 10: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 23: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 20: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 08: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  Fri Mar  8 19:57:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 11:57:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib test causes SSL core dump
Message-ID: <E16jQUB-0000ms-00@usw-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib test causes SSL core dump

Initial Comment:
The test() function in the httplib module attempts to 
connect to SourceForge using SSL.  I've tried this 
with Python 2.1 and up, using OpenSSL 0.9.6.  The read 
call fails with an SSL error, then python dumps core 
instead OpenSSL.

I don't know if this is a Python bug or an SSL bug.  
At first blush, I'd guess that Python is probably 
using OpenSSL incorrectly.

Here's the Python traceback.

Traceback (most recent call last):
  File "../Lib/httplib.py", line 895, in ?
    test()
  File "../Lib/httplib.py", line 884, in test
    status, reason, headers = hs.getreply()
  File "../Lib/httplib.py", line 734, in getreply
    response = self._conn.getresponse()
  File "../Lib/httplib.py", line 579, in getresponse
    response = self.response_class(self.sock)
  File "../Lib/httplib.py", line 99, in __init__
    self.fp = sock.makefile('rb', 0)
  File "../Lib/httplib.py", line 614, in makefile
    buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version number')

And the gdb stack trace.

#0 0x401e96d1 in sk_pop_free () 
from /usr/local/ssl/lib/libcrypto.so.0.9.6
(gdb) bt
#0 0x401e96d1 in sk_pop_free () 
from /usr/local/ssl/lib/libcrypto.so.0.9.6
#1 0x40191068 in __DTOR_END__ () 
from /usr/local/ssl/lib/libssl.so.0.9.6
#2 0xe853 in ?? ()
Cannot access memory at address 0x5614ec83.


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

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


From noreply@sourceforge.net  Fri Mar  8 21:13:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 13:13:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-506647 ] random.cunifvariate() incorrect?
Message-ID: <E16jRfi-0000ic-00@usw-sf-web3.sourceforge.net>

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

>Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (abcdefghijklmno)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.cunifvariate() incorrect?

Initial Comment:
random.cunifvariate() currently is defined as:
  return (mean + arc * (self.random() - 0.5)) % _pi

First of all, this returns values in the range [0, pi)
due to the modulus, which really makes it a
semi-circular distribution, not circular (but I'm not a
mathie, so perhaps I'm wrong).

I think the normalizing step ("% _pi", or whatever this
gets changed to) should probably be mentioned in the
documentation for this function; it caught me by
surprise, and I expect it will catch some others too.  

With this defintion, the function returns a random
value in the range [mean-arc/2, mean+arc/2).  The docs
say that arc, like mean, can only be in the range
[0,pi].  This would imply that one cannot get values in
the other half of the circle, i.e. [pi, 2*pi).  Since
there doesn't seem to be anything stopping the caller
from using an arc in [0,2*pi], perhaps the
documentation should be updated?


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

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


From noreply@sourceforge.net  Fri Mar  8 21:14:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 13:14:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-506741 ] ugly floats using str() on tuples,lists
Message-ID: <E16jRhI-0000jY-00@usw-sf-web3.sourceforge.net>

Bugs item #506741, was opened at 2002-01-22 01:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506741&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.1
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Tim Wegener (twegener)
Assigned to: Nobody/Anonymous (nobody)
Summary: ugly floats using str() on tuples,lists

Initial Comment:
Python version 2.1.1
Using str() to make floats look pretty works for 
str(some_float_variable), but for 
str(tuple_of_floats) the output floats are still 
ugly. 

In Python 2.1.1:
>>> a=1.9
>>> a
1.8999999999999999
>>> str(a)
'1.9'
>>> (a,a)
(1.8999999999999999, 1.8999999999999999)
>>> str((a,a))
'(1.8999999999999999, 1.8999999999999999)'
>>> [a,a]
[1.8999999999999999, 1.8999999999999999]
>>> str([a,a])
'[1.8999999999999999, 1.8999999999999999]'
>>>

In Python 1.5.2
>>> a=1.9
>>> str(a)
'1.9'
>>> str((a,a))
'(1.9, 1.9)'
>>> str([a,a])
'[1.9, 1.9]'
>>>



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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 21:14

Message:
Logged In: YES 
user_id=31392

Martin is right.  The str/repr with sequences is a long-
standing issue of contention, but this isn't a bug.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-23 07:52

Message:
Logged In: YES 
user_id=21627

This is not a bug. If you want to format objects in a
certain non-standard way, you must write your own algorithm
to do so. See pprint.py for an example.

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

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


From noreply@sourceforge.net  Fri Mar  8 21:15:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 13:15:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken
Message-ID: <E16jRi2-0000kA-00@usw-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: rfc822 long header continuation broken

Initial Comment:
I don't believe this is fixed in 2.1.2 or 2.2, but
haven't checked.

The code in rfc822.Message.readheaders incorrectly
unfolds long message headers. The relevant information
from rfc2822 is in section 2.2.3. In short:

"""
The process of moving from this folded multiple-line
representation of a header field to its single line
representation is called "unfolding". Unfolding is
accomplished by simply removing any CRLF that is
immediately followed by WSP.  Each header field should
be treated in its unfolded form for further syntactic
and semantic evaluation.
"""

This means that the code in readheaders:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = (self.dict[headerseen] + "\n " +
line.strip())
                self.dict[headerseen] = x.strip()
                continue

should be:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = self.dict[headerseen] + line
                self.dict[headerseen] = x.strip()
                continue

ie. no stripping of the leading whitespace and no
adding the newline.


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

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

Message:
Logged In: YES 
user_id=21627

Even though it might not matter, I don't think changing it
would hurt, either, and the change brings it definitely
closer to following the word of RFC 2822. 

If no case is brought forward where it matters, fixing it
for 2.3 alone should be sufficient.

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

Comment By: Richard Jones (richard)
Date: 2002-01-16 12:12

Message:
Logged In: YES 
user_id=6405

Yes, we had someone submit a bug report on the roundup 
users mailing list because someone had sent a message to 
the roundup mail gateway which was split. The client was 
extra-specially broken, since it split in the middle of a 
word (which is not to spec), but the more general case of 
folding on whitespace will cause roundup problems since I 
hadn't expected there to be any newlines in the header.

I can modify roundup to strip out the newline, but it'd be 
nice to have rfc822.Message not put it in there...



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-16 02:47

Message:
Logged In: YES 
user_id=6380

Richard, have you found a situation where it matters? I
thought that usually the next phase calls for normalizing
whitespace by squashing repeated spaces/tabs and removing
them from front and back.


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

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


From noreply@sourceforge.net  Fri Mar  8 21:21:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 13:21:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-506741 ] ugly floats using str() on tuples,lists
Message-ID: <E16jRo7-0005dc-00@usw-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
>Group: Not a Bug
Status: Closed
Resolution: None
Priority: 5
Submitted By: Tim Wegener (twegener)
Assigned to: Nobody/Anonymous (nobody)
Summary: ugly floats using str() on tuples,lists

Initial Comment:
Python version 2.1.1
Using str() to make floats look pretty works for 
str(some_float_variable), but for 
str(tuple_of_floats) the output floats are still 
ugly. 

In Python 2.1.1:
>>> a=1.9
>>> a
1.8999999999999999
>>> str(a)
'1.9'
>>> (a,a)
(1.8999999999999999, 1.8999999999999999)
>>> str((a,a))
'(1.8999999999999999, 1.8999999999999999)'
>>> [a,a]
[1.8999999999999999, 1.8999999999999999]
>>> str([a,a])
'[1.8999999999999999, 1.8999999999999999]'
>>>

In Python 1.5.2
>>> a=1.9
>>> str(a)
'1.9'
>>> str((a,a))
'(1.9, 1.9)'
>>> str([a,a])
'[1.9, 1.9]'
>>>



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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-08 16:21

Message:
Logged In: YES 
user_id=31435

Since this was closed as "not a bug", changed the Group to 
say so.>    "%.*f" % (0, -0.003)


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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 16:14

Message:
Logged In: YES 
user_id=31392

Martin is right.  The str/repr with sequences is a long-
standing issue of contention, but this isn't a bug.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-23 02:52

Message:
Logged In: YES 
user_id=21627

This is not a bug. If you want to format objects in a
certain non-standard way, you must write your own algorithm
to do so. See pprint.py for an example.

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

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


From noreply@sourceforge.net  Fri Mar  8 21:44:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 13:44:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-477487 ] Build Problems on AIX 4.3.3
Message-ID: <E16jSA2-0005tf-00@usw-sf-web1.sourceforge.net>

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

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build Problems on AIX 4.3.3

Initial Comment:
Problems in building Python 2.2b1 in AIX 4.3.3 with IBM
vac++ compiler. I think the problem is not compiler
specific.

The build tries to execute the following code:
../Modules/makexp_aix Modules/python.exp ""
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o
python \
                Modules/ccpython.o \
                libpython2.2.a -ldl  -lpthread   -lm  

The first part executes ok:
../Modules/makexp_aix Modules/python.exp "" libpython2.2.a

In the second part the call to the linker is missing.
Something like :
xlC_r -Wl,-bE:Modules/python.exp -lld -o python
Modules/ccpython.o libpython2.2.a -ldl  -lpthread   -lm
dose the job

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 21:44

Message:
Logged In: YES 
user_id=31392

Fix in rev. 1.295 of configure.in.


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

Comment By: Sven Rubben (srubben)
Date: 2002-01-16 07:28

Message:
Logged In: YES 
user_id=418821

Sorry if I wasn't clear, please change this line:

LINKCC="\/Modules/makexp_aix Modules/python.exp
\\ \; $(LINKCC)";;

to

LINKCC="\/Modules/makexp_aix Modules/python.exp
\\ \; $LINKCC";;



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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:38

Message:
Logged In: YES 
user_id=6380

srubben: I don't understand your suggestion. What brackets?
Can you type in the correct line?

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

Comment By: Sven Rubben (srubben)
Date: 2002-01-15 09:57

Message:
Logged In: YES 
user_id=418821

The following lines in the configure script (the check for
LINKCC) should be changed:
	case $ac_sys_system in
	AIX*)
	   LINKCC="\/Modules/makexp_aix Modules/python.exp
\\ \; $(LINKCC)";;

The brackets around the $(LINKCC) should be removed.

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

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


From noreply@sourceforge.net  Sat Mar  9 02:30:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 18:30:30 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-527668 ] pydoc should respect __all__
Message-ID: <E16jWcw-00054g-00@usw-sf-web2.sourceforge.net>

Feature Requests item #527668, was opened at 2002-03-08 21:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=527668&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc should respect __all__

Initial Comment:
If __all__ is set in a module, pydoc should only 
document those attributes, IMO. For example:


# foo.py
__all__ = [ 'hello' ]
from sys import *

def hello():
    """hi there"""
    print "hi"

def goodbye():
    """ciao"""
    print "bye"


>>> import foo, pydoc
>>> pydoc.help(foo)
Help on module foo:

NAME
    foo

FILE
    e:\temp\foo.py

FUNCTIONS
    goodbye()
        ciao
    
    hello()
        hi there

DATA
    __all__ = ['hello']
    __file__ = 'foo.py'
    __name__ = 'foo'


-------

Whereas right now it dumps everything from sys. A 
little proof-of-concept (not quite a patch):

import imp
import foo as _foo # do this programmatically using 
the imp module
if !hasattr(_foo,'__all__'):
    _foo.__all__ = _foo.__dict__.keys()
foo = imp.new_module('foo')

# Get exported attributes
for a in _foo.__all__:
    setattr(foo, a, getattr(_foo, a))

# Get special attributes
for a in _foo.__dict__.keys():
    if len(a) > 4 and a[:2] == '__' and a[-2:] == '__':
        setattr(foo, a, getattr(_foo, a))

import pydoc
pydoc.help(foo)





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=527668&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 03:40:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 19:40:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jXim-0005lE-00@usw-sf-web2.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
>Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 19:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 04:58:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 20:58:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?)
Message-ID: <E16jYwB-0001pL-00@usw-sf-web1.sourceforge.net>

Bugs item #503837, was opened at 2002-01-15 13:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Guido van Rossum (gvanrossum)
Summary: type.__module__ problems (again?)

Initial Comment:
Gelukkig nieuwjaar,

This is probably related to previous bug reports on
type.__module__.

Given

--- A.py ---
class meta1(type):
    def __new__(tp, name, bases, attr):
        return type.__new__(tp, name, bases, attr)

class meta2(type):
    pass

--- B.py ---
import A
class B1(object):
    __metaclass__ = A.meta1

class B2(object):
    __metaclass__ = A.meta2

------------

I get the following session.

Python 2.2 (#4, Jan  7 2002, 11:59:25) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import B
>>> B.B1.__module__
'A'
>>> B.B2.__module__
'B'

Among others, this problem causes pydoc to only display
documentation for B2 as part of the docs for module B.

Presumably, the behaviour for B2 is correct.

Regards,

Roeland Rengelink


----------------------------------------------------------------------

>Comment By: Roeland Rengelink (rengelink)
Date: 2002-03-09 04:58

Message:
Logged In: YES 
user_id=302601

This bug is now also reported under #516532

----------------------------------------------------------------------

Comment By: Roeland Rengelink (rengelink)
Date: 2002-01-16 08:16

Message:
Logged In: YES 
user_id=302601

I came upon the other bug reports by browsing the bug
database, but I didn't write the numbers down. The only ones
I did find again when I looked this morning are:

#442501
#487390

Neither are really related to the problem reported here
though,

Thanks for the fix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 21:07

Message:
Logged In: YES 
user_id=6380

Fixed in compile.c 2.235, by initializing __module__ to the
contents of the global variable __name__ at the start of the
class statement. Not 100% satisfied with that, but can't
come up with something better right now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:33

Message:
Logged In: YES 
user_id=6380

You're right. This is because __module__ is taken from the
globals of the currently executing Python code.

This is clearly a bug. I'll have to think about how to fix
it -- maybe the class statement will have to set it.

I can't find the other bug reports related to __module__;
the SF search box apparently searches for "module" when I
type that in the search box, and that hits about every other
bug report ever submitted, including closed ones. :-(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 05:00:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 21:00:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jYxj-0001qY-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-09 00:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 19:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 05:00:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 21:00:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-516532 ] cls.__module__ and metaclasses
Message-ID: <E16jYxy-0001ql-00@usw-sf-web1.sourceforge.net>

Bugs item #516532, was opened at 2002-02-12 18:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516532&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: cls.__module__ and metaclasses

Initial Comment:
In the following the __module__ attribute is incorrect:

file foo.py:
---------------
class foo(object):
  class __metaclass__(type):
    def __new__(cls, name, bases, dict):
      return type.__new__(cls, name, bases, dict)
---------------
file bar.py:
---------------
import foo

class bar(foo.foo):
   pass
---------------
With these two files the following test prints
the wrong result:

>>> import bar
>>> bar.bar.__module__
'foo'


----------------------------------------------------------------------

Comment By: Roeland Rengelink (rengelink)
Date: 2002-03-09 05:00

Message:
Logged In: YES 
user_id=302601

I think this is a duplicate of #503837

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516532&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 05:45:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 21:45:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jZg5-0002IT-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 23:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-09 05:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 05:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 03:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 03:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-06 00:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 00:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 05:47:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 21:47:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-507262 ] GNU --option syntax not supported
Message-ID: <E16jZhL-0006xC-00@usw-sf-web2.sourceforge.net>

Bugs item #507262, was opened at 2002-01-22 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470

Category: Python Interpreter Core
>Group: Feature Request
Status: Open
Resolution: None
>Priority: 2
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: GNU --option syntax not supported

Initial Comment:
It would be good if the python interpreter 
supported standard GNU --log style options as
well.

Jari

//root@W2KPICASSO /usr/bin $ python -V
Python 2.2
//root@W2KPICASSO /usr/bin $ python --help
Unknown option: --
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Try `python -h' for more information.
//root@W2KPICASSO /usr/bin $ python -h    
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Options and arguments (and corresponding environment 
variables):
-c cmd : program passed in as string (terminates 
option list)
-d     : debug output from parser (also PYTHONDEBUG=x)
-E     : ignore environment variables (such as 
PYTHONPATH)
-h     : print this help message and exit
-i     : inspect interactively after running script, 
(also PYTHONINSPECT=x)
         and force prompts, even if stdin does not 
appear to be a terminal
-O     : optimize generated bytecode (a tad; also 
PYTHONOPTIMIZE=x)
-OO    : remove doc-strings in addition to the -O 
optimizations
-Q arg : division options: -Qold (default), -Qwarn, -
Qwarnall, -Qnew
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-
tt: issue errors)
-u     : unbuffered binary stdout and stderr (also 
PYTHONUNBUFFERED=x)
-U     : Unicode literals: treats '...' literals like 
u'...'
-v     : verbose (trace import statements) (also 
PYTHONVERBOSE=x)
-V     : print the Python version number and exit
-W arg : warning control (arg is 
action:message:category:module:lineno)
-x     : skip first line of source, allowing use of 
non-Unix forms of #!cmd
file   : program read from script file
-      : program read from stdin (default; interactive 
mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup 
(no default)
PYTHONPATH   : ':'-separated list of directories 
prefixed to the
               default module search path.  The result 
is sys.path.
PYTHONHOME   : alternate <prefix> directory (or 
<prefix>:<exec_prefix>).
               The default module search path uses 
<prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements 
(Windows).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 06:08:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 08 Mar 2002 22:08:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-525520 ] httplib/HTTPConnetion: wrong HOST header
Message-ID: <E16ja1V-0006AV-00@usw-sf-web3.sourceforge.net>

Bugs item #525520, was opened at 2002-03-04 14:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525520&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Jeremy Hylton (jhylton)
Summary: httplib/HTTPConnetion: wrong HOST header

Initial Comment:
h = httplib.HTTPConnection('blabla.xx.com:5000")
h.request('GET','/',{},{'host':'www.foo.com'})

should produce a HTTP header "HOST: www.foo.com".
Instead HTTPConnection sends two HOST headers:

HOST: blabla.xx.com:5000

and 

HOST:www.foo.com

A host header in the headers dictionary should override
the default host header in any case.



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-09 06:08

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.46 of httplib.py


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525520&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 10:12:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 02:12:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows DLL/C++ info needs review
Message-ID: <E16jdqH-00013C-00@usw-sf-web2.sourceforge.net>

Bugs item #225003, was opened at 2000-12-08 16: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 DLL/C++ info needs review

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: Martin v. Löwis (loewis)
Date: 2002-03-09 11:12

Message:
Logged In: YES 
user_id=21627

Information on building with distutils has been added in a
separate section now.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-09 11:12

Message:
Logged In: YES 
user_id=21627

Information on building with distutils has been added in a
separate section now.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:38

Message:
Logged In: YES 
user_id=31392

Fred, It sounds like this task is done or almost done.  Can 
we close the bug report?


----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2001-12-14 13:44

Message:
Logged In: YES 
user_id=60314

I have reviewed Doc/ext/windows.tex, rev=1.3.  Every issue I
had noticed seems fixed very well.  The only remaining
problem I can see are many mentions of python15.lib at the
end of the documents; these should presumably be changed
to python22.lib (a mention of version dependency of these
numbers would probably be a good idea).

Great job!



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-13 18:23

Message:
Logged In: YES 
user_id=3066

The instructions for building extensions on Windows have
been completely replaced in Doc/ext/windows.tex revision
1.3.  The DLL discussion and C++ usage documentation still
needs to be reviewed, but the known-broken docs have been
corrected.

Lowering the priority of the remaining aspects of this
report, and changing the summary line.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-12 06:53

Message:
Logged In: YES 
user_id=3066

This is closely related to SF bug #221671.  Bumping the
priority to match.

I'll plan to get this done for 2.2rc1; Alex, I'll expect you
to review the updated material once the release candidate is
out so I can get your comments before the final release.  ;-)

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2001-08-17 09: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  Sat Mar  9 13:13:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 05:13:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16jgfS-0001xx-00@usw-sf-web3.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 14:03:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 06:03:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-507262 ] GNU --option syntax not supported
Message-ID: <E16jhRl-00076n-00@usw-sf-web1.sourceforge.net>

Bugs item #507262, was opened at 2002-01-22 18:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 2
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: GNU --option syntax not supported

Initial Comment:
It would be good if the python interpreter 
supported standard GNU --log style options as
well.

Jari

//root@W2KPICASSO /usr/bin $ python -V
Python 2.2
//root@W2KPICASSO /usr/bin $ python --help
Unknown option: --
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Try `python -h' for more information.
//root@W2KPICASSO /usr/bin $ python -h    
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Options and arguments (and corresponding environment 
variables):
-c cmd : program passed in as string (terminates 
option list)
-d     : debug output from parser (also PYTHONDEBUG=x)
-E     : ignore environment variables (such as 
PYTHONPATH)
-h     : print this help message and exit
-i     : inspect interactively after running script, 
(also PYTHONINSPECT=x)
         and force prompts, even if stdin does not 
appear to be a terminal
-O     : optimize generated bytecode (a tad; also 
PYTHONOPTIMIZE=x)
-OO    : remove doc-strings in addition to the -O 
optimizations
-Q arg : division options: -Qold (default), -Qwarn, -
Qwarnall, -Qnew
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-
tt: issue errors)
-u     : unbuffered binary stdout and stderr (also 
PYTHONUNBUFFERED=x)
-U     : Unicode literals: treats '...' literals like 
u'...'
-v     : verbose (trace import statements) (also 
PYTHONVERBOSE=x)
-V     : print the Python version number and exit
-W arg : warning control (arg is 
action:message:category:module:lineno)
-x     : skip first line of source, allowing use of 
non-Unix forms of #!cmd
file   : program read from script file
-      : program read from stdin (default; interactive 
mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup 
(no default)
PYTHONPATH   : ':'-separated list of directories 
prefixed to the
               default module search path.  The result 
is sys.path.
PYTHONHOME   : alternate <prefix> directory (or 
<prefix>:<exec_prefix>).
               The default module search path uses 
<prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements 
(Windows).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-09 09:03

Message:
Logged In: YES 
user_id=6380

Rather than quoting the Python -h output (with which I am
quite familiar, thank you!), you could explain what --log is
supposed to do. What does it do and why do you want it? (BTW
Python is not GNU software.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507262&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 14:30:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 06:30:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-225744 ] httplib does not check if port is valid (easy to fix?)
Message-ID: <E16jhs1-0003mC-00@usw-sf-web2.sourceforge.net>

Bugs item #225744, was opened at 2000-12-13 22: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: Jeremy Hylton (jhylton)
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: Skip Montanaro (montanaro)
Date: 2002-03-09 08:30

Message:
Logged In: YES 
user_id=44345

Here's a suggested patch that matches the exception
structure used by httplib.  It adds a subclass of 
HTTPException called InvalidURL and raises that when
int(port) gets incorrect input.


----------------------------------------------------------------------

Comment By: MartinThomas (martinthomas)
Date: 2001-01-10 15: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 16: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 16: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 08: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  Sat Mar  9 15:24:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 07:24:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jii8-0007xg-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-09 10:24

Message:
Logged In: YES 
user_id=33168

RedHat 7.2, glibc-2.2.4-13

Before patch:
   w/o -lieee    w/-lieee
   FAILED        Passed

After patch:
   w/o -lieee    w/-lieee
   Passed        Passed

Works for me.
I also attached a modified script to what Tim posted on
python-dev which prints out if there is a problem.  Silence
is golden.

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2002-03-09 02:52

Message:
Logged In: YES 
user_id=190903

Red Hat Linux release 6.2, with some updates.
Running on an Alpha box.  No changes to -ieee flag
(both compiled without -ieee)

Compared stock Python 2.2 vs. most recent CVS.

Using Python 2.2:
pow(1e-200, 2) and 1e-200**2 give OverflowError

Current CVS:
pow(1e-200, 2) and 1e-200**2 give 0.0


----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-09 01:18

Message:
Logged In: YES 
user_id=76089

Python 2.2 on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give OverflowError
Current CVS Python on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give 0.0

I did not do anything with -lieee, just ./configure && make


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-09 00:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 00:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 19:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 16:03:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 08:03:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-527816 ] (1).__nonzero__() dumps a core
Message-ID: <E16jjJh-0003nY-00@usw-sf-web3.sourceforge.net>

Bugs item #527816, was opened at 2002-03-09 17:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: (1).__nonzero__() dumps a core

Initial Comment:
Essentially, all is said.
This is running Pyhton 2.2 on Linux.

>From a rapid analysis, this comes from  a
the slot nb_nonzero of tp_as_number which returns an
integer being called from a wrapper object which
expects a function returning a PyObject* .

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 16:13:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 08:13:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-527816 ] (1).__nonzero__() dumps a core
Message-ID: <E16jjTC-0004qU-00@usw-sf-web2.sourceforge.net>

Bugs item #527816, was opened at 2002-03-09 16:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: (1).__nonzero__() dumps a core

Initial Comment:
Essentially, all is said.
This is running Pyhton 2.2 on Linux.

>From a rapid analysis, this comes from  a
the slot nb_nonzero of tp_as_number which returns an
integer being called from a wrapper object which
expects a function returning a PyObject* .

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-09 16:13

Message:
Logged In: YES 
user_id=6656

Oops!  Good spot.  Raised priority.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 17:31:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 09:31:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jkhC-0004iV-00@usw-sf-web3.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 17:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

Comment By: Christopher Lee (clee)
Date: 2002-03-09 11:31

Message:
Logged In: YES 
user_id=1426

Tim Peter's fix in CVS looks good on my machine:

redhat 7.2, linux kernel 2.4.17, glibc 2.2.4-19.3, gcc 2.96-98

Python 2.3a0 (check out from cvs Sat Mar  9 11:26:31 CST 2002)

 ./python test_ieee.py 
x = 1e200
y = 1/x
check math.pow(x, 2): got math range error -OK
check math.pow(y, 2): got zero-OK
check pow(x, 2) got (34, 'Numerical result out of range') -OK
check pow(y, 2) got zero-OK
check x**2 got (34, 'Numerical result out of range') -OK
check y**2 got zero-OK

when running the following code
import math
x = 1e200
y = 1/x
print "x = 1e200"
print "y = 1/x"

try:
    print "check math.pow(x, 2):", 
    math.pow(x, 2)  # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"


print "check math.pow(y, 2):", 
a=math.pow(y, 2)  # expect 0.
if a == 0.0:
    print "got zero-OK"
else:
    print "didn't get zero-FAIL"

try:
    print "check pow(x, 2)", 
    pow(x, 2)       # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check pow(y, 2)", 
a=pow(y, 2)       # expect 0.
if a == 0.0: print "got zero-OK"

try:
    print "check x**2",
    x**2            # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check y**2",
a=y**2            # expect 0.
if a==0.0:
    print "got zero-OK"





----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-09 09:24

Message:
Logged In: YES 
user_id=33168

RedHat 7.2, glibc-2.2.4-13

Before patch:
   w/o -lieee    w/-lieee
   FAILED        Passed

After patch:
   w/o -lieee    w/-lieee
   Passed        Passed

Works for me.
I also attached a modified script to what Tim posted on
python-dev which prints out if there is a problem.  Silence
is golden.

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2002-03-09 01:52

Message:
Logged In: YES 
user_id=190903

Red Hat Linux release 6.2, with some updates.
Running on an Alpha box.  No changes to -ieee flag
(both compiled without -ieee)

Compared stock Python 2.2 vs. most recent CVS.

Using Python 2.2:
pow(1e-200, 2) and 1e-200**2 give OverflowError

Current CVS:
pow(1e-200, 2) and 1e-200**2 give 0.0


----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-09 00:18

Message:
Logged In: YES 
user_id=76089

Python 2.2 on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give OverflowError
Current CVS Python on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give 0.0

I did not do anything with -lieee, just ./configure && make


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 23:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 23:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 21:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 21:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 18:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 18:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 18:11:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 10:11:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16jlJl-0001N1-00@usw-sf-web1.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 14:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 18:14:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 10:14:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16jlMn-000690-00@usw-sf-web2.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2002-03-09 18:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 14:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Sat Mar  9 19:18:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 11:18:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16jmMD-00026S-00@usw-sf-web1.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 15:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-09 11:18

Message:
Logged In: NO 

This problem was fixed in Python-20020309 for my box.  I am
running Debian Gnu Linux 2.2.19 ppc on a New World iMac.
The default configure did not add -lieee to LIBS and that
python did not give the underflow errors that python2.2
did.

----------------------------------------------------------------------

Comment By: Christopher Lee (clee)
Date: 2002-03-09 09:31

Message:
Logged In: YES 
user_id=1426

Tim Peter's fix in CVS looks good on my machine:

redhat 7.2, linux kernel 2.4.17, glibc 2.2.4-19.3, gcc 2.96-98

Python 2.3a0 (check out from cvs Sat Mar  9 11:26:31 CST 2002)

 ./python test_ieee.py 
x = 1e200
y = 1/x
check math.pow(x, 2): got math range error -OK
check math.pow(y, 2): got zero-OK
check pow(x, 2) got (34, 'Numerical result out of range') -OK
check pow(y, 2) got zero-OK
check x**2 got (34, 'Numerical result out of range') -OK
check y**2 got zero-OK

when running the following code
import math
x = 1e200
y = 1/x
print "x = 1e200"
print "y = 1/x"

try:
    print "check math.pow(x, 2):", 
    math.pow(x, 2)  # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"


print "check math.pow(y, 2):", 
a=math.pow(y, 2)  # expect 0.
if a == 0.0:
    print "got zero-OK"
else:
    print "didn't get zero-FAIL"

try:
    print "check pow(x, 2)", 
    pow(x, 2)       # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check pow(y, 2)", 
a=pow(y, 2)       # expect 0.
if a == 0.0: print "got zero-OK"

try:
    print "check x**2",
    x**2            # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check y**2",
a=y**2            # expect 0.
if a==0.0:
    print "got zero-OK"





----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-09 07:24

Message:
Logged In: YES 
user_id=33168

RedHat 7.2, glibc-2.2.4-13

Before patch:
   w/o -lieee    w/-lieee
   FAILED        Passed

After patch:
   w/o -lieee    w/-lieee
   Passed        Passed

Works for me.
I also attached a modified script to what Tim posted on
python-dev which prints out if there is a problem.  Silence
is golden.

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2002-03-08 23:52

Message:
Logged In: YES 
user_id=190903

Red Hat Linux release 6.2, with some updates.
Running on an Alpha box.  No changes to -ieee flag
(both compiled without -ieee)

Compared stock Python 2.2 vs. most recent CVS.

Using Python 2.2:
pow(1e-200, 2) and 1e-200**2 give OverflowError

Current CVS:
pow(1e-200, 2) and 1e-200**2 give 0.0


----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-08 22:18

Message:
Logged In: YES 
user_id=76089

Python 2.2 on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give OverflowError
Current CVS Python on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give 0.0

I did not do anything with -lieee, just ./configure && make


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 21:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 21:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 19:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 19:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 16:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 16:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:18:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:18:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-426866 ] urllib and socket fail with MS proxy
Message-ID: <E16jrz8-0005tn-00@usw-sf-web1.sourceforge.net>

Bugs item #426866, was opened at 2001-05-24 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Jeremy Hylton (jhylton)
Summary: urllib and socket fail with MS proxy 

Initial Comment:
Both urllib and socket fail to work with MS proxy with 
winsock client install.

urllib's proxy detection will correctly detect the 
existing of the proxy server but fail to work with it. 
It will return an empty page when an read() is issued.

socket will report 1006 winsock error.

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 19:18

Message:
Logged In: YES 
user_id=44345

Jeremy,

I assigned this to you simply because you commented on 
it.
It was submitted anonymously and the OP never responded 
to
your comment.  I think it should be marked "invalid" and
closed.  Whaddya think?

Skip


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 11:16

Message:
Logged In: YES 
user_id=31392

Can you provide more details?  What is MS proxy?  What URLs 
have you tried and what exactly is the response -- headers 
would help?  Under what conditions does socket raise a 
winsock error?

Do socket and urllib work on your platform without the 
proxy?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:20:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:20:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16js0S-0002Bw-00@usw-sf-web2.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 18:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:20

Message:
Logged In: YES 
user_id=31435

Thanks, all!   That confirmed success on each kind of box 
originally complained about, and others I didn't know 
about.  Closing this now.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-09 14:18

Message:
Logged In: NO 

This problem was fixed in Python-20020309 for my box.  I am
running Debian Gnu Linux 2.2.19 ppc on a New World iMac.
The default configure did not add -lieee to LIBS and that
python did not give the underflow errors that python2.2
did.

----------------------------------------------------------------------

Comment By: Christopher Lee (clee)
Date: 2002-03-09 12:31

Message:
Logged In: YES 
user_id=1426

Tim Peter's fix in CVS looks good on my machine:

redhat 7.2, linux kernel 2.4.17, glibc 2.2.4-19.3, gcc 2.96-98

Python 2.3a0 (check out from cvs Sat Mar  9 11:26:31 CST 2002)

 ./python test_ieee.py 
x = 1e200
y = 1/x
check math.pow(x, 2): got math range error -OK
check math.pow(y, 2): got zero-OK
check pow(x, 2) got (34, 'Numerical result out of range') -OK
check pow(y, 2) got zero-OK
check x**2 got (34, 'Numerical result out of range') -OK
check y**2 got zero-OK

when running the following code
import math
x = 1e200
y = 1/x
print "x = 1e200"
print "y = 1/x"

try:
    print "check math.pow(x, 2):", 
    math.pow(x, 2)  # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"


print "check math.pow(y, 2):", 
a=math.pow(y, 2)  # expect 0.
if a == 0.0:
    print "got zero-OK"
else:
    print "didn't get zero-FAIL"

try:
    print "check pow(x, 2)", 
    pow(x, 2)       # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check pow(y, 2)", 
a=pow(y, 2)       # expect 0.
if a == 0.0: print "got zero-OK"

try:
    print "check x**2",
    x**2            # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check y**2",
a=y**2            # expect 0.
if a==0.0:
    print "got zero-OK"





----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-09 10:24

Message:
Logged In: YES 
user_id=33168

RedHat 7.2, glibc-2.2.4-13

Before patch:
   w/o -lieee    w/-lieee
   FAILED        Passed

After patch:
   w/o -lieee    w/-lieee
   Passed        Passed

Works for me.
I also attached a modified script to what Tim posted on
python-dev which prints out if there is a problem.  Silence
is golden.

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2002-03-09 02:52

Message:
Logged In: YES 
user_id=190903

Red Hat Linux release 6.2, with some updates.
Running on an Alpha box.  No changes to -ieee flag
(both compiled without -ieee)

Compared stock Python 2.2 vs. most recent CVS.

Using Python 2.2:
pow(1e-200, 2) and 1e-200**2 give OverflowError

Current CVS:
pow(1e-200, 2) and 1e-200**2 give 0.0


----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-09 01:18

Message:
Logged In: YES 
user_id=76089

Python 2.2 on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give OverflowError
Current CVS Python on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give 0.0

I did not do anything with -lieee, just ./configure && make


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-09 00:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 00:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 22:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 19:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 19:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:20:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:20:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-429031 ] Text widget, bindtags and Tabs
Message-ID: <E16js1C-0001Ec-00@usw-sf-web3.sourceforge.net>

Bugs item #429031, was opened at 2001-05-31 09:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429031&group_id=5470

>Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alankar Misra (alankar)
Assigned to: Nobody/Anonymous (nobody)
Summary: Text widget, bindtags and Tabs

Initial Comment:
While using a Text widget, if I were to swap the first 
two default elements in the bindtags tuple 
(text._w,'Text') swapped to ('Text',text._w), ie the 
Text widget now recieves all the key events before a 
bound event handler does, the Text widget will eat up 
Tabs and the event handler will never be called. The 
attached py file demonstrates just that. It works with 
all the other keys, why not tabs?


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 19:20

Message:
Logged In: YES 
user_id=44345

setting the category.  seems sort of like a Tk issue to
me, not a Tkinter issue.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=429031&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:27:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:27:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-525481 ] long double causes compiler warnings
Message-ID: <E16js72-0005yu-00@usw-sf-web1.sourceforge.net>

Bugs item #525481, was opened at 2002-03-04 07:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
>Assigned to: Nobody/Anonymous (nobody)
Summary: long double causes compiler warnings

Initial Comment:
The 2.44 changes to objimpl.h, especially the "long double" bit, causes numerous warnings on Mac OS X (and possible on other gcc-based platforms). Maybe the suggestion of adding the -Wno-long-double option should be taken, maybe something else should be done (adding a config-based define for the type with the biggest alignment requirement?).

/Users/jack/src/python/Include/objimpl.h:275: warning: use of `long double' type; its size may change in a future release
/Users/jack/src/python/Include/objimpl.h:275: warning: (Long double usage is reported only once for each file.
/Users/jack/src/python/Include/objimpl.h:275: warning: To disable this warning, use -Wno-long-double.)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:27

Message:
Logged In: YES 
user_id=31435

Well, since 2.44 consisted entirely of adding the 5-
character string "long " to objimpl.h, I think we can be 
sure that was the cause <wink>.

But "long double" a standard C type, and I don't think a 
compiler has any business warning about using a standard C 
type in a vanilla way.  Someone who has access to this 
compiler should fix it, if they care enough to do so.  
That's not me on either count, so I'm unassigning this 
report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525481&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:27:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:27:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-432570 ] overlapping groups ?
Message-ID: <E16js7J-0001IH-00@usw-sf-web3.sourceforge.net>

Bugs item #432570, was opened at 2001-06-12 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432570&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: overlapping groups ?

Initial Comment:
with perl:

$tag = '<abc xyz="def/ghi">';
$tag =~ /<(\/|\?)?(.*?)(\/|\?)?>/;
print "1=$1\n";
print "2=$2\n";
print "3=$3\n";

you get:

1=
2=abc xyz="def/ghi"
3=

with python
(ActivePython 2.1, build 210 ActiveState
based on Python 2.1 (#15, Apr 19 2001, 10:28:27)
[MSC 32 bit (Intel)] on win32):

import re
p = re.compile("<(/|\?)?(.*?)(/|\?)?>")
tag = '<abc xyz="def/ghi"><test>'
m = p.search(tag)
print '1='+str(m.group(1))
print '2='+str(m.group(2))
print '3='+str(m.group(3))

you get:

1=None
2=abc xyz="def/ghi"
3=abc xyz="def/

uups ...

cu, jk.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 19:27

Message:
Logged In: YES 
user_id=44345

I can't reproduce this using the current CVS (2.3a0) on
Linux.  Unless there is an actual Windows-related issue
here, I think this should be marked "fixed" and then
closed.  -skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432570&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:41:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:41:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-439992 ] [win32] KeyboardInterrupt Not Caught
Message-ID: <E16jsKu-00067D-00@usw-sf-web1.sourceforge.net>

Bugs item #439992, was opened at 2001-07-10 04: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

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 19:41

Message:
Logged In: YES 
user_id=44345

just a note to remind folks that GvR suggested closing
this as "won't fix" a few months ago.  Seems like it's
still the correct course unless MS has changed Windows
dramtically in the intervening interval. -skip


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-12 00:08

Message:
Logged In: YES 
user_id=31435

Umm, I have no idea whether it can be fixed.  Who was this 
assigned to?  Assigning to MarkH in case he has an idea.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 23:34

Message:
Logged In: YES 
user_id=6380

Shall we close this as Won't Fix? Is there a point in
keeping it open while we know we can't fix it?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-08-07 10: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 08: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  Sun Mar 10 01:44:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:44:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-443866 ] Evaluating func_code causing core dump
Message-ID: <E16jsO4-0002QP-00@usw-sf-web2.sourceforge.net>

Bugs item #443866, was opened at 2001-07-23 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: Later
Priority: 3
Submitted By: Jonathan Hogg (jhogg)
Assigned to: Jeremy Hylton (jhylton)
Summary: Evaluating func_code causing core dump

Initial Comment:
Python 2.2a1 (#1, Jul 19 2001, 18:18:51)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on 
linux2

The intepreter dies hard if you directly evaluate the 
func_code of a function that has a closure. E.g.:

-----
def func1():
    return lambda: 4 + y

f = func1()
print "Ugly test 1:", eval( f.func_code, {'y': 38} )


def func2(x):
    return lambda: x + y

f = func2(4)
print "Ugly test 2:", eval( f.func_code, {'y': 38} )
-----

The second eval will cause a core dump on UNIX. The 
offending code is in PyEval_EvalCodeEx() of ceval.c 
line 2466. This loop attempts to match free vars 
against the closure, but the closure is NULL if the 
function is called with eval.

I know this is very broken usage of the interpreter, 
but it should die more cleanly than a core dump ;-)

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 19:44

Message:
Logged In: YES 
user_id=44345

just a reminder that this appears to be fixed -skip


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 23:29

Message:
Logged In: YES 
user_id=6380

Jeremy, since you claimed this to be fixed, is there a
reason to keep this bug report open? If you want a feature,
please open a (new, please!) feature request.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-30 16:53

Message:
Logged In: YES 
user_id=31392

It might be useful to extend eval() with a means to specify
bindings from free variables.  It's not at all clear how to
do this under the current implementation, which refers to
free variables using integer indexes assigned at compile
time.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-30 16:51

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.219 of bltinmodule.c


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-24 17:35

Message:
Logged In: YES 
user_id=31435

Assigned to Jeremy in the hopes this will speed his return 
to us <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=443866&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:47:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:47:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-512433 ] Quote handling in os.system & os.popen
Message-ID: <E16jsQP-0002Rz-00@usw-sf-web2.sourceforge.net>

Bugs item #512433, was opened at 2002-02-03 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512433&group_id=5470

Category: Windows
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jimmy Retzlaff (jretz)
Assigned to: Tim Peters (tim_one)
Summary: Quote handling in os.system & os.popen

Initial Comment:
On Python 2.2 under Windows XP:

    os.system('"notepad" "test.py"')

does not work as expected. It appears that os.system 
attempts to run:

    notepad" "test.py

A workaround is to use:

    os.system('""notepad" "test.py""')

Both of the following work as expected:

    os.system('notepad "test.py"')
    os.system('"notepad" test.py')

os.popen exhibits the same behaviour. In naive 
testing, the following hack seems to make things 
better:

    os_system = os.system
    os.system = lambda command: os_system('"%s"' % 
command)

This may suggest a potential fix in the C code - or 
it may simply offend the sensibilities of those more 
knowledgeable than me. :)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:47

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing as "Won't Fix".  os.system() and os.popen
() are barely usable on Windows, and it's going to remain 
that way until Python grows its own command shell.  Before 
that, it's at the mercy of what the MS shells happen to 
do.  In the case of XP's cmd.exe, you're a victim of 
documented (by MS) behavior:  see the /C and /K options to 
cmd.exe:

"""
If /C or /K is specified, then the remainder of the command 
line after the switch is processed as a command line, where 
the following logic is used to process quote (") 
characters: 

    1. If all of the following conditions are met, then 
quote characters on the command line are preserved: 

        - no /S switch 
        - exactly two quote characters 
        - no special characters between the two quote 
characters, where special is one of: &<>()@^| 
        - there are one or more whitespace characters 
between the two quote characters 
        - the string between the two quote characters is 
the name of an executable file. 

    2. Otherwise, old behavior is to see if the first 
character is a quote character and if so, strip the leading 
character and remove the last quote character on the 
command line, preserving any text after the last quote 
character.
"""

You're a victim of clause #2 there.  The MS shells aren't 
consistent about these rules, so there's nothing Python can 
do to try to out-guess them, short of heroic efforts.  For 
example, if we took your suggestion, things that work fine 
today under Win98's command.com would suddenly break (W98 
does *not* strip the new quotes you're adding, so "Bad 
command or file name" is the usual result).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512433&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:50:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:50:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E16jsTu-0006Cl-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: 3rd Party
Status: Open
Resolution: Wont Fix
Priority: 3
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 00:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 21:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 15:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 12:47

Message:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 10:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13:25

Message:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 03:37

Message:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 01:53:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 17:53:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-448951 ] Bug in re group handling
Message-ID: <E16jsWM-0001XX-00@usw-sf-web3.sourceforge.net>

Bugs item #448951, was opened at 2001-08-07 19: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: Skip Montanaro (montanaro)
Date: 2002-03-09 19:53

Message:
Logged In: YES 
user_id=44345

This looks like another item that works in current CVS.
I get "None" for group(1) in the 0# case. -skip


----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2001-10-04 23:39

Message:
Logged In: YES 
user_id=65253

I posted a fix as patch #468169 since I don't seem to have
access to add it here.


----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2001-08-30 11: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  Sun Mar 10 02:09:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 09 Mar 2002 18:09:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-527139 ] random.gammavariate hosed
Message-ID: <E16jslo-0002ff-00@usw-sf-web2.sourceforge.net>

Bugs item #527139, was opened at 2002-03-08 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: random.gammavariate hosed

Initial Comment:
Report from c.l.py; something is certainly wrong here, 
but will take some digging to figure out whether docs 
or code:

"""
From: Weet Vanniks
Sent: Thursday, March 07, 2002 11:14 AM
To: python-list@python.org
Subject: Bug in the standard module random ?


Hi,

The gammavariate function of the standard module is 
documented as taking two parameters, the first one 
alpha is required to be > -1 and the second beta is 
required to be >0.  However, examining the 
implementation, it seems that the requirement for 
alpha is to be >0.

In spite of this, I still have a problem since I 
called the gammavariate function with a parameter 
alpha equal to 0.2 and it fails logically on the 
following line:

ainv=_sqrt(2.0 * alpha - 1.0)

Apparently, the implementation requires alpha to be > 
0.5.  Am i missing something or is it a bug?
"""

----------------------------------------------------------------------

Comment By: John Machin (sjmachin)
Date: 2002-03-10 13:09

Message:
Logged In: YES 
user_id=480138

Edited & revised version of my posts on c.l.py:

=== Point 1 =================
There is a doc problem. Some definitions of the gamma 
distribution define it (a) such that alpha > -1 and has the 
exponential distribution as a special case when alpha == 0; 
others take the tack (b) that the lower bound is zero and 
the exponential distribution is when alpha == 1.

Option (b) seems to be the most popular recently.
Example of (a): my very old probability textbook.
Example of (b):
http://www.nag.com/numeric/cl/manual/pdf/G05/g05ffc_cl05.pdf

Here we have the doc taking option (a) and the 
implementation taking
option (b).

N.B. the following is VERY relevant:
http://mail.python.org/pipermail/python-dev/2001-
January/012181.html

=== Point 2 =============
gammavariate() calls stdgamma() with arguments that include 
ainv, bbb, and ccc. stdgamma() uses those arguments only if 
alpha > 1.0. As the OP found, ainv is off the planet for 
alpha < 0.5.

stdgamma() is called (inside random.py) only once, from 
gammavariate()

The module exposes both gammavariate() and stdgamma() --- 
stdgamma() with those three extra args seems useless to me. 
It should not be an exposed function IMO.

=== Point 3 ========

The documentation says there is a gamma() but doesn't 
mention gammavariate() and stdgamma(). The exposed function 
should be called "gammavariate" (a) for consistency with 
other functions (b) to avoid the perceived need to explain 
that this "gamma" is not the gamma function!!!

[post-posting points]

=== Point 4 ==== 
Serendipitous coincidence: http://www.jstatsoft.org/v03/i03/

=== Point 5 ====

The algorithm that Python uses starts falling apart from 
underflow for small alpha. So does the algorithm in GSL 
(GNU Scientific Library). So does the algorithm in the 
Monty Python paper. The problem in all of them is that they 
do pow(random(), 1.0 / alpha) or exp(log(random) / alpha) 
or suchlike. For alpha == 0.00001 (say), the result is 
vanishingly small and most generated variates are == 0.0.  
Note that the Monty Python paper says "the rare but 
difficult case alpha < 1". Given the bug we currently have 
with alpha < 0.5, it would appear to be even rarer than 
using floats as dict keys :-) -- as we don't purport to be 
NAG or even GSL, I propose we do no more about this than a 
one-line warning in the doc. Perhaps the whole random 
module needs a "caveat emptor" up the front.

=== Point 6 ====
I shall prepare a patch for random.py and upload it real 
soon now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527139&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 08:20:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 00:20:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-527816 ] (1).__nonzero__() dumps a core
Message-ID: <E16jyZb-0005Ey-00@usw-sf-web3.sourceforge.net>

Bugs item #527816, was opened at 2002-03-09 08:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Cesar Douady (douady)
Assigned to: Nobody/Anonymous (nobody)
Summary: (1).__nonzero__() dumps a core

Initial Comment:
Essentially, all is said.
This is running Pyhton 2.2 on Linux.

>From a rapid analysis, this comes from  a
the slot nb_nonzero of tp_as_number which returns an
integer being called from a wrapper object which
expects a function returning a PyObject* .

----------------------------------------------------------------------

Comment By: Burton Radons (loth)
Date: 2002-03-10 00:20

Message:
Logged In: YES 
user_id=2441

Good spot, and you're right about the source.  I've
submitted Patch #528038 to address this.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-09 08:13

Message:
Logged In: YES 
user_id=6656

Oops!  Good spot.  Raised priority.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 09:03:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 01:03:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16jzEt-0001pf-00@usw-sf-web1.sourceforge.net>

Bugs item #513572, was opened at 2002-02-05 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
>Assigned to: Nobody/Anonymous (nobody)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 10:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 03:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2002-02-11 03:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 13:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 17:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 09:10:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 01:10:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-528020 ] bug in Python2.2 in the nested scoping
Message-ID: <E16jzLM-0006kO-00@usw-sf-web2.sourceforge.net>

Bugs item #528020, was opened at 2002-03-10 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
>Assigned to: Jeremy Hylton (jhylton)
Summary: bug in Python2.2 in the nested scoping

Initial Comment:
Hello!
  There appears to be a bug in Python2.2 in the nested 
scoping.
Example:

"""
#the definition:
def a():
  x = 0
  i = lambda: eval('x')
  return i()

#the return of the above (on several machines, 
versions & systems):
>>> a()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in a
  File "<stdin>", line 3, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined
"""

and if I may, I have a remark in relation to the 
bove, there appear to be (in this particular case) an 
inconsistence between the lambda locals and globals,
as I understand, in the current state of development
the globals contain a 'unified' namespace with all the 
variables 'above' the nested block, but that does not 
appear to be the case! in the example above the lambda 
has no locals (as expected), and its globals DO NOT!! 
contain the namespace of the function 'a'..
I for one, can not understand this behaveur. 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:10

Message:
Logged In: YES 
user_id=31435

Sorry, I don't see any bugs here.  Your understanding of 
globals in Python is way too elaborate -- the globals 
belong to the module level, and the only thing a nested 
scope can do to a global is mask/hide one by introducing a 
local of the same name.  There's no such thing as 
a "unified namespace" in Python.

I suggest you study the "4.1 Code blocks, execution frames, 
and namespaces" section of the Reference Manual, ask 
questions if needed on comp.lang.python, then come back 
here if you still think there's a bug.

Assigning to Jeremy in anticipation <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 09:19:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 01:19:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16jzUO-000206-00@usw-sf-web1.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 08:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:19

Message:
Logged In: YES 
user_id=31435

If would help a lot if someone produced a small, self-
contained test case that reproduced the problem.  The usual 
outcome of *trying* to is the discovery that popen() on 
Windows hangs "for no identifiable reason at all".  
Example:  there's a test_popen2.py in the std Python test 
suite.  It hangs about 1 time in 200 when I run it on 
Win98SE.  There's no identifiable cause; it just hangs 
sometimes, and when it does it's always hung in the bowels 
of MS's code.  There are no races in the Python code 
driving it.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:54

Message:
Logged In: YES 
user_id=68151

os.read() doesn't block.
I'd expect you have to 
call os.read in a loop. 


i,o,e=os.popen3("../../python 
errXX.py")
print os.read(o.fileno(),10000), 
os.read(e.fileno(),10000)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 13:22

Message:
Logged In: YES 
user_id=31435

Chris, which version of Windows are you talking about?  You 
identified W2K for Thomas Guettler, but didn't say which 
version you were using.  The popen implementations are 
radically different across Windows flavors, so knowing 
which one you're using is important.

Alas, "important" doesn't necessarily imply helpful 
<wink>.  Historically, popen-on-Windows bugs don't get 
fixed, because they hit a brick wall after blame gets 
traced to MS internals.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-09 13:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 13:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 09:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 14:27:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 06:27:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-527816 ] (1).__nonzero__() dumps a core
Message-ID: <E16k4I7-0004PW-00@usw-sf-web3.sourceforge.net>

Bugs item #527816, was opened at 2002-03-09 11:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Cesar Douady (douady)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: (1).__nonzero__() dumps a core

Initial Comment:
Essentially, all is said.
This is running Pyhton 2.2 on Linux.

>From a rapid analysis, this comes from  a
the slot nb_nonzero of tp_as_number which returns an
integer being called from a wrapper object which
expects a function returning a PyObject* .

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-10 09:27

Message:
Logged In: YES 
user_id=6380

Fixed in CVS.  Thanks!

----------------------------------------------------------------------

Comment By: Burton Radons (loth)
Date: 2002-03-10 03:20

Message:
Logged In: YES 
user_id=2441

Good spot, and you're right about the source.  I've
submitted Patch #528038 to address this.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-09 11:13

Message:
Logged In: YES 
user_id=6656

Oops!  Good spot.  Raised priority.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527816&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 14:36:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 06:36:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-459464 ] Math_test overflowerror on sparc64 linux
Message-ID: <E16k4Qn-00077F-00@usw-sf-web1.sourceforge.net>

Bugs item #459464, was opened at 2001-09-07 11:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470

Category: Extension Modules
Group: 3rd Party
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Martin v. Löwis (loewis)
Summary: Math_test overflowerror on sparc64 linux

Initial Comment:
Traceback(most recent call last):
testit('asin(-1)',math.asin(-1),-math.pi/2)
OverflowError: math range error

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-10 15:36

Message:
Logged In: YES 
user_id=21627

I cannot reproduce the problem with 2.2, so closing it again.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 02:32

Message:
Logged In: YES 
user_id=31435

Reassigning to Martin since he reopened this -- there's no 
more usable info here now than before.  If you care, go 
back to the start and answer the questions you and I both 
asked the OP (which remain unanswered).  Else I suggest 
closing it again.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-11 08:33

Message:
Logged In: YES 
user_id=21627

One further piece of information: If mathmodule is linked
into the interpreter, the test passes fine.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-11 08:31

Message:
Logged In: YES 
user_id=21627

Re-opening, this can be reproduced on the SF compile farm.
It is not a sparc64 issue, since this is all 32-bit userland.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-17 21:45

Message:
Logged In: YES 
user_id=31435

Closed for lack of followup; presumed to be a platform libm 
bug.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-14 05:20

Message:
Logged In: YES 
user_id=31435

If there isn't any followup on this by the weekend, I'm 
going to close it.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-09-10 17:43

Message:
Logged In: YES 
user_id=21627

Also, what compiler did you use? gcc on sparc64 (all
versions) has known floating point bugs, so that it is not
capable of building reliable 64-bit binaries, see
gcc.gnu.org for details.
The test works fine for me on Solaris 8, with the Sun WS6U1
compiler.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-07 11:58

Message:
Logged In: YES 
user_id=31435

Needs more info.

Which version of Python?

If you try asin(-1) in a C program on this box, does the 
math library set errno?  If so, it's a platform C bug, and 
you should report it to your C vendor (Python doesn't do 
anything with asin except call the platform asin, and if 
that sets errno to ERANGE, Python raises OverflowError; asin
(-1) should not set errno to ERANGE, but if it does there's 
nothing Python can do about that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459464&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 16:00:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 08:00:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-527855 ] ftplib error (exception) handling bug
Message-ID: <E16k5kF-00071w-00@usw-sf-web3.sourceforge.net>

Bugs item #527855, was opened at 2002-03-09 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527855&group_id=5470

Category: Extension Modules
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Gonnerman (solomoriah)
Assigned to: Nobody/Anonymous (nobody)
Summary: ftplib error (exception) handling bug

Initial Comment:
On line 445 of ftplib.py we find:

    if msg[:3] != '500':

msg isn't a string, it's an error_perm instance.  
Change the line to this:

    if str(msg)[:3] != '500':

(with correct indentation obviously) and the problem 
is solved.

I don't know if this is in 2.2 or not as I haven't 
installed it yet.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-10 17:00

Message:
Logged In: YES 
user_id=21627

Thanks for the report; fixed in ftplib.py 1.66.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527855&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 17:27:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 09:27:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16k769-0005OB-00@usw-sf-web2.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 17:27

Message:
Logged In: YES 
user_id=68151

I don't know about Win98*. But the example 
given did hang in Linux also.

The 
problem as posted here seems to be caused 
by fp.read() blocking until the spawned 
program exits. Using os.read() on Linux 
avoids this problem. I'll give it a try on 
Win2k and XP today. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 09:19

Message:
Logged In: YES 
user_id=31435

If would help a lot if someone produced a small, self-
contained test case that reproduced the problem.  The usual 
outcome of *trying* to is the discovery that popen() on 
Windows hangs "for no identifiable reason at all".  
Example:  there's a test_popen2.py in the std Python test 
suite.  It hangs about 1 time in 200 when I run it on 
Win98SE.  There's no identifiable cause; it just hangs 
sometimes, and when it does it's always hung in the bowels 
of MS's code.  There are no races in the Python code 
driving it.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 23:54

Message:
Logged In: YES 
user_id=68151

os.read() doesn't block.
I'd expect you have to 
call os.read in a loop. 


i,o,e=os.popen3("../../python 
errXX.py")
print os.read(o.fileno(),10000), 
os.read(e.fileno(),10000)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 18:22

Message:
Logged In: YES 
user_id=31435

Chris, which version of Windows are you talking about?  You 
identified W2K for Thomas Guettler, but didn't say which 
version you were using.  The popen implementations are 
radically different across Windows flavors, so knowing 
which one you're using is important.

Alas, "important" doesn't necessarily imply helpful 
<wink>.  Historically, popen-on-Windows bugs don't get 
fixed, because they hit a brick wall after blame gets 
traced to MS internals.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-09 18:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 14:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 20:42:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 12:42:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-526726 ] Possible bug in import.c (2.1.2)
Message-ID: <E16kA8u-0007Vw-00@usw-sf-web2.sourceforge.net>

Bugs item #526726, was opened at 2002-03-07 01:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526726&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jeff Sasmor (jeffsasmor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Possible bug in import.c (2.1.2)

Initial Comment:
Referencing the source distribution; file 
Python/import.c:

lines 1881 through 1884 read:

if (parent == NULL) {
 PyErr_Format(PyExc_ImportError,
 "reload(): parent %.200s not in sys.modules",name); 

It might be more correct to subsitute the variable
parentname here (rather than 'name') since it is
the parentname'd module that wasn't found.  Perhaps
there was some other intent in mind.....

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-03-10 21:42

Message:
Logged In: YES 
user_id=92689

No:
1) I read the error string as "the parent of 'name' is not 
in sys.modules", which is indeed what's intended.
2) parentname is a PyObject* and name is a char*
(I assume it is correct to close this bug)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526726&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 20:50:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 12:50:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-515830 ] macostools.mkalias doesnt work for folde
Message-ID: <E16kAHO-0006Ga-00@usw-sf-web3.sourceforge.net>

Bugs item #515830, was opened at 2002-02-11 11:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515830&group_id=5470

Category: Macintosh
Group: None
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: macostools.mkalias doesnt work for folde

Initial Comment:
macostools.mkalias() fails if the source is a folder in stead of a file.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-10 20:28

Message:
Logged In: YES 
user_id=92689

Fixed in macostools.py rev. 1.14.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515830&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 23:17:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 15:17:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-528020 ] bug in Python2.2 in the nested scoping
Message-ID: <E16kCYv-0000kN-00@usw-sf-web2.sourceforge.net>

Bugs item #528020, was opened at 2002-03-10 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
>Assigned to: Nobody/Anonymous (nobody)
Summary: bug in Python2.2 in the nested scoping

Initial Comment:
Hello!
  There appears to be a bug in Python2.2 in the nested 
scoping.
Example:

"""
#the definition:
def a():
  x = 0
  i = lambda: eval('x')
  return i()

#the return of the above (on several machines, 
versions & systems):
>>> a()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in a
  File "<stdin>", line 3, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined
"""

and if I may, I have a remark in relation to the 
bove, there appear to be (in this particular case) an 
inconsistence between the lambda locals and globals,
as I understand, in the current state of development
the globals contain a 'unified' namespace with all the 
variables 'above' the nested block, but that does not 
appear to be the case! in the example above the lambda 
has no locals (as expected), and its globals DO NOT!! 
contain the namespace of the function 'a'..
I for one, can not understand this behaveur. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 12:10

Message:
Logged In: YES 
user_id=31435

Sorry, I don't see any bugs here.  Your understanding of 
globals in Python is way too elaborate -- the globals 
belong to the module level, and the only thing a nested 
scope can do to a global is mask/hide one by introducing a 
local of the same name.  There's no such thing as 
a "unified namespace" in Python.

I suggest you study the "4.1 Code blocks, execution frames, 
and namespaces" section of the Reference Manual, ask 
questions if needed on comp.lang.python, then come back 
here if you still think there's a bug.

Assigning to Jeremy in anticipation <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 23:17:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 15:17:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-528020 ] bug in Python2.2 in the nested scoping
Message-ID: <E16kCZa-0000kk-00@usw-sf-web2.sourceforge.net>

Bugs item #528020, was opened at 2002-03-10 08:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
>Assigned to: Jeremy Hylton (jhylton)
Summary: bug in Python2.2 in the nested scoping

Initial Comment:
Hello!
  There appears to be a bug in Python2.2 in the nested 
scoping.
Example:

"""
#the definition:
def a():
  x = 0
  i = lambda: eval('x')
  return i()

#the return of the above (on several machines, 
versions & systems):
>>> a()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in a
  File "<stdin>", line 3, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined
"""

and if I may, I have a remark in relation to the 
bove, there appear to be (in this particular case) an 
inconsistence between the lambda locals and globals,
as I understand, in the current state of development
the globals contain a 'unified' namespace with all the 
variables 'above' the nested block, but that does not 
appear to be the case! in the example above the lambda 
has no locals (as expected), and its globals DO NOT!! 
contain the namespace of the function 'a'..
I for one, can not understand this behaveur. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 12:10

Message:
Logged In: YES 
user_id=31435

Sorry, I don't see any bugs here.  Your understanding of 
globals in Python is way too elaborate -- the globals 
belong to the module level, and the only thing a nested 
scope can do to a global is mask/hide one by introducing a 
local of the same name.  There's no such thing as 
a "unified namespace" in Python.

I suggest you study the "4.1 Code blocks, execution frames, 
and namespaces" section of the Reference Manual, ask 
questions if needed on comp.lang.python, then come back 
here if you still think there's a bug.

Assigning to Jeremy in anticipation <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470


From noreply@sourceforge.net  Sun Mar 10 23:38:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 15:38:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16kCtD-0002I5-00@usw-sf-web3.sourceforge.net>

Bugs item #528274, was opened at 2002-03-11 02:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 00:34:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 16:34:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16kDlt-0001Wv-00@usw-sf-web2.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 07:16:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 10 Mar 2002 23:16:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16kK2d-0003Oo-00@usw-sf-web3.sourceforge.net>

Bugs item #528274, was opened at 2002-03-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-11 08:16

Message:
Logged In: YES 
user_id=21627

It is not clear from your report what bug you are reporting.
Please structure a bug report in the following way:
- what did you do (you've explained this, providing a script)
- what happened (you've also reported that)
- what did you expect to happen instead (this is hard to
find in your report)
- why do you believe that the bug is in Python and not in
your understanding of the language (optional)

Analizing what you got as output: in your report:

- NameError in nested_1: This is not a bug. You declare a as
a global variable, yet there is no global variable with that
name, hence the NameError.

- NameError in nested_2: This appears to be a bug. See

http://www.python.org/doc/current/ref/dynamic-features.html

  for a discussion of nested scopes and dynamic features. In
your example, you reference the variable 'a' before using it
in eval(), so it should be available to eval(). Notice,
however, that removing the variable access from nested_2
also makes it unavailable to eval().

In the script, you argue that the variable should be either
global or local. This is not true in Python 2.2, see

http://www.python.org/doc/current/ref/nested-scopes.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 10:10:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 02:10:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-525548 ] __add__ returning NotImplemented broken
Message-ID: <E16kMlI-0002Nr-00@usw-sf-web1.sourceforge.net>

Bugs item #525548, was opened at 2002-03-04 15:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525548&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: __add__ returning NotImplemented broken

Initial Comment:
A new-style class that returns NotImplemented
from its __add__ method misbehaves; this should
raise a TypeError but in fact the NotImplemented
value is kept as the return value.

This only seems to be a problem with __add__;
I bet it's because the code goes through a path
intended for sequence concatenation.

Old-style classes do the right thing.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-11 10:10

Message:
Logged In: YES 
user_id=6656

Isn't this a dup of 

[ 516727 ] MyInt(2)+"3" -> NotImplemented

? (now fixed in CVS)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525548&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 10:56:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 02:56:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-528440 ] asyncore.poll bug
Message-ID: <E16kNTv-0007o6-00@usw-sf-web2.sourceforge.net>

Bugs item #528440, was opened at 2002-03-11 10:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528440&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Kjetil Jacobsen (kjetilja)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.poll bug

Initial Comment:
the asyncore.poll function (which uses select()) has
different handling of EINTR than asyncore.poll3 (which
uses poll()).

asyncore.poll3 resets the read-set when EINTR occurs,
but this is not done in asyncore.poll.

to be consistent with the behaviour of asyncore.poll3,
asyncore.poll should also reset the read/write sets
upon EINTR.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528440&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 13:14:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 05:14:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-525548 ] __add__ returning NotImplemented broken
Message-ID: <E16kPdY-0000vg-00@usw-sf-web2.sourceforge.net>

Bugs item #525548, was opened at 2002-03-04 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525548&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Duplicate
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: __add__ returning NotImplemented broken

Initial Comment:
A new-style class that returns NotImplemented
from its __add__ method misbehaves; this should
raise a TypeError but in fact the NotImplemented
value is kept as the return value.

This only seems to be a problem with __add__;
I bet it's because the code goes through a path
intended for sequence concatenation.

Old-style classes do the right thing.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-11 08:14

Message:
Logged In: YES 
user_id=6380

Yup. Closing.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-11 05:10

Message:
Logged In: YES 
user_id=6656

Isn't this a dup of 

[ 516727 ] MyInt(2)+"3" -> NotImplemented

? (now fixed in CVS)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525548&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 17:29:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 09:29:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-498607 ] PyObject_GetIter not documented
Message-ID: <E16kTcH-0004Ff-00@usw-sf-web3.sourceforge.net>

Bugs item #498607, was opened at 2002-01-02 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyObject_GetIter not documented

Initial Comment:
As far as I can tell, the PyObject_GetIter function is 
not mentioned in the C API documentation.  If I 
understand correctly, it should be listed somewhere on 
the "6.1 Object Protocol" page.

----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-03-11 08:29

Message:
Logged In: YES 
user_id=86307

I took a shot at documenting this myself.  Attached is a 
patch against ver. 1.8.6.1 of Doc/api/abstract.tex.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 19:02:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 11:02:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-498607 ] PyObject_GetIter not documented
Message-ID: <E16kV40-0003d8-00@usw-sf-web2.sourceforge.net>

Bugs item #498607, was opened at 2002-01-02 12:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyObject_GetIter not documented

Initial Comment:
As far as I can tell, the PyObject_GetIter function is 
not mentioned in the C API documentation.  If I 
understand correctly, it should be listed somewhere on 
the "6.1 Object Protocol" page.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-11 14:02

Message:
Logged In: YES 
user_id=3066

Accepted & checked in with minor changes as
Doc/api/abstract.tex revisions 1.10 and 1.8.6.2.
Thanks, Greg!

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-03-11 12:29

Message:
Logged In: YES 
user_id=86307

I took a shot at documenting this myself.  Attached is a 
patch against ver. 1.8.6.1 of Doc/api/abstract.tex.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498607&group_id=5470


From noreply@sourceforge.net  Mon Mar 11 19:39:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 11:39:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16kVdM-0007V8-00@usw-sf-web1.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: Nobody/Anonymous (nobody)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 02:31:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 11 Mar 2002 18:31:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E16kc4z-0003n3-00@usw-sf-web1.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
Group: 3rd Party
Status: Open
Resolution: Wont Fix
Priority: 3
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 18:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 16:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 15:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 15:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 14:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 15:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 01:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 10:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 13:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 18:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 12:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 09:47

Message:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 07:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 10:25

Message:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 00:37

Message:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 09:03:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 01:03:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-528879 ] segfaults with nl_langinfo
Message-ID: <E16kiBy-0007po-00@usw-sf-web1.sourceforge.net>

Bugs item #528879, was opened at 2002-03-12 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470

Category: Unicode
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Piefel (piefel)
Assigned to: M.-A. Lemburg (lemburg)
Summary: segfaults with nl_langinfo

Initial Comment:
import locale
locale.nl_langinfo(0x20032)

This crashes - no stack trace. Smaller constants work.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 10:02:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 02:02:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-528879 ] segfaults with nl_langinfo
Message-ID: <E16kj73-0008UN-00@usw-sf-web1.sourceforge.net>

Bugs item #528879, was opened at 2002-03-12 09:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470

>Category: Extension Modules
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 6
Submitted By: Michael Piefel (piefel)
>Assigned to: Martin v. Löwis (loewis)
Summary: segfaults with nl_langinfo

Initial Comment:
import locale
locale.nl_langinfo(0x20032)

This crashes - no stack trace. Smaller constants work.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-12 10:02

Message:
Logged In: YES 
user_id=6656

_localemodule.c has Martin's name at the top of it, so he
gets this.

This would seem to be a bug in some versions of glibc --
nl_langinfo is setting errno and returning NULL.  Fixed just
over two years ago in glibc CVS, but obviously still "out
there".  Worth working around?  Shouldn't be too hard.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 16:19:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 08:19:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-528990 ] bug? in PyImport_ImportModule under AIX
Message-ID: <E16kozh-0004BR-00@usw-sf-web1.sourceforge.net>

Bugs item #528990, was opened at 2002-03-12 17:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528990&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Fanny Wattez (wattez)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug? in PyImport_ImportModule under AIX

Initial Comment:
Here is a description of the problem we encounter.

platform : AIX 4.3.3
Python 2.2 

environment variables : 
----------------------------------------
 
PATH=/home/soft/ccm_gdc7/bin:/bin:/usr/sbin:/usr/etc:/u
sr/lpp/X11/bin:/usr/wf/bin:/usr/local/bin:/usr/local/ad
min/etc:/lbin:/usr/bin/etc:/usr/ucb:/home/users/wattez/
lbin:/sbin:.:/usr/bin/X11:/sbin:/home/users/wattez/lbin
/fvwm-
exec:/tools/versant/6.0.0/rs6000/bin:/tools/views402/st
udio/rs6000:/tools/sp1.3.4/bin:/tools/imagemagick5.4.2/
bin:/tools/python2.2.debug/bin
PYTHON_ROOT=/tools/python2.2.debug
PYTHONPATH=/tools/python2.2.debug/lib/python2.2:/tools/
python2.2.debug/lib/python2.2/lib-
tk:/tools/xmlproc0.70:/tools/doctemplate2.2.1:/tools/py
thon2.2.debug/lib/python2.2/plat-
aix4:/tools/python2.2.debug/lib/python2.2/lib-
dynload:/tools/python2.2.debug/lib/python2.2/site-
packages

test program :
-------------------

#include <iostream.h>
#include <Python.h>

int main(int i__argc,char* i__argv[])
{

        Py_Initialize();

        cout << endl << "CALL of PyImport_ImportModule 
with argument " << getenv("NAME_MODULE") << endl;

        PyObject * l__obj = PyImport_ImportModule
(getenv("NAME_MODULE"));

        if (l__obj == NULL)
          cout << "importation of module " << getenv
("NAME_MODULE") << " does not work well!" << endl;

        return 1;
}


We ran this test program for different values of 
$NAME_MODULE.

$NAME_MODULE     	|    does the test program 
work well?
----------------------------------------------------
base64                  |    KO (Segmentation fault) 
at the call of PyImport_ImportModule
os                 	|    OK
strop            	|    KO (Segmentation fault) 
at the call of PyImport_ImportModule
string           	|    KO (Segmentation fault) 
at the call of PyImport_ImportModule

What do we see with dbx (Python 2.2 is compiled in 
debug mode)?
-------------------------------------
The last instructions in the stack are : 

stropmodule.split_whitespace(s = "strop", len = 
806723600, maxsplit = 806727672), line 80 
in "stropmodule.c"
initstrop(), line 1221 in "stropmodule.c"
_PyImport_LoadDynamicModule(0x2ff1d2b0, 0x2ff1cdc0, 
0xf0004d40), line 53 in "importdl.c"

with 0x2ff1d2b0 = "strop"
        0x2ff1cdc0 
= "/tools/python2.2.debug/lib/python2.2/lib-
dynload/strop.so"

Could you help us understand the problem?

Note : under the interactive Python interpreter, we 
have no problems importing each of these modules. The 
test program only crashes under AIX 4.3.3 not under 
Windows 2000.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528990&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 19:52:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 11:52:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-517684 ] warnings.warn() misdocumented
Message-ID: <E16ksJx-0008TQ-00@usw-sf-web3.sourceforge.net>

Bugs item #517684, was opened at 2002-02-14 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517684&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: warnings.warn() misdocumented

Initial Comment:
warnings.warn() on
http://www.python.org/doc/current/lib/warning-functions.html
contains a sample function call.  The argument `level'
is not a valid keyword argument to warnings.warn(). 
The example should probably just be:

def deprecation(message):
    warnings.warn(message, DeprecationWarning, 2)


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 14:52

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libwarnings.tex revisions 1.7, 1.6.16.1,
and 1.5.4.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517684&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:19:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:19:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-528438 ] test_math should run test_exceptions
Message-ID: <E16ksjw-0000Ko-00@usw-sf-web3.sourceforge.net>

Bugs item #528438, was opened at 2002-03-11 05:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528438&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
>Assigned to: Michael Hudson (mwh)
Summary: test_math should run test_exceptions

Initial Comment:
Currently test_math runs test of overflow/underflow
behaviour only in verbose mode because it was such a
crapshoot as to whether it worked or not.

As it is hoped that the odds have been improved, it
should probably run it unconditionally (at least until
it turns out that in fact it still doesn't work
everywhere).

It should perhaps be expanded to include tests of **
behaviour (unless that's tested somewhere else).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-12 15:19

Message:
Logged In: YES 
user_id=31435

Back to you!  Python still doesn't promise anything here, 
and I've got no interest in wading thru reports from 100 
Platforms from Mars.  That's why these tests aren't run by 
default.  You can enable them if you like (and I agree it 
would be interesting), but unless someone in Python 
development is dead serious about supporting this stuff 
(I'm not and can't be), the platform-specific failures that 
pop up will just irritate all involved.

Ensuring that 1e-200**2 doesn't overflow would be a fine 
addition to the std runs-all-the-time test -- except you 
can't know whether 1e-200 is in range for the platform's 
notion of C double, or whether 1e-200**2 is out of range 
(although both are very likely today).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528438&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:25:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:25:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-513666 ] unicode() docs don't mention LookupError
Message-ID: <E16kspo-00070j-00@usw-sf-web1.sourceforge.net>

Bugs item #513666, was opened at 2002-02-06 03:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513666&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Gertzfield (che_fox)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: unicode() docs don't mention LookupError

Initial Comment:
The unicode() docs say:

"If errors is 'strict' (the default), a ValueError is
raised on errors..."

This is not true; ValueError is only raised on
conversion errors.  There are other exceptions that can
be raised:

Python 2.1.2 (#1, Jan 18 2002, 18:05:45) 
[GCC 2.95.4  (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.

>>> unicode("abc", "nonexistent codec")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding

Looking at src/Objects/unicodeobject.c, there are lots
of other exceptions that can be raised.  The
documentation should probably be clarified.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 15:25

Message:
Logged In: YES 
user_id=3066

Marc-Andre -- could you summarize all the exceptions that
can be raised and what they mean?  A simple list here would
be fine; I can move the information into LaTeX if you'd prefer.

Thanks!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-06 04:25

Message:
Logged In: YES 
user_id=38388

You are right in that there are many more exceptions which are possible (perhaps we ought to mention 
LookupError in the docs), ValueError will certainly be the most common, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513666&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:29:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:29:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-515751 ] Missing docs for module imputil
Message-ID: <E16kstT-00073N-00@usw-sf-web1.sourceforge.net>

Bugs item #515751, was opened at 2002-02-11 00:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 6
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Greg Stein (gstein)
Summary: Missing docs for module imputil

Initial Comment:
The summary says it all.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 15:29

Message:
Logged In: YES 
user_id=3066

Greg -- please write documentation for this module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515751&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:35:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:35:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-529050 ] ModuleType.__new__ crash
Message-ID: <E16kszT-00077y-00@usw-sf-web1.sourceforge.net>

Bugs item #529050, was opened at 2002-03-12 10:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529050&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Nobody/Anonymous (nobody)
Summary: ModuleType.__new__ crash

Initial Comment:
Submitted on behalf of Gustavo Cordova
<gcordova@hebmex.com>:

Hi all, sorry for posting to this list.

I found a (maybe?) new bug, which crashes the interpreter.
Just do this (is't repeatable):

>>> from types import *
>>> mod = ModuleType.__new__(ModuleType)
>>> mod

Upon trying to do a str(mod) to print it (I believe),
the VM crashes and burns.

I was searching for a way to construct a new module
from it's file's compiled bytecode (just read() the
"*.pyc" file),
so I thought maybe the ModuleType had some kind of
constructor
which could use the compiled byte code.

I don't have web access, so I couldn't post it as a bug
report in sourceforge.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-12 12:35

Message:
Logged In: NO 

I've got a fix. Will check in soon. --Guido


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529050&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:37:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:37:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-529050 ] ModuleType.__new__ crash
Message-ID: <E16kt1h-0002Wg-00@usw-sf-web2.sourceforge.net>

Bugs item #529050, was opened at 2002-03-12 13:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529050&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: ModuleType.__new__ crash

Initial Comment:
Submitted on behalf of Gustavo Cordova
<gcordova@hebmex.com>:

Hi all, sorry for posting to this list.

I found a (maybe?) new bug, which crashes the interpreter.
Just do this (is't repeatable):

>>> from types import *
>>> mod = ModuleType.__new__(ModuleType)
>>> mod

Upon trying to do a str(mod) to print it (I believe),
the VM crashes and burns.

I was searching for a way to construct a new module
from it's file's compiled bytecode (just read() the
"*.pyc" file),
so I thought maybe the ModuleType had some kind of
constructor
which could use the compiled byte code.

I don't have web access, so I couldn't post it as a bug
report in sourceforge.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-12 15:37

Message:
Logged In: YES 
user_id=6380

Fixed in CVS, moduleobject.c rev 2.41.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-12 15:35

Message:
Logged In: NO 

I've got a fix. Will check in soon. --Guido


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529050&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 20:37:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 12:37:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16kt1e-0000Z3-00@usw-sf-web3.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 21:35:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 13:35:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-529135 ] test_pyclbr: bad dependency for input
Message-ID: <E16ktvg-0003Fu-00@usw-sf-web2.sourceforge.net>

Bugs item #529135, was opened at 2002-03-12 16:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529135&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_pyclbr: bad dependency for input

Initial Comment:
Lib/test/test_pyclbr.py depends on the implementation
details of other module (httplib in particular) for
test data; it should not depend on that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529135&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 21:53:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 13:53:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-529146 ] ICGlue byte alignment issue
Message-ID: <E16kuCi-000863-00@usw-sf-web1.sourceforge.net>

Bugs item #529146, was opened at 2002-03-12 21:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: ICGlue byte alignment issue

Initial Comment:
When using IC to read the Internet Configuration data (from Internet Control Panel), the type and creator codes appear to be misaligned.

For example, with the JPG entry, I receive back:

"EGog" & "le  ", instead of the proper: "JPEG" &"ogle" entries.....



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 22:08:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 14:08:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-528879 ] segfaults with nl_langinfo
Message-ID: <E16kuRB-0008HO-00@usw-sf-web1.sourceforge.net>

Bugs item #528879, was opened at 2002-03-12 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Michael Piefel (piefel)
Assigned to: Martin v. Löwis (loewis)
Summary: segfaults with nl_langinfo

Initial Comment:
import locale
locale.nl_langinfo(0x20032)

This crashes - no stack trace. Smaller constants work.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-12 23:08

Message:
Logged In: YES 
user_id=21627

The problem is that glibc's nl_langinfo sometimes returns
int values, instead of char*. E.g. 0x20032 is
_NL_TIME_ERA_NUM_ENTRIES, which returns the number of eras.
Use of these constants is not supported, so _locale shall be
changed to verify the arguments to check it is a supported
argument.

Fixed in _localemodule.c 2.26.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-12 11:02

Message:
Logged In: YES 
user_id=6656

_localemodule.c has Martin's name at the top of it, so he
gets this.

This would seem to be a bug in some versions of glibc --
nl_langinfo is setting errno and returning NULL.  Fixed just
over two years ago in glibc CVS, but obviously still "out
there".  Worth working around?  Shouldn't be too hard.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528879&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 22:16:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 14:16:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app
Message-ID: <E16kuZL-0008Oe-00@usw-sf-web1.sourceforge.net>

Bugs item #505490, was opened at 2002-01-18 20:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Stefan Franke (sfranke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve I/O redirection to embedding app

Initial Comment:
When embedding Python into an existing application, you
usually do two things (among others):
1. Make Python use your own memory allocation
2. Redirect its I/O to the embedding app

While the former is very easy due to the excellent
pymem.h interface, the latter is quite painful, since
the interpreter uses stdin/out/err directly.

The common workaround I found on c.l.p is providing
your own file-like objects in an extension module and
assign them to sys.stdout/err within the interpreter.
This solution still has its problems (like getting
errors while import site.py)

I wish Python would encapsulate I/O in a similar way
than its malloc interface, and in some way I would
expect this from a language which is said to be 
designed for extending and embedding.

Unluckily I'm not able to this myself. I started my 
first embedding project a few days ago and still miss
the big picture about Python's C API.


----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-03-12 23:16

Message:
Logged In: YES 
user_id=92689

I also don't understand that Jack's talking about: 
assigning to stdout/stderr is not only the proper 
solution, it also *works*, even for C tracebacks. Non-
debugging C code that uses fprintf() instead of the 
official PySys_WriteStd[err|out]() APIs is broken.

I think this bug should be closed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 20:35

Message:
Logged In: YES 
user_id=21627

What do you mean with "you don't get tracebacks"? The
attached a.py prints the traceback into the redirected file
just fine (with 2.2, on Solaris 8).

Also, which other output do you have in mind?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-01-21 11:14

Message:
Logged In: YES 
user_id=45365

Assigning to sys.stdout and friends is only half a solution: you don't get tracebacks and any other output produced by the C code.

Unfortunately there is no platform-independent solution without getting rid of stdio completely.

Fortunately there are platform-dependent solutions for many platforms. MacPython has a lowlevel hook to do this, for instance. Depending on your stdio implementation you may be able to hook into stdio on a low level.

An alternative 90% solution is to do the sys.stdout assignment and add Python code to print your tracebacks and such. An example of such code can be found in  Idle (or IDE, or PythonWin, or any other windowing Python IDE).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-18 22:26

Message:
Logged In: YES 
user_id=21627

I don't think that assigning to sys.stdout etc. is a
work-around; it is the proper solution. If you worry about
site.py, you can set Py_NoSiteFlag (which may be a good idea
in an embedded interpreter, anyway); if you then still need
site.py, you can import it on your own.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 22:31:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 14:31:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16kuoI-00008u-00@usw-sf-web1.sourceforge.net>

Bugs item #528274, was opened at 2002-03-10 23:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
Status: Open
>Resolution: Wont Fix
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Nobody/Anonymous (nobody)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 22:31

Message:
Logged In: YES 
user_id=31392

I think the bug report is trying to say that the error in
the following code snippet is unexpected:

def f(x):
    a = x
    def g():
        return eval('a')
    return g

f(3)()

I'm not sure what the nested scopes appendix in the ref
manual says, but I don't see that this is a bug I care to
fix.  (If it's a bug at all.)  I don't believe the behavior
of eval() is defined with respect to free variables bound in
enclosing scopes.  In practical terms, the compiler has no
way to know that g() will try to access a in f().


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-11 07:16

Message:
Logged In: YES 
user_id=21627

It is not clear from your report what bug you are reporting.
Please structure a bug report in the following way:
- what did you do (you've explained this, providing a script)
- what happened (you've also reported that)
- what did you expect to happen instead (this is hard to
find in your report)
- why do you believe that the bug is in Python and not in
your understanding of the language (optional)

Analizing what you got as output: in your report:

- NameError in nested_1: This is not a bug. You declare a as
a global variable, yet there is no global variable with that
name, hence the NameError.

- NameError in nested_2: This appears to be a bug. See

http://www.python.org/doc/current/ref/dynamic-features.html

  for a discussion of nested scopes and dynamic features. In
your example, you reference the variable 'a' before using it
in eval(), so it should be available to eval(). Notice,
however, that removing the variable access from nested_2
also makes it unavailable to eval().

In the script, you argue that the variable should be either
global or local. This is not true in Python 2.2, see

http://www.python.org/doc/current/ref/nested-scopes.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 22:34:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 14:34:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16kur8-0000B6-00@usw-sf-web1.sourceforge.net>

Bugs item #528274, was opened at 2002-03-10 23:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 22:34

Message:
Logged In: YES 
user_id=31392

I just checked the language reference, Section A.3.2:

> The builtin functions eval() and input() can not access
free 
> variables unless the variables are also referenced by the 
> program text of he block that contains the call to eval()
> or input(). 


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 22:31

Message:
Logged In: YES 
user_id=31392

I think the bug report is trying to say that the error in
the following code snippet is unexpected:

def f(x):
    a = x
    def g():
        return eval('a')
    return g

f(3)()

I'm not sure what the nested scopes appendix in the ref
manual says, but I don't see that this is a bug I care to
fix.  (If it's a bug at all.)  I don't believe the behavior
of eval() is defined with respect to free variables bound in
enclosing scopes.  In practical terms, the compiler has no
way to know that g() will try to access a in f().


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-11 07:16

Message:
Logged In: YES 
user_id=21627

It is not clear from your report what bug you are reporting.
Please structure a bug report in the following way:
- what did you do (you've explained this, providing a script)
- what happened (you've also reported that)
- what did you expect to happen instead (this is hard to
find in your report)
- why do you believe that the bug is in Python and not in
your understanding of the language (optional)

Analizing what you got as output: in your report:

- NameError in nested_1: This is not a bug. You declare a as
a global variable, yet there is no global variable with that
name, hence the NameError.

- NameError in nested_2: This appears to be a bug. See

http://www.python.org/doc/current/ref/dynamic-features.html

  for a discussion of nested scopes and dynamic features. In
your example, you reference the variable 'a' before using it
in eval(), so it should be available to eval(). Notice,
however, that removing the variable access from nested_2
also makes it unavailable to eval().

In the script, you argue that the variable should be either
global or local. This is not true in Python 2.2, see

http://www.python.org/doc/current/ref/nested-scopes.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 22:52:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 14:52:05 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16kv7l-0004B6-00@usw-sf-web2.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-12 15:52

Message:
Logged In: YES 
user_id=85984

Take a look at the attached formataddr()
implementation.

Unlike dump_address_pair(), it takes care
to both double-quote the fullname only
when necessary, and also escape any
delimiting lexical tokens with a backslash.
This will hopefully produce a more RFC 2822 
compliant result.



----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 11:07

Message:
Logged In: YES 
user_id=85984

Yes, I think formataddr() is a much better
name.  dump_address_pair() is not very intuitive
at all IMO.




----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 10:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 15:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 15:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 08:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 23:04:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 15:04:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-528020 ] bug in Python2.2 in the nested scoping
Message-ID: <E16kvJg-0000XP-00@usw-sf-web1.sourceforge.net>

Bugs item #528020, was opened at 2002-03-10 05:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470

Category: None
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Jeremy Hylton (jhylton)
Summary: bug in Python2.2 in the nested scoping

Initial Comment:
Hello!
  There appears to be a bug in Python2.2 in the nested 
scoping.
Example:

"""
#the definition:
def a():
  x = 0
  i = lambda: eval('x')
  return i()

#the return of the above (on several machines, 
versions & systems):
>>> a()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 4, in a
  File "<stdin>", line 3, in <lambda>
  File "<string>", line 0, in ?
NameError: name 'x' is not defined
"""

and if I may, I have a remark in relation to the 
bove, there appear to be (in this particular case) an 
inconsistence between the lambda locals and globals,
as I understand, in the current state of development
the globals contain a 'unified' namespace with all the 
variables 'above' the nested block, but that does not 
appear to be the case! in the example above the lambda 
has no locals (as expected), and its globals DO NOT!! 
contain the namespace of the function 'a'..
I for one, can not understand this behaveur. 

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:04

Message:
Logged In: YES 
user_id=31392

This looks like its the same as the bug report I just
closed.  The explanation is certainly the same.  Read
A.3.2.  eval() does not have access to names boudning in
enclosing scopes -- just locals and globals.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 09:10

Message:
Logged In: YES 
user_id=31435

Sorry, I don't see any bugs here.  Your understanding of 
globals in Python is way too elaborate -- the globals 
belong to the module level, and the only thing a nested 
scope can do to a global is mask/hide one by introducing a 
local of the same name.  There's no such thing as 
a "unified namespace" in Python.

I suggest you study the "4.1 Code blocks, execution frames, 
and namespaces" section of the Reference Manual, ask 
questions if needed on comp.lang.python, then come back 
here if you still think there's a bug.

Assigning to Jeremy in anticipation <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528020&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 23:11:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 15:11:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-507477 ] Py_CompileString and tracebacks
Message-ID: <E16kvQf-0000cM-00@usw-sf-web1.sourceforge.net>

Bugs item #507477, was opened at 2002-01-23 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Krzysztof Zych (badpenguin)
>Assigned to: Jeremy Hylton (jhylton)
Summary: Py_CompileString and tracebacks

Initial Comment:
The API docs say, that when compiling a string with Py_Compilestring(code, filename, start), the filename param is used to construct the code object and may appear in tracebacks. Exceptions generated from these compiled objects evaluated with PyEval_EvalCode do not show this valuable description. This does not, somehow, apply when using Python's compile() and eval().

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:11

Message:
Logged In: YES 
user_id=31392

Can you explain in more detail what you think the bug is? 
Or are there multiple bugs?  From your description, it
sounds like something isn't right, but I can't tell exactly
what you'd like to see fixed.  A small example would help.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 23:12:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 15:12:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-529146 ] ICGlue byte alignment issue
Message-ID: <E16kvRl-0000d5-00@usw-sf-web1.sourceforge.net>

Bugs item #529146, was opened at 2002-03-12 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470

Category: Macintosh
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: ICGlue byte alignment issue

Initial Comment:
When using IC to read the Internet Configuration data (from Internet Control Panel), the type and creator codes appear to be misaligned.

For example, with the JPG entry, I receive back:

"EGog" & "le  ", instead of the proper: "JPEG" &"ogle" entries.....



----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-13 00:12

Message:
Logged In: YES 
user_id=45365

Raised the priority and put this in the 221 candidate group to make sure I don't forget to fix this before 2.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470


From noreply@sourceforge.net  Tue Mar 12 23:17:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 15:17:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-505490 ] Improve I/O redirection to embedding app
Message-ID: <E16kvWK-0002Rr-00@usw-sf-web3.sourceforge.net>

Bugs item #505490, was opened at 2002-01-18 20:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470

Category: Extension Modules
Group: Feature Request
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Stefan Franke (sfranke)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve I/O redirection to embedding app

Initial Comment:
When embedding Python into an existing application, you
usually do two things (among others):
1. Make Python use your own memory allocation
2. Redirect its I/O to the embedding app

While the former is very easy due to the excellent
pymem.h interface, the latter is quite painful, since
the interpreter uses stdin/out/err directly.

The common workaround I found on c.l.p is providing
your own file-like objects in an extension module and
assign them to sys.stdout/err within the interpreter.
This solution still has its problems (like getting
errors while import site.py)

I wish Python would encapsulate I/O in a similar way
than its malloc interface, and in some way I would
expect this from a language which is said to be 
designed for extending and embedding.

Unluckily I'm not able to this myself. I started my 
first embedding project a few days ago and still miss
the big picture about Python's C API.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-13 00:17

Message:
Logged In: YES 
user_id=45365

Just and Martin are absolutely right. I was thinking far too mac-centric, where the actual open of the console can cause problems to some embedding applications. For this reason MacPython has a way to completely override the console I/O routines, but there is no general reason to need this.

I'm closing the bug.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-12 23:16

Message:
Logged In: YES 
user_id=92689

I also don't understand that Jack's talking about: 
assigning to stdout/stderr is not only the proper 
solution, it also *works*, even for C tracebacks. Non-
debugging C code that uses fprintf() instead of the 
official PySys_WriteStd[err|out]() APIs is broken.

I think this bug should be closed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-24 20:35

Message:
Logged In: YES 
user_id=21627

What do you mean with "you don't get tracebacks"? The
attached a.py prints the traceback into the redirected file
just fine (with 2.2, on Solaris 8).

Also, which other output do you have in mind?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-01-21 11:14

Message:
Logged In: YES 
user_id=45365

Assigning to sys.stdout and friends is only half a solution: you don't get tracebacks and any other output produced by the C code.

Unfortunately there is no platform-independent solution without getting rid of stdio completely.

Fortunately there are platform-dependent solutions for many platforms. MacPython has a lowlevel hook to do this, for instance. Depending on your stdio implementation you may be able to hook into stdio on a low level.

An alternative 90% solution is to do the sys.stdout assignment and add Python code to print your tracebacks and such. An example of such code can be found in  Idle (or IDE, or PythonWin, or any other windowing Python IDE).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-18 22:26

Message:
Logged In: YES 
user_id=21627

I don't think that assigning to sys.stdout etc. is a
work-around; it is the proper solution. If you worry about
site.py, you can set Py_NoSiteFlag (which may be a good idea
in an embedded interpreter, anyway); if you then still need
site.py, you can import it on your own.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505490&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 02:29:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 18:29:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16kyWT-0006S4-00@usw-sf-web2.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Rich Salz (rsalz)
Date: 2002-03-12 21:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 14:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 02:48:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 18:48:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-525684 ] Need character macro cheat sheet
Message-ID: <E16kyp0-0006ds-00@usw-sf-web2.sourceforge.net>

Bugs item #525684, was opened at 2002-03-04 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525684&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Need character macro cheat sheet

Initial Comment:
For those of us without a lot of LaTeX experience
it would be helpful if Documenting Python had a
table listing the various macros used to generate
various special characters outside math mode.  For
example:

    macro                produces
    \e                   \
    \textless            <
    \textgreater         >
    \textasciicircum     ^

Skip


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 21:48

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/doc/doc.tex revision 1.60.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525684&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 03:57:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 19:57:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-420851 ] Missing docs for iteration support.
Message-ID: <E16kztZ-0007LV-00@usw-sf-web2.sourceforge.net>

Bugs item #420851, was opened at 2001-05-02 16:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=420851&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: 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: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 22:57

Message:
Logged In: YES 
user_id=3066

Added information about support the iterator protocol in
extension types (tp_iter, tp_iternext) in
Doc/ext/newtypes.tex revisions 1.8 and 1.6.6.2.

I think this is the last missing piece of the documentation
for this feature; closing the bug report.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-01 12:33

Message:
Logged In: YES 
user_id=3066

__iter__() documented in Doc/ref/ref3.tex revision 1.75.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-09-06 15:05

Message:
Logged In: YES 
user_id=3066

Documented the iter() function in Doc/lib/libfuncs.tex
revision 1.84.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-20 12: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 09: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  Wed Mar 13 05:29:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 21:29:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-529273 ] WeakValueDictionary.setdefault() bug
Message-ID: <E16l1KC-0004Ml-00@usw-sf-web1.sourceforge.net>

Bugs item #529273, was opened at 2002-03-13 00:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529273&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: WeakValueDictionary.setdefault() bug

Initial Comment:
In Python 2.1.2, WeakValueDictionary.setdefault() is
broken:

Python 2.1.2 (#1, Jan 27 2002, 18:54:41) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import weakref
>>> d = weakref.WeakValueDictionary()
>>> class C: pass
... 
>>> d.setdefault('yes', C())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/weakref.py", line 91,
in setdefault
    ref = ref(default, remove)
UnboundLocalError: local variable 'ref' referenced
before assignment

Attached is a simple patch, along with a test case. 
This is a bug fix candidate for Python 2.1.3, should
there be one.  It is not necessary for Python 2.2,
although you may want to port the test forward.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529273&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 05:50:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 21:50:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-529273 ] WeakValueDictionary.setdefault() bug
Message-ID: <E16l1es-0008U7-00@usw-sf-web2.sourceforge.net>

Bugs item #529273, was opened at 2002-03-13 00:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529273&group_id=5470

Category: Python Library
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: WeakValueDictionary.setdefault() bug

Initial Comment:
In Python 2.1.2, WeakValueDictionary.setdefault() is
broken:

Python 2.1.2 (#1, Jan 27 2002, 18:54:41) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)]
on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import weakref
>>> d = weakref.WeakValueDictionary()
>>> class C: pass
... 
>>> d.setdefault('yes', C())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.1/weakref.py", line 91,
in setdefault
    ref = ref(default, remove)
UnboundLocalError: local variable 'ref' referenced
before assignment

Attached is a simple patch, along with a test case. 
This is a bug fix candidate for Python 2.1.3, should
there be one.  It is not necessary for Python 2.2,
although you may want to port the test forward.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 00:50

Message:
Logged In: YES 
user_id=3066

Fixed using a very similar patch in Lib/weakref.py revision
1.8.2.1.  Backported a test that was added for Python 2.2.*
in Lib/test/test_weakref.py revision 1.7.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529273&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 06:02:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 22:02:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar'
Message-ID: <E16l1q3-0006Xg-00@usw-sf-web3.sourceforge.net>

Bugs item #500073, was opened at 2002-01-06 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470

>Category: Python Library
>Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: Bernard YUE (berniey)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser fail to handle '&foobar'

Initial Comment:
HTMLParser did not distingish between &foobar; and 
&foobar.  The later is still considered as a 
charref/entityref.  Below is my posposed fix:

File:  sgmllib.py

# SGMLParser.goahead()
# line 162-176
# from
            elif rawdata[i] == '&':
                match = charref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_charref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_entityref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue

# to
            elif rawdata[i] == '&'
                match = charref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an charref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else:
                        name = match.group(1)
                        self.handle_charref(name)
                        i = match.end(0)
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an entitiyref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else: 
                        name = match.group(1)
                        self.handle_entityref(name)
                        i = match.end(0)
                    continue



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:02

Message:
Logged In: YES 
user_id=3066

Bump the priority so I'll have to look at this when I'm not
too tired to think straight.

----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-09 01:35

Message:
Logged In: YES 
user_id=419276

Hi Guys,

I felt embarrass as I confuss everybody here.  Martin is nearly 
100% right.  Except that all &foo, &foo;, &#bar, &#bar; are all 
valid entity in HTML 4.01 as well if it was defined (I did not put 
enough test case in the old test.html to spot my mistake, when I 
ran it with the W3C Html validator, the new one should include 
all cases).  Hence the existing sgmllib.py was correct<Oops!>.

However, all the major browsers (IE, Natscape, Konqueror, Opera) 
choose to print the invalid HTML as plain text.  Hence I think 
htmllib.py might as well follow the crowd as well.

My suggestion is to added functions 
HTMLParser.unknown_charref() and and 
HTMLParser.unknown_entityref() as follows (files attached):

    # --- treat unknown entity as plain text

    def unknown_charref(self, ref):
        self.handle_data( '&#' + ref)

    def unknown_entityref(self, ref): 
        self.handle_data( '&'+ ref)

Sorry again for my previous incorrect patches.

Bernie


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-09 00:30

Message:
Logged In: YES 
user_id=21627

I still recommend to reject this patch, it is plain wrong.
Do we all agree that an HTML Document containing &you is
ill-formed (all HTML versions)? If so, it is a matter of
best-effort what to do with it.

In SGML, it is well-formed to omit the semicolon from the
entity name in a entity reference in certain cases, see

http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi

Therefore, omission of the semicolon does *not* mean that
you don't have an entity reference, and sgmllib's processing
of entity references is completely correct - it would be an
error to treat &you as data. 

Therefore, your document is correct SGML. It just fails to
be correct HTML, since the entity 'you' is not defined.

If you want to process such a document in a specific way, I
recommend to subclass HTMLParser, overriding unknown_entityref.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 23:42

Message:
Logged In: YES 
user_id=6380

I'm reassigning this to Fred.

In 2.2, the new HTMLParser may or may not still have this
problem.

In 2.1.2, I think that "fixing" it would be too big a risk
of breaking existing code, so I think it should not be
fixed.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 23:33

Message:
Logged In: YES 
user_id=44345

Bernie,

I tried your patch.  It looks good to me.  I was a tad
confused 
when I first read your bug report.  I thought
you were suggesting that 
"&foo" be interpreted as a
charref/entityref.  Instead you are 
tightening up the
parser.

That seems reasonable to me.  Martin, what 
do you think?

Skip


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 20:04

Message:
Logged In: YES 
user_id=419276

Hi again,

I just run the test.html with w3c's HTML validator.  &you does 
indeed treated as an invalid entityref in HTML 4.01.  I've displays 
test.html under IE, Netscape and Konqueror and it all gave the 
result I've expected.  I am not sure if sgmllib.py should stick with 
the standard or go with the general defacto interpretation.

But I think it is more sensable to treat &you as text.


Bernie


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 19:43

Message:
Logged In: YES 
user_id=419276

Hi Martin and Skip,

Sorry for not explain myself clearly.  What I mean is that &foobar 
should have been treated as '&foobar' literally (i.e. text), and 
&forbat; should be an entityref and &#forbar; as charref.

Currently, sgmllib treated &foobar as entityref and &#foobar as 
charref and match it against entityref table and charref table.  
Ignores the entity when a match is not found.

My suggested change should fix this problem.  Run test.py 
(test.py and test.html attached)

>./test.py

Me! Me & You! Copyright@copy;abc Copyright©abc © ©

But we are expecting:
Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

My suggested change will print the expected output.

# test.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3c.org/TR/html4/strict.dtd">

<html>
<head dir="ltr" lang="en">
  <TITLE>Testing Page</TITLE>
  <META name="AUTHOR" content="Bernard Yue">
  <META name="DESCRIPTION" content="Testing Page">
</head>
<body>
  <p>Me&you!  Me & You! Copyright@copy;abc 
Copyright&#169;abc &copy; &#169;
  </p>
</body>
</html>

# test.py
#!/usr/bin/env python

from htmllib import HTMLParser
from formatter import AbstractFormatter, DumbWriter


def test():
    _formatter = AbstractFormatter( DumbWriter())
    _parser = HTMLParser( _formatter)
    _f = open( './test.html')

    _parser.feed( _f.read())
    _f.close()
    _parser.close()
    print ''

if __name__ == '__main__':
    test()




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 17:02

Message:
Logged In: YES 
user_id=21627

I fail to see the problem as well. Please attach an example
document to this report. Without a detailed analysis of the
problem in question, there is zero chance that any change
like this is accepted.

Here is my analysis from your report: It seems that you
complain that sgmllib, when it sees an ill-formed document,
behaves in a particular way, whereas you expect to behave it
in a different way. Since the document is ill-formed
anyways, any behaviour is as good as any other.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 16:03

Message:
Logged In: YES 
user_id=44345

Bernie,

I see nothing wrong in principal with recognizing 
"&nbsp"
when the user should have typed "&nbsp;", but I wonder
about 
the validity of "&nbsp".  You mentioned it's still
a charref or 
entityref.  Is that documented somewhere or
is it simply a practical 
approach to a common problem?

Thanks,

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 06:05:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 12 Mar 2002 22:05:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-505747 ] markupbase handling of HTML declarations
Message-ID: <E16l1t6-0006Zh-00@usw-sf-web3.sourceforge.net>

Bugs item #505747, was opened at 2002-01-19 09:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 6
Submitted By: Greg Chapman (glchapman)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: markupbase handling of HTML declarations

Initial Comment:
Using Python 2.2., I tried to use websucker.py on this 
page:

http://magix.fri.uni-lj.si/orange/start/

This resulted in an exception in ParserBase._scan_name 
because _declname_match failed.  Examining the source 
for the page above, I see there are several tags that 
look like: "<![endif]>" where the first character 
after "<!" is a '[', not an alpha as mandated by 
_delcname_match.  Perhaps this is badly formed HTML (I 
see it was produced by FrontPage), but if not, it 
appears that _scan_name may have to be modified.  FYI, 
here's the traceback from the exception:

Traceback (most recent call last):
  File "C:\Python22\Tools\webchecker\websucker.py", 
line 126, in ?
    sys.exit(main() or 0)
  File "C:\Python22\Tools\webchecker\websucker.py", 
line 43, in main
    c.run()
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 349, in run
    self.dopage(url)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 403, in dopage
    page = self.getpage(url_pair)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 507, in getpage
    return Page(text, url, maxpage=self.maxpage, 
checker=self)
  File "C:\Python22\Tools\webchecker\webchecker.py", 
line 671, in __init__
    self.parser.feed(self.text)
  File "c:\Python22\lib\sgmllib.py", line 95, in feed
    self.goahead(0)
  File "c:\Python22\lib\sgmllib.py", line 161, in 
goahead
    k = self.parse_declaration(i)
  File "c:\Python22\lib\markupbase.py", line 66, in 
parse_declaration
    decltype, j = self._scan_name(j, i)
  File "c:\Python22\lib\markupbase.py", line 313, in 
_scan_name
    self.error("expected name token")
  File "c:\Python22\lib\sgmllib.py", line 102, in error
    raise SGMLParseError(message)
sgmllib.SGMLParseError: expected name token



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-15 01:13

Message:
Logged In: YES 
user_id=3066

Ugh!  I don't think that's legal HTML at all.  I'll have to
think about the right way to deal with it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505747&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 09:38:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 01:38:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16l5Cv-0002Nt-00@usw-sf-web2.sourceforge.net>

Bugs item #528274, was opened at 2002-03-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Jeremy Hylton (jhylton)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-13 10:38

Message:
Logged In: YES 
user_id=21627

The attached script also has the example

def f(x):
    a = x
    def g():
        print a
        return eval('a')
    return g

f(3)()

which currently produces

3
Traceback (most recent call last):
  File "a.py", line 8, in ?
    f(3)()
  File "a.py", line 5, in g
    return eval('a')
  File "<string>", line 0, in ?
NameError: name 'a' is not defined

I believe this is a bug, since the variable a is referenced
by the program text of the block that contains the call to
eval(); thus, accessing a inside eval should work well;
Reopening.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:34

Message:
Logged In: YES 
user_id=31392

I just checked the language reference, Section A.3.2:

> The builtin functions eval() and input() can not access
free 
> variables unless the variables are also referenced by the 
> program text of he block that contains the call to eval()
> or input(). 


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:31

Message:
Logged In: YES 
user_id=31392

I think the bug report is trying to say that the error in
the following code snippet is unexpected:

def f(x):
    a = x
    def g():
        return eval('a')
    return g

f(3)()

I'm not sure what the nested scopes appendix in the ref
manual says, but I don't see that this is a bug I care to
fix.  (If it's a bug at all.)  I don't believe the behavior
of eval() is defined with respect to free variables bound in
enclosing scopes.  In practical terms, the compiler has no
way to know that g() will try to access a in f().


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-11 08:16

Message:
Logged In: YES 
user_id=21627

It is not clear from your report what bug you are reporting.
Please structure a bug report in the following way:
- what did you do (you've explained this, providing a script)
- what happened (you've also reported that)
- what did you expect to happen instead (this is hard to
find in your report)
- why do you believe that the bug is in Python and not in
your understanding of the language (optional)

Analizing what you got as output: in your report:

- NameError in nested_1: This is not a bug. You declare a as
a global variable, yet there is no global variable with that
name, hence the NameError.

- NameError in nested_2: This appears to be a bug. See

http://www.python.org/doc/current/ref/dynamic-features.html

  for a discussion of nested scopes and dynamic features. In
your example, you reference the variable 'a' before using it
in eval(), so it should be available to eval(). Notice,
however, that removing the variable access from nested_2
also makes it unavailable to eval().

In the script, you argue that the variable should be either
global or local. This is not true in Python 2.2, see

http://www.python.org/doc/current/ref/nested-scopes.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 10:11:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 02:11:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-507477 ] Py_CompileString and tracebacks
Message-ID: <E16l5jJ-0000j5-00@usw-sf-web3.sourceforge.net>

Bugs item #507477, was opened at 2002-01-23 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Krzysztof Zych (badpenguin)
Assigned to: Jeremy Hylton (jhylton)
Summary: Py_CompileString and tracebacks

Initial Comment:
The API docs say, that when compiling a string with Py_Compilestring(code, filename, start), the filename param is used to construct the code object and may appear in tracebacks. Exceptions generated from these compiled objects evaluated with PyEval_EvalCode do not show this valuable description. This does not, somehow, apply when using Python's compile() and eval().

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:11

Message:
Logged In: YES 
user_id=31392

Can you explain in more detail what you think the bug is? 
Or are there multiple bugs?  From your description, it
sounds like something isn't right, but I can't tell exactly
what you'd like to see fixed.  A small example would help.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 11:08:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 03:08:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11
Message-ID: <E16l6cc-0003Mf-00@usw-sf-web2.sourceforge.net>

Bugs item #506349, was opened at 2002-01-21 01:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Harald Koschinski (astir)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Zope crashing with signal 11

Initial Comment:
after switching to python 2.1.2 compiled with GC
(intranet:/usr/local/src/Python-2.1.2 # ./configure
--without-pymalloc)
the crashes are back again :-(((((((((((((((((((((((

-------------------------------------------------------------------------------------
2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan
 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11
2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11
2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11
2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan
21 09:30:43 2002: Aiieee! 6749 exited with error code: 11
-----------------------------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-13 03:08

Message:
Logged In: NO 

I also have this problem. I have Zope 2.5.1 beta 1, and
it crashes on linux and on windows. It DOESN't crash,
however, with the -t1 option. 

I thought this could be a c extension we are using (ming),
but it also crashes without this library installed.

Does SOMEBODY have any idea? 
(ZOPE_SECURITY_POLICY=PYTHON doens't work also)
mart@eastsite.nl

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-22 20:28

Message:
Logged In: YES 
user_id=29957

This is a bug in the current Zope 2.4.3 release. Either
upgrade to the current 2.4 branch of CVS, grab the current
2.5 beta, or else wait until 2.4.4 is out.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 02:23

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 01:39

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 12:33:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 04:33:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-526488 ] MachO time.daylight incorrect
Message-ID: <E16l7wS-0004Nj-00@usw-sf-web2.sourceforge.net>

Bugs item #526488, was opened at 2002-03-06 18:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526488&group_id=5470

Category: Macintosh
Group: Python 2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Dan Grassi (dgrassi)
Assigned to: Jack Jansen (jackjansen)
Summary: MachO time.daylight incorrect

Initial Comment:
The MachO time.daylight variable is wrong and
MacClassic is correct.

Here are examples from both versions:

[localhost:~] dgrassi% python
Python 2.2 (#11, Jan  6 2002, 01:00:42) 
[GCC 2.95.2 19991024 (release)] on darwin
Type "help", "copyright", "credits" or "license" for
more information.
>>> from time import *
daylight
timezone
tzname
asctime()
>>> 1
>>> 18000
>>> ('EST', 'EDT')
>>> 'Wed Mar  6 11:40:58 2002'


Python 2.2 (#124, Dec 22 2001, 17:36:41)  [CW CARBON
GUSI2 THREADS GC] on mac
Type "copyright", "credits" or "license" for more
information.
>>> from time import *
daylight
timezone
tzname
asctime()
>>> 0
>>> 18000
>>> ('', '')
>>> 'Wed Mar  6 11:40:09 2002'


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-13 13:33

Message:
Logged In: YES 
user_id=45365

After private mail exchanges with Dan I'm convinced that there's nothing wrong with this behaviour.

Dan: if you disagree please reopen the bug and provide more information on what you had expected to see.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526488&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 13:02:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 05:02:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11
Message-ID: <E16l8Oa-0004iE-00@usw-sf-web2.sourceforge.net>

Bugs item #506349, was opened at 2002-01-21 09:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Harald Koschinski (astir)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Zope crashing with signal 11

Initial Comment:
after switching to python 2.1.2 compiled with GC
(intranet:/usr/local/src/Python-2.1.2 # ./configure
--without-pymalloc)
the crashes are back again :-(((((((((((((((((((((((

-------------------------------------------------------------------------------------
2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan
 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11
2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11
2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11
2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan
21 09:30:43 2002: Aiieee! 6749 exited with error code: 11
-----------------------------------------------------------------------------------

----------------------------------------------------------------------

>Comment By: Harald Koschinski (astir)
Date: 2002-03-13 13:02

Message:
Logged In: YES 
user_id=321375

Many people have this problem but nobody has as real
solution. I can fix the problem in to way's:
1. -t1
2. compiling python without gc

Both are no real solutions and have big disadvantages :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-13 11:08

Message:
Logged In: NO 

I also have this problem. I have Zope 2.5.1 beta 1, and
it crashes on linux and on windows. It DOESN't crash,
however, with the -t1 option. 

I thought this could be a c extension we are using (ming),
but it also crashes without this library installed.

Does SOMEBODY have any idea? 
(ZOPE_SECURITY_POLICY=PYTHON doens't work also)
mart@eastsite.nl

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-23 04:28

Message:
Logged In: YES 
user_id=29957

This is a bug in the current Zope 2.4.3 release. Either
upgrade to the current 2.4 branch of CVS, grab the current
2.5 beta, or else wait until 2.4.4 is out.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 10:23

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 09:39

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 13:17:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 05:17:56 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-446502 ] Expanding symlinks, addition to os.path
Message-ID: <E16l8dg-0004ta-00@usw-sf-web2.sourceforge.net>

Feature Requests item #446502, was opened at 2001-07-31 14:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=446502&group_id=5470

Category: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Erik Demaine (edemaine)
Assigned to: Nobody/Anonymous (nobody)
Summary: Expanding symlinks, addition to os.path

Initial Comment:
I propose to add a new function expand_symlinks() to
os.path (perhaps) that allows the user to easily
resolve a path into a "real file," expanding all
symlink references.  Specifically:

    expand_symlinks(path, limit=100) - Resolve symbolic
links.
  
    Resolves all symbolic links for a given path, and
returns the resulting path that refers to a true file. 
To detect symlink loops, an IOError exception is thrown
if more than 'limit' expansions do not lead to a true
file.  To prevent this behavior, the 'limit' argument
can be set to None.

Rationale:  In many scripts I write, and I suspect that
others write, I want to know the directory in which the
script lives.  Often os.path.dirname(sys.argv[0])
suffices, but this does not work when the script is
executed by way of a symlink.  In this situation,
os.path.dirname(expand_symlinks(sys.argv[0])) is what I
want.

Common objection: expand_symlinks() is just a few
lines.

Response: It is tedious to write the necessary while
loop for every script that wants to know where it
lives.  And it is easy to get wrong, especially by
omitting a check for symlink loops (too many symlink
expansions).

Of course, this is a personal opinion, and I'm open to
suggestions.

Attached is a prototype implementation.

----------------------------------------------------------------------

>Comment By: Erik Demaine (edemaine)
Date: 2002-03-13 08:17

Message:
Logged In: YES 
user_id=265183

I think this bug should now be closed; Python 2.2 includes a
new os.path.realpath which is essentially the corrected
version of the original proposal (thanks loewis for pointing
this out!).  Whoever put it in Python 2.2, thanks! :-)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-10-04 13:40

Message:
Logged In: YES 
user_id=21627

The proposed feature sounds good, but the implementation 
appears to be incorrect, if 'path' already goes through a 
symlink. Suppose you have the following structure

/usr/spool -> ../var/spool
/var/spool/mail -> ../mail

Now, I invoke expand_symlinks with /usr/spool/mail.
I should get /var/mail, but I do get /usr/mail, which does 
not exist.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=446502&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 21:39:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 13:39:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-528274 ] Nested Scopes bug (Confirmed)
Message-ID: <E16lGTL-0006dl-00@usw-sf-web1.sourceforge.net>

Bugs item #528274, was opened at 2002-03-10 23:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470

Category: None
Group: Python 2.2
Status: Open
Resolution: Wont Fix
>Priority: 2
Submitted By: Alex A. Naanou (alex_nanou)
Assigned to: Jeremy Hylton (jhylton)
Summary: Nested Scopes bug (Confirmed)

Initial Comment:
Bug confirmed.

description:
names that a in a scope just above the scome of the 
nested block (function) do not appear that functions 
globals thus bracking SOME (!) of the code that uses 
them. in particular the eval function, and all code 
that explicitly searces the name in the globals.

code:
//see the attached file.

output:
- a NameError raised in function nested_1:
'NameError: global name 'a' is not defined'
- a NameError raised in function nested_2:
'NameError: name 'a' is not defined'

workarround:
explicitly pass the variable to the function as its 
default argument (as in nested_0).
NOTE: declaring the name global does not work (as 
shown in function nested_1).
//see the attached file for more details.

test results:
 there appears to be a gap between the globals and the 
locals of a nested function.

test systems:
WIN2K v.5.00.2195 SP2
- ActivePython 2.2 Alpha 2 build 1 (ActiveState) 
Python 2.2a2+ (#22, Sep  5 2001, 14:10:41) [MSC 32 bit 
(Intel)] on win32
- Python 2.2 (#1, Dec 31 2001, 15:21:18) [GCC 2.95.3-5 
(cygwin special)] on cygwin
FreeBSD 4.5 (LocalBuild)
Python2.2 //I do not remember the exact build.

                                       With Respect..
                                             Alex.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-13 21:39

Message:
Logged In: YES 
user_id=31392

Yeah, I guess it would be nice if eval() behaved the way the
refman suggests.  It may be best to fix the refman and leave
the code the way it is.  eval() is a nuisance.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-13 09:38

Message:
Logged In: YES 
user_id=21627

The attached script also has the example

def f(x):
    a = x
    def g():
        print a
        return eval('a')
    return g

f(3)()

which currently produces

3
Traceback (most recent call last):
  File "a.py", line 8, in ?
    f(3)()
  File "a.py", line 5, in g
    return eval('a')
  File "<string>", line 0, in ?
NameError: name 'a' is not defined

I believe this is a bug, since the variable a is referenced
by the program text of the block that contains the call to
eval(); thus, accessing a inside eval should work well;
Reopening.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 22:34

Message:
Logged In: YES 
user_id=31392

I just checked the language reference, Section A.3.2:

> The builtin functions eval() and input() can not access
free 
> variables unless the variables are also referenced by the 
> program text of he block that contains the call to eval()
> or input(). 


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 22:31

Message:
Logged In: YES 
user_id=31392

I think the bug report is trying to say that the error in
the following code snippet is unexpected:

def f(x):
    a = x
    def g():
        return eval('a')
    return g

f(3)()

I'm not sure what the nested scopes appendix in the ref
manual says, but I don't see that this is a bug I care to
fix.  (If it's a bug at all.)  I don't believe the behavior
of eval() is defined with respect to free variables bound in
enclosing scopes.  In practical terms, the compiler has no
way to know that g() will try to access a in f().


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-11 07:16

Message:
Logged In: YES 
user_id=21627

It is not clear from your report what bug you are reporting.
Please structure a bug report in the following way:
- what did you do (you've explained this, providing a script)
- what happened (you've also reported that)
- what did you expect to happen instead (this is hard to
find in your report)
- why do you believe that the bug is in Python and not in
your understanding of the language (optional)

Analizing what you got as output: in your report:

- NameError in nested_1: This is not a bug. You declare a as
a global variable, yet there is no global variable with that
name, hence the NameError.

- NameError in nested_2: This appears to be a bug. See

http://www.python.org/doc/current/ref/dynamic-features.html

  for a discussion of nested scopes and dynamic features. In
your example, you reference the variable 'a' before using it
in eval(), so it should be available to eval(). Notice,
however, that removing the variable access from nested_2
also makes it unavailable to eval().

In the script, you argue that the variable should be either
global or local. This is not true in Python 2.2, see

http://www.python.org/doc/current/ref/nested-scopes.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528274&group_id=5470


From noreply@sourceforge.net  Wed Mar 13 21:41:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 13:41:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-505315 ] free vars sometimes show up in locals()
Message-ID: <E16lGUx-0006ex-00@usw-sf-web1.sourceforge.net>

Bugs item #505315, was opened at 2002-01-18 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Jeremy Hylton (jhylton)
Summary: free vars sometimes show up in locals()

Initial Comment:
Python 2.2 under Linux.

Whether free variables are part of the local dictionary
or not is
unclear from the doc, but certainly the following
description is buggy:

> in :
>
> def foo():
>     x=1
>     def bar():
>         x
>         print locals()
>     bar()
> foo()
>
> the result is "{}", indicating that x is not in
locals(). But in :
>
> def foo():
>     x=1
>     def bar():
>         x
>         y=1
>         print locals()
>     bar()
> foo()
>
> the result is "{'y':1, 'x':1}", indicating that the
presence of y has
> made x part of locals().

The above is supported by Michael Hudson and he
suggested to assign this
bug report to Jeremy.

Also in :

def foo():
    x=1
    class bar:
        x
        y=1
    print dir(bar)
foo()

the result is "['__doc__', '__module__', 'y']", showing
that x was not
included.

This means that the local dictionary for a class (which
is supposed to
make up the class dictionary) and for a function is not
the same if free
variables are ever to be considered as part of the
local dictionary.

Looking at the interpreter code, the problem lies in
PyFrame_FastToLocals() (Objects/frameobject.c:406)
where there is a test
for (f->f_nlocals == NULL) which prevents free and cell
variables from
being transfered.
It is unclear whether this is an optimization fossile
from before nested
scopes or whether this is done on purpose to
differenciate the behavior
between functions (which almost always have locals) and
classes (for
which nlocals is 0 when PyFrame_FastToLocals is called).

In my opinion, the test should be suppressed and cell
variables should not be transfered to the local dict,
but this breaks the current test suite (in particular
test_scope).

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-13 21:41

Message:
Logged In: YES 
user_id=31392

Yes.  I think cell variables should always be transferred.

Free variables should if eval() is supposed to work as
currently advertised, but I don't think that's desirable.


----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-01-18 13:48

Message:
Logged In: YES 
user_id=428521

I made a typo in the last paragraph.
I actually meant cell variables should always be transfered
to the local dict while free variables should not.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 01:39:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 17:39:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-529708 ] error in re docs or in sre
Message-ID: <E16lKD8-0002Jq-00@usw-sf-web3.sourceforge.net>

Bugs item #529708, was opened at 2002-03-13 16:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Wolfson (rumjuggler)
Assigned to: Fredrik Lundh (effbot)
Summary: error in re docs or in sre

Initial Comment:
The docs for positive lookbehind assertions state that
"(?<=abc)def will match "abcdef", since the lookbehind
will back up 3 characters and check if the contained
pattern matches", but that doesn't gibe with experience:

>>> import re
>>> f = re.compile('(?<=abc)def')
>>> print f.match('abcdef')
None
>>> 

I don't know enough about REs to know if this is a
documentation error or an sre error, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 02:08:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 18:08:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16lKfP-0000qL-00@usw-sf-web1.sourceforge.net>

Bugs item #529713, was opened at 2002-03-13 20:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 04:52:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 20:52:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash
Message-ID: <E16lNEA-00074I-00@usw-sf-web4.sourceforge.net>

Bugs item #529750, was opened at 2002-03-13 23:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam M. Fass (afass)
Assigned to: Nobody/Anonymous (nobody)
Summary: Circular reference makes Py_Init crash

Initial Comment:
Call Py_Initialize(), create two objects that 
reference each other, then call Py_Finalize() and 
then Py_Intialize() again.  This crashes Python with 
the following error message:

Fatal Python error: UNREF invalid object

The documentation on Py_Finalize() mentions that 
circular references will cause memory leaks, but it 
does not mention this behavior.

Platform info:
* Windows XP
* Visual C++ 6.0
* Python 2.2

------------------------------

#include "Python.h"

int main(int argc, char* argv[])
{
	char *code1 = "class TestClass:\n\ti = 3\nt1 
= TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = 
t1";
	Py_Initialize();

	PyRun_SimpleString(code1);

	Py_Finalize();

	Py_Initialize();
	Py_Finalize();
}

------------------------------

The string "code1" contains this python code:

class TestClass:
   i = 3
t1 = TestClass()
t2 = TestClass()
t1.t = t2
t2.t = t1

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 06:29:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 22:29:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-529083 ] Demo/xmlrpc/ http_server module missing
Message-ID: <E16lOk1-0007Jt-00@usw-sf-web2.sourceforge.net>

Bugs item #529083, was opened at 2002-03-12 20:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529083&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fredrik Lundh (effbot)
Summary: Demo/xmlrpc/ http_server module missing

Initial Comment:
The xmlrpc_handler.py demo file attempts to import
http_server, which does not exist.

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-03-14 07:29

Message:
Logged In: YES 
user_id=38376

note that the comment at the top of the file says
"an asynchronous XML-RPC server for Medusa"...

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529083&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 06:42:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 22:42:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-529708 ] error in re docs or in sre
Message-ID: <E16lOx1-0003cJ-00@usw-sf-web1.sourceforge.net>

Bugs item #529708, was opened at 2002-03-13 20:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470

>Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Wolfson (rumjuggler)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: error in re docs or in sre

Initial Comment:
The docs for positive lookbehind assertions state that
"(?<=abc)def will match "abcdef", since the lookbehind
will back up 3 characters and check if the contained
pattern matches", but that doesn't gibe with experience:

>>> import re
>>> f = re.compile('(?<=abc)def')
>>> print f.match('abcdef')
None
>>> 

I don't know enough about REs to know if this is a
documentation error or an sre error, though.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-14 01:42

Message:
Logged In: YES 
user_id=31435

Changed to Docs and reassigned to Fred.  Reassign to /F if 
it will help.

The example works fine (and matches 'def') if .search() is 
used instead of .match().  It shouldn't match if .match() 
is used (and doesn't).  This is a confusion due to the 
reader mistaking the word "match" used to describe that the 
regexp, well, *matches* <wink>, with the method named "match
()" that merely constrains the match to begin at the start 
of the string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 06:50:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 22:50:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-529708 ] error in re docs or in sre
Message-ID: <E16lP4l-0003hd-00@usw-sf-web1.sourceforge.net>

Bugs item #529708, was opened at 2002-03-14 02:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Wolfson (rumjuggler)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: error in re docs or in sre

Initial Comment:
The docs for positive lookbehind assertions state that
"(?<=abc)def will match "abcdef", since the lookbehind
will back up 3 characters and check if the contained
pattern matches", but that doesn't gibe with experience:

>>> import re
>>> f = re.compile('(?<=abc)def')
>>> print f.match('abcdef')
None
>>> 

I don't know enough about REs to know if this is a
documentation error or an sre error, though.

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-03-14 07:50

Message:
Logged In: YES 
user_id=38376

the documentation is confused.  <= means that the
pattern following the assertion ("def") will only
match if preceeded by the assertion ("abc").

>>> re.search("(?<=abc)def", "abcdef").group(0)
'def'

>>> re.search("(?<=abc)...", "abcdef").group(0)
'def'

>>> re.search("(?<=c)\w", "abcdef").group(0)
'd'


here's a slighty better example: match words, but
only if they're preceeded with a hyphen:

>>> re.search("(?<=-)\w+", "spam -egg").group(0)
'egg'


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 07:42

Message:
Logged In: YES 
user_id=31435

Changed to Docs and reassigned to Fred.  Reassign to /F if 
it will help.

The example works fine (and matches 'def') if .search() is 
used instead of .match().  It shouldn't match if .match() 
is used (and doesn't).  This is a confusion due to the 
reader mistaking the word "match" used to describe that the 
regexp, well, *matches* <wink>, with the method named "match
()" that merely constrains the match to begin at the start 
of the string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 07:21:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 13 Mar 2002 23:21:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16lPYJ-0000A6-00@usw-sf-web4.sourceforge.net>

Bugs item #529713, was opened at 2002-03-14 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 08:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 12:39:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 04:39:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-529083 ] Demo/xmlrpc/ http_server module missing
Message-ID: <E16lUWB-0002xP-00@usw-sf-web2.sourceforge.net>

Bugs item #529083, was opened at 2002-03-12 14:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529083&group_id=5470

Category: Demos and Tools
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fredrik Lundh (effbot)
Summary: Demo/xmlrpc/ http_server module missing

Initial Comment:
The xmlrpc_handler.py demo file attempts to import
http_server, which does not exist.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 07:39

Message:
Logged In: YES 
user_id=3066

So if that comment was serious, why wasn't it flashing gold
& red?  ;-)  OK, I missed that -- closing the bug as
"submitter illiteracy."

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-14 01:29

Message:
Logged In: YES 
user_id=38376

note that the comment at the top of the file says
"an asynchronous XML-RPC server for Medusa"...

</F>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529083&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 14:44:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 06:44:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-523117 ] ref.ps and ref.pdf formatting
Message-ID: <E16lWTJ-0005DE-00@usw-sf-web4.sourceforge.net>

Bugs item #523117, was opened at 2002-02-26 15:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470

Category: Documentation
>Group: Python 2.2
Status: Open
Resolution: None
>Priority: 8
Submitted By: David R Young (youngdr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref.ps and ref.pdf formatting

Initial Comment:
I have noticed what seems to be a formatting problem in both ref.ps (when 
viewed with GSview 4.1) and ref.pdf (when viewed with Acrobat 5.0.5). One 
example is on page 33 in section 5.3.4. The text of the modified BNF 
grammar notation for a rule seems to be much too long to fit on one line. 
Since it is not wrapped, a lot of the rule is not printed.

They are the files from pdf-letter-2.2.zip and postscript-letter-2.2.zip.

They are from 2001/December/21.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 09:44

Message:
Logged In: YES 
user_id=3066

This bug exists in both the 2.2 branch and the trunk.  It
should be considered a high-priority bug, especially for 2.2.1.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 15:37:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 07:37:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-529923 ] re module syntax documentation omission
Message-ID: <E16lXHq-000300-00@usw-sf-web3.sourceforge.net>

Bugs item #529923, was opened at 2002-03-14 15:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529923&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: re module syntax documentation omission

Initial Comment:
The discussion of what the backslash character does in 
the documentation chapter "4.2.1 Regular Expression 
Syntax" is incorrect. In addition to the sequences 
listed, other sequences also work, e.g. "\n", "\x7f", 
etc.

>>> p = r"\x40"
>>> p
'\x40'
>>> re.search(p, "foo@bar")
<_sre.SRE_Match object at 0x183fc0>
>>> re.search(p, "x40")           
>>>

According to the documentation, the first search 
should fail and the second should succeed. In fact, 
the opposite occurs.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529923&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 16:34:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 08:34:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16lYBP-0006Um-00@usw-sf-web4.sourceforge.net>

Bugs item #529713, was opened at 2002-03-13 20:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Bob Plankers (plankers)
Date: 2002-03-14 10:34

Message:
Logged In: YES 
user_id=485432

Okay, I'll take a look. I should be able to find the 
appropriate spots in configure.in/Makefile.pre.in for the 
$(CC). The problem didn't look so straightforward yesterday 
when I was prowling around in there. :-) Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 01:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 16:58:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 08:58:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-523117 ] ref.ps and ref.pdf formatting
Message-ID: <E16lYYO-0006mS-00@usw-sf-web4.sourceforge.net>

Bugs item #523117, was opened at 2002-02-26 20:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470

Category: Documentation
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 8
Submitted By: David R Young (youngdr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref.ps and ref.pdf formatting

Initial Comment:
I have noticed what seems to be a formatting problem in both ref.ps (when 
viewed with GSview 4.1) and ref.pdf (when viewed with Acrobat 5.0.5). One 
example is on page 33 in section 5.3.4. The text of the modified BNF 
grammar notation for a rule seems to be much too long to fit on one line. 
Since it is not wrapped, a lot of the rule is not printed.

They are the files from pdf-letter-2.2.zip and postscript-letter-2.2.zip.

They are from 2001/December/21.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-14 16:58

Message:
Logged In: YES 
user_id=6656

Setting group.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 14:44

Message:
Logged In: YES 
user_id=3066

This bug exists in both the 2.2 branch and the trunk.  It
should be considered a high-priority bug, especially for 2.2.1.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:24:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:24:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-529132 ] test_pyclbr broken on 2.2 branch
Message-ID: <E16lYxb-0004FJ-00@usw-sf-web3.sourceforge.net>

Bugs item #529132, was opened at 2002-03-12 21:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Michael Hudson (mwh)
Summary: test_pyclbr broken on 2.2 branch

Initial Comment:
The test suite fails for pyclbr; it looks like Jeremy's
changes for the test need to be back-ported (rev. 1.7),
since the httplib module that it relies on has changed.

test test_pyclbr failed -- Traceback (most recent call
last):
  File "../Lib/test/test_pyclbr.py", line 142, in
test_others
    cm('httplib', ignore=('error',    # set with =
  File "../Lib/test/test_pyclbr.py", line 66, in
checkModule
    self.assertHasattr(module, name, ignore)
  File "../Lib/test/test_pyclbr.py", line 36, in
assertHasattr
    self.failUnless(hasattr(obj, attr))
  File
"/home/fdrake/projects/python22-maint/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-13 11:27

Message:
Logged In: YES 
user_id=6656

Oops!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:24:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:24:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-529132 ] test_pyclbr broken on 2.2 branch
Message-ID: <E16lYxc-0004FO-00@usw-sf-web3.sourceforge.net>

Bugs item #529132, was opened at 2002-03-12 21:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Michael Hudson (mwh)
Summary: test_pyclbr broken on 2.2 branch

Initial Comment:
The test suite fails for pyclbr; it looks like Jeremy's
changes for the test need to be back-ported (rev. 1.7),
since the httplib module that it relies on has changed.

test test_pyclbr failed -- Traceback (most recent call
last):
  File "../Lib/test/test_pyclbr.py", line 142, in
test_others
    cm('httplib', ignore=('error',    # set with =
  File "../Lib/test/test_pyclbr.py", line 66, in
checkModule
    self.assertHasattr(module, name, ignore)
  File "../Lib/test/test_pyclbr.py", line 36, in
assertHasattr
    self.failUnless(hasattr(obj, attr))
  File
"/home/fdrake/projects/python22-maint/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-13 11:27

Message:
Logged In: YES 
user_id=6656

Oops!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:26:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:26:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-529132 ] test_pyclbr broken on 2.2 branch
Message-ID: <E16lYzk-0004Gz-00@usw-sf-web3.sourceforge.net>

Bugs item #529132, was opened at 2002-03-12 21:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Michael Hudson (mwh)
Summary: test_pyclbr broken on 2.2 branch

Initial Comment:
The test suite fails for pyclbr; it looks like Jeremy's
changes for the test need to be back-ported (rev. 1.7),
since the httplib module that it relies on has changed.

test test_pyclbr failed -- Traceback (most recent call
last):
  File "../Lib/test/test_pyclbr.py", line 142, in
test_others
    cm('httplib', ignore=('error',    # set with =
  File "../Lib/test/test_pyclbr.py", line 66, in
checkModule
    self.assertHasattr(module, name, ignore)
  File "../Lib/test/test_pyclbr.py", line 36, in
assertHasattr
    self.failUnless(hasattr(obj, attr))
  File
"/home/fdrake/projects/python22-maint/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:26

Message:
Logged In: YES 
user_id=6656

Heh, this is what I get for complaining about not getting
enough email from the tracker, I guess.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 17:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-13 11:27

Message:
Logged In: YES 
user_id=6656

Oops!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:52:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:52:02 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-516076 ] Assign boolean value to a weak reference
Message-ID: <E16lZOU-0004YF-00@usw-sf-web3.sourceforge.net>

Feature Requests item #516076, was opened at 2002-02-11 15:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=516076&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Stefan Franke (sfranke)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Assign boolean value to a weak reference

Initial Comment:
To test if a weak reference r is still alive, you type

    if r() is not None:
        print "Alive"

Wouldn't be

    if r:
        print "Alive"

more pythonic, since all values of any datatype that 
are not empty evaluate to "true"? Same if you think
about r as a pointer.

principle-of-least-surprise-ly yr's
Stefan


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 12:52

Message:
Logged In: YES 
user_id=3066

Rejected.

An early version of the proposal (and code) included a
predicate to test liveness of a weakref, but we determined
that it led to sloppy coding in this way:  If we test
liveness separately from retrieval, the "liveness" can
easily be changed between the test and the retrieval by
another thread dropping the reference.  Using your
"spelling" for the test, this code:

o = ... # some interesting object
wr = weakref.ref(o)
...
if wr:
    wr().doSomethingInteresting()

can fail with an AttributeError indicating that None does
not have an attribute doSomethingInteresting.  To avoid
being subject to this kind of race condition, it makes more
sense to write the conditional like this:

thing = wr()
if thing is not None:
    thing.doSomethingInteresting()

Restricting the test in this way makes it difficult to
stumble because of the race condition.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-16 19:03

Message:
Logged In: YES 
user_id=21627

Looks reasonable. Fred?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=516076&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:52:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:52:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-516299 ] urlparse can get fragments wrong
Message-ID: <E16lZOV-0004YJ-00@usw-sf-web3.sourceforge.net>

Bugs item #516299, was opened at 2002-02-11 23:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse can get fragments wrong

Initial Comment:
urlparse.urlparse() goes wrong on a URL such as
'http://amk.ca#foo', where there's a fragment
identifier and 
the hostname isn't followed by a slash.  It returns
'amk.ca#foo'
as the hostname portion of the URL.

While looking at that, I realized that test_urlparse()
only tests urljoin(), not urlparse() or urlunparse(). 
The attached patch
also adds a minimal test suite for urlparse(), but it
should
be still more comprehensive.  Unfortunately the RFC
doesn't include test cases, so I haven't done this yet.

(Assigned to you at random, Michael; feel free to
unassign it
if you lack the time.)


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 12:52

Message:
Logged In: YES 
user_id=11375

Unassigning -- anyone want to review my bug fix so I can check it 
in?

(leogah's idea of using the regex from RFC2396 is a good one, but 
that 
large a change should probably go into 2.3, not a .1 release.)


----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2002-02-20 08:56

Message:
Logged In: YES 
user_id=356893

The current version of the URI specification (RFC2396) 
includes a regexp for parsing URIs. For evil edge cases, I 
usually cut and paste directly into re.

Would it be an idea just to incorporate it rather than 
hammer the kinks out of the ad-hoc parser? If so, I'll hack 
on it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-02-13 05:45

Message:
Logged In: YES 
user_id=6656

Sorry, don't know *anything* about URLs and don't really
have the time to learn now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 17:54:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 09:54:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-528440 ] asyncore.poll bug
Message-ID: <E16lZQZ-0004Zk-00@usw-sf-web3.sourceforge.net>

Bugs item #528440, was opened at 2002-03-11 05:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528440&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Kjetil Jacobsen (kjetilja)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.poll bug

Initial Comment:
the asyncore.poll function (which uses select()) has
different handling of EINTR than asyncore.poll3 (which
uses poll()).

asyncore.poll3 resets the read-set when EINTR occurs,
but this is not done in asyncore.poll.

to be consistent with the behaviour of asyncore.poll3,
asyncore.poll should also reset the read/write sets
upon EINTR.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 12:54

Message:
Logged In: YES 
user_id=11375

This is a duplicate of bug #517554, and is fixed in the current CVS.

Thanks 
for your bug report!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528440&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 18:49:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 10:49:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-520644 ] __slots__ are not pickled
Message-ID: <E16laIK-0003Up-00@usw-sf-web1.sourceforge.net>

Bugs item #520644, was opened at 2002-02-20 20:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520644&group_id=5470

Category: Type/class unification
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ are not pickled

Initial Comment:
[Posted on behalf of Kevin Jacobs]

I have been hacking on ways to make lighter-weight 
Python objects using the
__slots__ mechanism that came with Python 2.2 new-
style class.  Everything
has gone swimmingly until I noticed that slots do not 
get pickled/cPickled
at all!

Here is a simple test case:

  import pickle,cPickle
  class Test(object):
    __slots__ = ['x']
    def __init__(self):
      self.x = 66666

  test = Test()

  pickle_str  = pickle.dumps( test )
  cpickle_str = cPickle.dumps( test )

  untest  = pickle.loads( pickle_str )
  untestc = cPickle.loads( cpickle_str )

  print untest.x    # raises AttributeError
  print untextc.x   # raises AttributeError

...

see 

http://aspn.activestate.com/ASPN/Mail/Message/python-
dev/1031499

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-07 02:43

Message:
Logged In: YES 
user_id=6380

I've decided on a "fix" that will go into 2.2.1.

When a new-style class defines slots and does not define
__getstate__, a dummy __getstate__ will be inserted into the
class that raises an exception. If the class wants slots to
be pickled, it should define a __getstate__ method.

In 2.3, we may revise this decision. The solution space is
large, and I don't want to rush it, hence the decision to
make it fail cleanly in 2.2.1 -- that's the best I can do.
The 2.2.1 solution will be compatible with whatever we
decide to do in 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-28 19:36

Message:
Logged In: YES 
user_id=6380

Good point. So maybe it should be up to the class to define
how to pickle slots.

An alternative idea could look at the type of descriptors;
slots use a different type than properties.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-28 19:29

Message:
Logged In: YES 
user_id=61408

[Guido on python-dev]
In particular, the fact that instances of classes with 
__slots__
appear picklable but lose all their slot values is a bug -- 
these
should either not be picklable unless you add a __reduce__ 
method, or
they should be pickled properly. ...
  I haven't made up my mind on how to fix this -- it would 
be
nice if __slots__ would automatically be pickled, but it's 
tricky
(although I think it's doable -- without ever referencing 
the
__slots__ variable :-).


[pedronis - my 2cts]
unless you plan some low-level (non-python-level) solution,
I think a main question is whether member and properties
are distinguishable and maybe whether among members
basic type members (file.softspace etc) and __slots__
members are distinguishable

It would be somehow strange and redundant if properties 
value would be automatically pickled (I see them as
computed value)

In java (bean) properties are not pickled and even
fields (= slots) can be marked as transient to avoid
their serialization.

In your picture it seems that all those things are
not to be dinstinguished, so probably no automatic
serialization, if there are members and given that
actually files for example cannot be pickled, would
be a reasonable solution.

Otherwise (distinguishable case) other 
automatic approaches can make sense too.

Just some - I hope valuable -  input and my opinion.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 15:03

Message:
Logged In: YES 
user_id=459565

Oops.  Please ignore the last paragraph of point #5.
Samuele's __allslots__ is fine with regard to the
example I presented.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 14:52

Message:
Logged In: YES 
user_id=459565

Samuele's sltattr.py is an interesting approach, though I 
am not entirely
sure it is necessary or feasible sufficiently address the 
significant
problems with slots via proxying __dict__ (see #5 below).  
Here is a mostly
complete list of smaller changes that are somewhat 
orthogonal to how we
address accesses to __dict__:

  1) Flatten slot lists:  Change obj.__class__.__slots__ to 
return an
     immutable list of all slot descriptors in the object 
(including all
     those of base classes).  The motivation for this is 
similar in spirit
     to storing a flattened __mro__.

     The advantages of this change are:

     a) allows for fast and explicit object reflection that 
correctly finds
        all dict attributes, all slot attributes.

     b) allows reflection implementations (like vars
(object) and pickle) to
        treat dict and slot attrs differently if we choose 
not to proxy
        __dict__.  This has several advantages, as 
explained in change #2.
        Also importantly, this way it is not possible 
to "lose" descriptors
        permanently by deleting them from 
obj.__class__.__dict__.

  2) Update reflection API even if we do not choose to 
proxy __dict__: Alter
     vars(object) to return a dictionary of all attributes, 
including both
     the contents of the non-proxied __dict__ and the valid 
attributes that
     result from iterating over __slots__ and evaluating 
the descriptors.
     The details of how this is best implemented depend on 
how we wish to
     define the behavior of modifying the resulting 
dictionary.  It could be
     either:

           a) explicitly immutable, which involves creating 
proxy objects
           b) mutable, which involves copying
           c) undefined, which means implicitly immutable

     Aside from the questions over the nature of the return 
type, this
     implementation (coupled with #1) has distinct 
advantages.  Specifically
     the native object.__dict__ has a very natural internal 
representation
     that pairs attribute names directly with values.  In 
contrast, a fair
     amount of additional work is needed to extract the 
slots that store
     values and create a dictionary of their names and 
values.  Other
     implementations will require a great deal more work 
since they would
     have to traverse though base classes to collecting 
slot descriptors.

  3) Flatten slot inheritance:  Update the new-style object 
inheritance
     mechanism to re-use slots of the same name, rather 
than creating a new
     slot and hiding the old.  This makes the inheritance 
semantics of slots
     equivalent to those of normal instance attributes and 
avoids
     introducing an ad-hoc and obscure method of data 
hiding.

  4) Update standard library to use new reflection API (and 
make them robust
     to properies at the same time) if we choose not to 
proxy __dict__.
     Virtually all of the changes are simple and involve 
updating these
     constructs:

           a) obj.__dict__
           b) obj.__dict__[blah]
           c) obj.__dict__[blah] = x

     (What these will become depends on other factors, 
including the context
      and semantics of vars(obj).)

     Here is a fairly complete list of Python 2.2 modules 
that will need to
     be updated:

       copy, copy_reg, inspect, pickle, pydoc, cPickle, 
Bastion, codeop,
       dis, doctest, gettext, ihooks, imputil, knee, pdb, 
profile, rexec,
       rlcompleter, tempfile, unittest, xmllib, xmlrpclib

    5) (NB: potentially controversial and not required) We 
could alter the
       descriptor protocol to make slots (and properties) 
more transparent
       when the values they reference do not exist.  Here 
is an example to
       illustrate this:

           class A(object):
             foo = 1

           class B(A):
             __slots__ = ('foo',)

           b = B()
           print b.foo
           > 1 or AttributeError?

        Currently an AttributeError is raised.  However, it 
is a fairly easy
        change to make AttributeErrors signal that 
attribute resolution is
        to continue until either a valid descriptor is 
evaluated, an
        instance-attribute is found, or until the 
resolution fails after
        search the meta-type, the type and the instance 
dictionary.

        The problem illustrated by the above code also 
occurs when trying to
        create proxies for __dict__, if the proxy worked on 
the basis of the
        collected slot descriptors (__allslots__ in 
Samuele's example).

I am prepared to submit patches to address each of these 
issues.  However, I
do want feedback beforehand, so that I do not waste time 
implementing
something that will never be accepted.


----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-22 01:33

Message:
Logged In: YES 
user_id=61408

some slots more like attrs illustrative python code

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-21 17:51

Message:
Logged In: YES 
user_id=459565

This bug raises questions about what a slot really is.
After a fair amount of discussion on Python-dev, we
have come up with basically two answers:

  1) a slot is a struct-member that is part of the
     private implementation of an object.  Slots should
     have their own semantics and not be expected to
     act like Python instance attributes.

  2) slots should be treated just like dict instance
     attributes except they are allocated statically
     within the object itself, and require slightly 
     different reflection methods.

Under (1), this bug isn't really a bug.  The class should
implement a __reduce__ function or otherwise hook into
the copy_reg system.

Under (2), this bug is just the tip of the iceberg. 
There are about 8 other problems with the current 
slot implementation that need to be resolved before
slots act almost identically to normal instance attributes.
Thankfully, I am fairly confident that I can supply 
patches that can achieve this, though I am waiting for
Guido to comment on this issue when he returns from his
trip.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520644&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 19:23:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 11:23:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-520645 ] unpickable basic types => confusing err
Message-ID: <E16laof-0003sh-00@usw-sf-web1.sourceforge.net>

Bugs item #520645, was opened at 2002-02-20 16:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520645&group_id=5470

Category: Type/class unification
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Samuele Pedroni (pedronis)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: unpickable basic types => confusing err

Initial Comment:
E.g.

Python 2.2
>>> f=open('c:/autoexec.bat','r')
>>> w=open('c:/transit/p','w')
>>> import pickle as pic
>>> pic.dump(f,w)
Traceback (most recent call last):
<<snip>>
TypeError: coercing to Unicode: need string or buffer, 
file found
>>> import cPickle as cpic
>>> cpic.dump(f,w)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\USR\PYTHON22\lib\copy_reg.py", line 56, in 
_reduce
    state = base(self)
TypeError: coercing to Unicode: need string or buffer, 
file found

VS.

Python 2.1 
>>> f=open('c:/autoexec.bat','r')
>>> w=open('c:/transit/p','w')
>>> import pickle as pic
>>> pic.dump(f,w)
Traceback (most recent call last):
<<snip>>
pickle.PicklingError: can't pickle 'file' object: 
<open file 'c:/autoexec.bat',
mode 'r' at 00795290>
>>> import cPickle as cpic
>>> cpic.dump(f,w)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpickleableError: Cannot pickle <type 'file'> 
objects
>>>



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-14 14:23

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this on the 2.2.1 branch or on the CVS 
trunk.  I believe it was fixed by rev. 2.10 of copy_reg.py 
(without this even being the intention :-).

Closing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520645&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 19:32:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 11:32:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-529132 ] test_pyclbr broken on 2.2 branch
Message-ID: <E16laxt-0000GG-00@usw-sf-web4.sourceforge.net>

Bugs item #529132, was opened at 2002-03-12 16:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Michael Hudson (mwh)
Summary: test_pyclbr broken on 2.2 branch

Initial Comment:
The test suite fails for pyclbr; it looks like Jeremy's
changes for the test need to be back-ported (rev. 1.7),
since the httplib module that it relies on has changed.

test test_pyclbr failed -- Traceback (most recent call
last):
  File "../Lib/test/test_pyclbr.py", line 142, in
test_others
    cm('httplib', ignore=('error',    # set with =
  File "../Lib/test/test_pyclbr.py", line 66, in
checkModule
    self.assertHasattr(module, name, ignore)
  File "../Lib/test/test_pyclbr.py", line 36, in
assertHasattr
    self.failUnless(hasattr(obj, attr))
  File
"/home/fdrake/projects/python22-maint/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 14:32

Message:
Logged In: YES 
user_id=3066

Yes, there is a bug in the test.  There still is, but it can
be solved for 2.3.  I've opened a separate bug report for that.

(The bug is that test_pyclbr relies on implementation
details of a module for it's test data; it should use some
Python source that it supplies.)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 12:26

Message:
Logged In: YES 
user_id=6656

Heh, this is what I get for complaining about not getting
enough email from the tracker, I guess.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 12:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 12:24

Message:
Logged In: YES 
user_id=6656

Used Jeremy's fix from the trunk.  This is related to 

[ 529135 ] test_pyclbr: bad dependency for input

which will remain open.

I guess I'm hoping this is a bug in the test, not in the
library...

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-13 06:27

Message:
Logged In: YES 
user_id=6656

Oops!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529132&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 20:22:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 12:22:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16lbk3-0004ZG-00@usw-sf-web1.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&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: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2002-03-14 20:22

Message:
Logged In: YES 
user_id=24723

This was an application problem, see:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Here's my new code which solves the problem, maybe
NonBlockingReader belongs in a library somewhere?

cheers,

Chris

PS:

from os import getcwd, chdir, system, popen3

from threading import Thread

class NonBlockingReader(Thread):

    def __init__(self,file):
        Thread.__init__(self)
        self.file = file
        
    def run(self):
        self.result = self.file.read()

    def read(self):
        return self.result
    
dir=getcwd()
chdir('E:\ZopeTests\sandbox\Zope3')
(i,c,e) = popen3('c:\python22\python test.py')
chdir(dir)

print "popened"
ct = NonBlockingReader(c)
print "ct created"
et = NonBlockingReader(e)
print "et created"
ct.start()
print "ct started"
et.start()
print "et started"
ct.join()
print "ct joined"
et.join()
print "et joined"

print ct.read()+et.read()

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 19:29

Message:
Logged In: YES 
user_id=68151

http://ezwiki.com/2.54/python/popenTest.py

This test works on 
Linux and Win2k.
It makes me think raw_input should flush 
stdout.
It's tricky getting this sort of thing to work.

Looks like 
test_popen2.py uses "more.exe" on Win98.
That might be a 
problem?
The client program must flush stdout after each write.


----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 17:27

Message:
Logged In: YES 
user_id=68151

I don't know about Win98*. But the example 
given did hang in Linux also.

The 
problem as posted here seems to be caused 
by fp.read() blocking until the spawned 
program exits. Using os.read() on Linux 
avoids this problem. I'll give it a try on 
Win2k and XP today. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 09:19

Message:
Logged In: YES 
user_id=31435

If would help a lot if someone produced a small, self-
contained test case that reproduced the problem.  The usual 
outcome of *trying* to is the discovery that popen() on 
Windows hangs "for no identifiable reason at all".  
Example:  there's a test_popen2.py in the std Python test 
suite.  It hangs about 1 time in 200 when I run it on 
Win98SE.  There's no identifiable cause; it just hangs 
sometimes, and when it does it's always hung in the bowels 
of MS's code.  There are no races in the Python code 
driving it.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 23:54

Message:
Logged In: YES 
user_id=68151

os.read() doesn't block.
I'd expect you have to 
call os.read in a loop. 


i,o,e=os.popen3("../../python 
errXX.py")
print os.read(o.fileno(),10000), 
os.read(e.fileno(),10000)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 18:22

Message:
Logged In: YES 
user_id=31435

Chris, which version of Windows are you talking about?  You 
identified W2K for Thomas Guettler, but didn't say which 
version you were using.  The popen implementations are 
radically different across Windows flavors, so knowing 
which one you're using is important.

Alas, "important" doesn't necessarily imply helpful 
<wink>.  Historically, popen-on-Windows bugs don't get 
fixed, because they hit a brick wall after blame gets 
traced to MS internals.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-09 18:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 14:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 22:35:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 14:35:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16ldp3-0001w1-00@usw-sf-web4.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 23:07:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 15:07:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-520644 ] __slots__ are not pickled
Message-ID: <E16leJT-0006Bn-00@usw-sf-web1.sourceforge.net>

Bugs item #520644, was opened at 2002-02-20 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520644&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Samuele Pedroni (pedronis)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __slots__ are not pickled

Initial Comment:
[Posted on behalf of Kevin Jacobs]

I have been hacking on ways to make lighter-weight 
Python objects using the
__slots__ mechanism that came with Python 2.2 new-
style class.  Everything
has gone swimmingly until I noticed that slots do not 
get pickled/cPickled
at all!

Here is a simple test case:

  import pickle,cPickle
  class Test(object):
    __slots__ = ['x']
    def __init__(self):
      self.x = 66666

  test = Test()

  pickle_str  = pickle.dumps( test )
  cpickle_str = cPickle.dumps( test )

  untest  = pickle.loads( pickle_str )
  untestc = cPickle.loads( cpickle_str )

  print untest.x    # raises AttributeError
  print untextc.x   # raises AttributeError

...

see 

http://aspn.activestate.com/ASPN/Mail/Message/python-
dev/1031499

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-14 18:07

Message:
Logged In: YES 
user_id=6380

I've checked in the proposed fix as typeobject.c rev. 2.129.
Also a test for the new behavior to test_descr.py and a NEWS
entry. These should all be added to 2.2.1 as well. Closing
now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 21:43

Message:
Logged In: YES 
user_id=6380

I've decided on a "fix" that will go into 2.2.1.

When a new-style class defines slots and does not define
__getstate__, a dummy __getstate__ will be inserted into the
class that raises an exception. If the class wants slots to
be pickled, it should define a __getstate__ method.

In 2.3, we may revise this decision. The solution space is
large, and I don't want to rush it, hence the decision to
make it fail cleanly in 2.2.1 -- that's the best I can do.
The 2.2.1 solution will be compatible with whatever we
decide to do in 2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-28 14:36

Message:
Logged In: YES 
user_id=6380

Good point. So maybe it should be up to the class to define
how to pickle slots.

An alternative idea could look at the type of descriptors;
slots use a different type than properties.

----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-28 14:29

Message:
Logged In: YES 
user_id=61408

[Guido on python-dev]
In particular, the fact that instances of classes with 
__slots__
appear picklable but lose all their slot values is a bug -- 
these
should either not be picklable unless you add a __reduce__ 
method, or
they should be pickled properly. ...
  I haven't made up my mind on how to fix this -- it would 
be
nice if __slots__ would automatically be pickled, but it's 
tricky
(although I think it's doable -- without ever referencing 
the
__slots__ variable :-).


[pedronis - my 2cts]
unless you plan some low-level (non-python-level) solution,
I think a main question is whether member and properties
are distinguishable and maybe whether among members
basic type members (file.softspace etc) and __slots__
members are distinguishable

It would be somehow strange and redundant if properties 
value would be automatically pickled (I see them as
computed value)

In java (bean) properties are not pickled and even
fields (= slots) can be marked as transient to avoid
their serialization.

In your picture it seems that all those things are
not to be dinstinguished, so probably no automatic
serialization, if there are members and given that
actually files for example cannot be pickled, would
be a reasonable solution.

Otherwise (distinguishable case) other 
automatic approaches can make sense too.

Just some - I hope valuable -  input and my opinion.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 10:03

Message:
Logged In: YES 
user_id=459565

Oops.  Please ignore the last paragraph of point #5.
Samuele's __allslots__ is fine with regard to the
example I presented.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-22 09:52

Message:
Logged In: YES 
user_id=459565

Samuele's sltattr.py is an interesting approach, though I 
am not entirely
sure it is necessary or feasible sufficiently address the 
significant
problems with slots via proxying __dict__ (see #5 below).  
Here is a mostly
complete list of smaller changes that are somewhat 
orthogonal to how we
address accesses to __dict__:

  1) Flatten slot lists:  Change obj.__class__.__slots__ to 
return an
     immutable list of all slot descriptors in the object 
(including all
     those of base classes).  The motivation for this is 
similar in spirit
     to storing a flattened __mro__.

     The advantages of this change are:

     a) allows for fast and explicit object reflection that 
correctly finds
        all dict attributes, all slot attributes.

     b) allows reflection implementations (like vars
(object) and pickle) to
        treat dict and slot attrs differently if we choose 
not to proxy
        __dict__.  This has several advantages, as 
explained in change #2.
        Also importantly, this way it is not possible 
to "lose" descriptors
        permanently by deleting them from 
obj.__class__.__dict__.

  2) Update reflection API even if we do not choose to 
proxy __dict__: Alter
     vars(object) to return a dictionary of all attributes, 
including both
     the contents of the non-proxied __dict__ and the valid 
attributes that
     result from iterating over __slots__ and evaluating 
the descriptors.
     The details of how this is best implemented depend on 
how we wish to
     define the behavior of modifying the resulting 
dictionary.  It could be
     either:

           a) explicitly immutable, which involves creating 
proxy objects
           b) mutable, which involves copying
           c) undefined, which means implicitly immutable

     Aside from the questions over the nature of the return 
type, this
     implementation (coupled with #1) has distinct 
advantages.  Specifically
     the native object.__dict__ has a very natural internal 
representation
     that pairs attribute names directly with values.  In 
contrast, a fair
     amount of additional work is needed to extract the 
slots that store
     values and create a dictionary of their names and 
values.  Other
     implementations will require a great deal more work 
since they would
     have to traverse though base classes to collecting 
slot descriptors.

  3) Flatten slot inheritance:  Update the new-style object 
inheritance
     mechanism to re-use slots of the same name, rather 
than creating a new
     slot and hiding the old.  This makes the inheritance 
semantics of slots
     equivalent to those of normal instance attributes and 
avoids
     introducing an ad-hoc and obscure method of data 
hiding.

  4) Update standard library to use new reflection API (and 
make them robust
     to properies at the same time) if we choose not to 
proxy __dict__.
     Virtually all of the changes are simple and involve 
updating these
     constructs:

           a) obj.__dict__
           b) obj.__dict__[blah]
           c) obj.__dict__[blah] = x

     (What these will become depends on other factors, 
including the context
      and semantics of vars(obj).)

     Here is a fairly complete list of Python 2.2 modules 
that will need to
     be updated:

       copy, copy_reg, inspect, pickle, pydoc, cPickle, 
Bastion, codeop,
       dis, doctest, gettext, ihooks, imputil, knee, pdb, 
profile, rexec,
       rlcompleter, tempfile, unittest, xmllib, xmlrpclib

    5) (NB: potentially controversial and not required) We 
could alter the
       descriptor protocol to make slots (and properties) 
more transparent
       when the values they reference do not exist.  Here 
is an example to
       illustrate this:

           class A(object):
             foo = 1

           class B(A):
             __slots__ = ('foo',)

           b = B()
           print b.foo
           > 1 or AttributeError?

        Currently an AttributeError is raised.  However, it 
is a fairly easy
        change to make AttributeErrors signal that 
attribute resolution is
        to continue until either a valid descriptor is 
evaluated, an
        instance-attribute is found, or until the 
resolution fails after
        search the meta-type, the type and the instance 
dictionary.

        The problem illustrated by the above code also 
occurs when trying to
        create proxies for __dict__, if the proxy worked on 
the basis of the
        collected slot descriptors (__allslots__ in 
Samuele's example).

I am prepared to submit patches to address each of these 
issues.  However, I
do want feedback beforehand, so that I do not waste time 
implementing
something that will never be accepted.


----------------------------------------------------------------------

Comment By: Samuele Pedroni (pedronis)
Date: 2002-02-21 20:33

Message:
Logged In: YES 
user_id=61408

some slots more like attrs illustrative python code

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-02-21 12:51

Message:
Logged In: YES 
user_id=459565

This bug raises questions about what a slot really is.
After a fair amount of discussion on Python-dev, we
have come up with basically two answers:

  1) a slot is a struct-member that is part of the
     private implementation of an object.  Slots should
     have their own semantics and not be expected to
     act like Python instance attributes.

  2) slots should be treated just like dict instance
     attributes except they are allocated statically
     within the object itself, and require slightly 
     different reflection methods.

Under (1), this bug isn't really a bug.  The class should
implement a __reduce__ function or otherwise hook into
the copy_reg system.

Under (2), this bug is just the tip of the iceberg. 
There are about 8 other problems with the current 
slot implementation that need to be resolved before
slots act almost identically to normal instance attributes.
Thankfully, I am fairly confident that I can supply 
patches that can achieve this, though I am waiting for
Guido to comment on this issue when he returns from his
trip.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520644&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 23:24:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 15:24:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16leZt-00083y-00@usw-sf-web3.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
Logged In: YES 
user_id=11375

Looking at the implementation of accept() in asyncore.py, it will 
return 
None when the socket is in non-blocking mode and the accept() would block.  
There's really nothing else accept() could
return in this case, so you'll 
probably have to write your code to 
handle this case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Thu Mar 14 23:32:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 15:32:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-508157 ] urllib.urlopen results.readline is slow
Message-ID: <E16lei3-00089d-00@usw-sf-web3.sourceforge.net>

Bugs item #508157, was opened at 2002-01-24 16:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Davidson (kbdavidson)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen results.readline is slow

Initial Comment:
The socket file object underlying the return from 
urllib.urlopen() is opened without any buffering 
resulting in very slow performance of results.readline
().  The specific problem is in the 
httplib.HTTPResponse constructor.  It calls 
sock.makefile() with a 0 for the buffer size.  Forcing 
the buffer size to 4096 results in the time for 
calling readline() on a 60K character line to go from 
16 seconds to .27 seconds (there is other processing 
going on here but the magnitude of the difference is 
correct).

I am using Python 2.0 so I can not submit a patch 
easily but the problem appears to still be present in 
the 2.2 source.  The specific change is to change the 
0 in sock.makefile() to 4096 or some other reasonable 
buffer size:

class HTTPResponse:
    def __init__(self, sock, debuglevel=0):
        self.fp = sock.makefile('rb', 0)    <= change 
to 4096
        self.debuglevel = debuglevel



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:32

Message:
Logged In: YES 
user_id=11375

Greg Stein originally wrote it;  I'll ping him.

I suspect it might be because of 
HTTP pipelining; if multiple
responses will be returned over a socket, you 
probably can't use buffering because the buffer might consume the end of 
response #1 and the start of response #2.  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-25 09:12

Message:
Logged In: YES 
user_id=6380

I wonder why the author explicitly turned off buffering.
There probably was a reason? Without knowing why, we can't
just change it.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-24 16:54

Message:
Logged In: NO 

What platform?

--Guido (not logged in)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 00:13:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 16:13:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lfLB-00009I-00@usw-sf-web3.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 00:48:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 16:48:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lftb-0000Zp-00@usw-sf-web3.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 02:49:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 18:49:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-530143 ] Typo in 3.16 copy_reg doc
Message-ID: <E16lhmb-0004dr-00@usw-sf-web4.sourceforge.net>

Bugs item #530143, was opened at 2002-03-14 18:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in 3.16 copy_reg doc

Initial Comment:
On the page at <http://www.python.org/doc/current/lib/module-copyreg.html> in the second 
half about the pickle function, it says, in part:

> pickle(type, function[, constructor]) 
>     Declares that function should be used as a ``reduction'' function for objects of type type;
>     type should not a class object. function should return either a string or a tuple containing 
>     two or three elements. 

The part that says "type should not a class object" seems wrong. I think it should probably be 
"type should be a class object".


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 02:52:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 18:52:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16lhpM-0003zq-00@usw-sf-web2.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

>Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-14 21:52

Message:
Logged In: YES 
user_id=482117

My question then is why didn't it do this when I ran my app
with python 2.1.1. Something has changed in 2.2 and I don't
think it was asyncore, I do know some work was done to the
low level socket and select modules so they could handle
IPV6. I understand why the None is being returned, but an
accept shouldn't even be called on a write event coming from
a select or poll.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
Logged In: YES 
user_id=11375

Looking at the implementation of accept() in asyncore.py, it will 
return 
None when the socket is in non-blocking mode and the accept() would block.  
There's really nothing else accept() could
return in this case, so you'll 
probably have to write your code to 
handle this case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 03:33:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 19:33:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-530159 ] solaris build reds _FILE_OFFSET_BIT
Message-ID: <E16liSp-00055z-00@usw-sf-web4.sourceforge.net>

Bugs item #530159, was opened at 2002-03-15 14:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530159&group_id=5470

Category: None
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: solaris build reds _FILE_OFFSET_BIT

Initial Comment:
Solaris/sparc 2.7, building the 2.2 branch with gcc
2.95.2. No special magic options provided to ./configure.

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I/import/src/lang/python/CVS/22branch/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/import/src/lang/python/CVS/22branch/dist/src/Modules/pypcre.c
-o build/temp.solaris-2.7-sun4u-2.2/pypcre.o
In file included from
/import/src/lang/python/CVS/22branch/dist/src/Include/Python.h:24,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pcre.h:11,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pcre-int.h:55,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pypcre.c:48:pyconfig.h:104:
warning: `_FILE_OFFSET_BITS' redefined
/usr/include/sys/feature_tests.h:96: warning: this is
the location of the previous definition

The system header's defining it as 32, pyconfig.h's
overriding that and setting it to 64, but isn't setting
_LP64

Not sure if this will break anything at all...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530159&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 03:47:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 19:47:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-530163 ] fpectl build on solaris: -lsunmath
Message-ID: <E16ligs-0005FC-00@usw-sf-web4.sourceforge.net>

Bugs item #530163, was opened at 2002-03-15 14:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: fpectl build on solaris: -lsunmath

Initial Comment:
This is on Solaris 2.7, with gcc2.95.2

Observed on both the trunk and the release22 branch.

By default, the configure/setup stuff isn't including
 -L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath
when linking fpectl.so. This means that this doesn't
produce a working module (it needs libsunmath for
ieee_handler)

My autoconf knowledge isn't excellent, but I'm going
to have a look-see, figure out the easiest way to do
this...



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 06:16:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 22:16:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-518775 ] buffer object API description truncated
Message-ID: <E16ll0d-0006le-00@usw-sf-web4.sourceforge.net>

Bugs item #518775, was opened at 2002-02-17 10:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518775&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Greg Stein (gstein)
Summary: buffer object API description truncated

Initial Comment:
In section 10.6 of the C API reference manual,
Python-2-2/Doc/html/api/buffer-structs.html

the description for the last subroutine listed,

int (*getcharbufferproc) (PyObject *self, int segment,
const char **ptrptr)

is omitted.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-15 01:16

Message:
Logged In: YES 
user_id=3066

It hasn't been dropped, it just hasn't been written.  ;-( 
There is a general level of incompleteness in the API
document which we are aware of and are working to correct
(albiet more slowly than we'd like).

Assigning to Greg since he spent more time developing the
buffer API than anyone else.

The documentation for this should be added to the
release21-maint and release22-maint branches and the
development trunk.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518775&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 06:34:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 14 Mar 2002 22:34:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16llIN-0006FV-00@usw-sf-web2.sourceforge.net>

Bugs item #529713, was opened at 2002-03-13 20:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Bob Plankers (plankers)
Date: 2002-03-15 00:34

Message:
Logged In: YES 
user_id=485432

I am attaching a patch for the linking problem, as well as 
a problem where under AIX the modules were not building at 
all. On a machine where Python is not installed it was 
looking for ld_so_aix in /usr/local/lib/...wherever instead 
of in Modules/ld_so_aix.

The linking problem simply changes a $(LINKCC) to \.

Let me know if this sucks. :-) It seems to work fine 
building under Linux (RHL 7.2) with the patches, but that 
certainly is not a comprehensive test.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-14 10:34

Message:
Logged In: YES 
user_id=485432

Okay, I'll take a look. I should be able to find the 
appropriate spots in configure.in/Makefile.pre.in for the 
$(CC). The problem didn't look so straightforward yesterday 
when I was prowling around in there. :-) Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 01:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 09:11:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 01:11:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16lnkI-0000Bw-00@usw-sf-web4.sourceforge.net>

Bugs item #529713, was opened at 2002-03-14 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:11

Message:
Logged In: YES 
user_id=21627

The chunk on changing LDSHARED to BLDSHARED is definitely right.

On the chunk using $(CC) - I cannot really see why this is
necessary. Right above the AIX assignment of LINKCC, there
is a test with three alternatives ($CXX is empty, it is
needed to link a C++ program, it is not needed). In either
case, LINKCC is set. So it is surprising why LINKCC is then
not set in the right-hand side of the AIX assignment.

Can you please investigate? Perhaps putting echo statements
would be sufficient, or 'set -x' right above that entire
chain of if statements.

Notice that I hesitate to accept your patch because we also
have bug reports where user complain that LINKCC should use
the C++ compiler if available. The test is designed to
enable that feature; your patch would break it.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-15 07:34

Message:
Logged In: YES 
user_id=485432

I am attaching a patch for the linking problem, as well as 
a problem where under AIX the modules were not building at 
all. On a machine where Python is not installed it was 
looking for ld_so_aix in /usr/local/lib/...wherever instead 
of in Modules/ld_so_aix.

The linking problem simply changes a $(LINKCC) to \.

Let me know if this sucks. :-) It seems to work fine 
building under Linux (RHL 7.2) with the patches, but that 
certainly is not a comprehensive test.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-14 17:34

Message:
Logged In: YES 
user_id=485432

Okay, I'll take a look. I should be able to find the 
appropriate spots in configure.in/Makefile.pre.in for the 
$(CC). The problem didn't look so straightforward yesterday 
when I was prowling around in there. :-) Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 08:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 09:18:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 01:18:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-530159 ] solaris build reds _FILE_OFFSET_BIT
Message-ID: <E16lnqc-0000GY-00@usw-sf-web4.sourceforge.net>

Bugs item #530159, was opened at 2002-03-15 04:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530159&group_id=5470

Category: None
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: solaris build reds _FILE_OFFSET_BIT

Initial Comment:
Solaris/sparc 2.7, building the 2.2 branch with gcc
2.95.2. No special magic options provided to ./configure.

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I/import/src/lang/python/CVS/22branch/dist/src/./Include
-I/usr/local/include -IInclude/ -c
/import/src/lang/python/CVS/22branch/dist/src/Modules/pypcre.c
-o build/temp.solaris-2.7-sun4u-2.2/pypcre.o
In file included from
/import/src/lang/python/CVS/22branch/dist/src/Include/Python.h:24,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pcre.h:11,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pcre-int.h:55,
                 from
/import/src/lang/python/CVS/22branch/dist/src/Modules/pypcre.c:48:pyconfig.h:104:
warning: `_FILE_OFFSET_BITS' redefined
/usr/include/sys/feature_tests.h:96: warning: this is
the location of the previous definition

The system header's defining it as 32, pyconfig.h's
overriding that and setting it to 64, but isn't setting
_LP64

Not sure if this will break anything at all...


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:18

Message:
Logged In: YES 
user_id=21627

This originates from pypcre breaking the rule that Python.h
must be included first. Nothing in pypcre cares about LFS,
so it is harmless.

Fixed in pypcre.c 2.23.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530159&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 09:22:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 01:22:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-530163 ] fpectl build on solaris: -lsunmath
Message-ID: <E16lnvF-0005tI-00@usw-sf-web3.sourceforge.net>

Bugs item #530163, was opened at 2002-03-15 04:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: fpectl build on solaris: -lsunmath

Initial Comment:
This is on Solaris 2.7, with gcc2.95.2

Observed on both the trunk and the release22 branch.

By default, the configure/setup stuff isn't including
 -L/opt/SUNWspro/lib -R/opt/SUNWspro/lib -lsunmath
when linking fpectl.so. This means that this doesn't
produce a working module (it needs libsunmath for
ieee_handler)

My autoconf knowledge isn't excellent, but I'm going
to have a look-see, figure out the easiest way to do
this...



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:22

Message:
Logged In: YES 
user_id=21627

I think there is absolutely no way to find SUNWspro
reliably. /opt is but one location where it might be
installed - on our infrastructure, it is not in /opt, since
that is not NFS shared.

If c89 is on the path, it could give an indication where
SUNWspro may be installed.

In any case, I recommend to perform the necessary
computation in setup.py, not in autoconf.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530163&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 09:57:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 01:57:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16loSR-0008Nh-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 01:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 01:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 09:57:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 01:57:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16loSf-0008Nq-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 01:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 01:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 10:03:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 02:03:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-516299 ] urlparse can get fragments wrong
Message-ID: <E16loZ2-0000lv-00@usw-sf-web4.sourceforge.net>

Bugs item #516299, was opened at 2002-02-12 04:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse can get fragments wrong

Initial Comment:
urlparse.urlparse() goes wrong on a URL such as
'http://amk.ca#foo', where there's a fragment
identifier and 
the hostname isn't followed by a slash.  It returns
'amk.ca#foo'
as the hostname portion of the URL.

While looking at that, I realized that test_urlparse()
only tests urljoin(), not urlparse() or urlunparse(). 
The attached patch
also adds a minimal test suite for urlparse(), but it
should
be still more comprehensive.  Unfortunately the RFC
doesn't include test cases, so I haven't done this yet.

(Assigned to you at random, Michael; feel free to
unassign it
if you lack the time.)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-15 10:03

Message:
Logged In: YES 
user_id=6656

Well, make test now says this:

test test_urlparse produced unexpected output:
**********************************************************************
*** lines 2-6 of actual output doesn't appear in expected
output after line 1:
+ http://www.python.org = ('http', 'www.python.org', '', '',
'', '')
+ http://www.python.org#abc = ('http', 'www.python.org', '',
'', '', 'abc')
+ http://www.python.org/#abc = ('http', 'www.python.org',
'/', '', '', 'abc')
+ http://a/b/c/d;p?q#f = ('http', 'a', '/b/c/d', 'p', 'q', 'f')
+
**********************************************************************

did you just forget to update output/test_urlparse?

Is this a 2.2.1 candidate?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 17:52

Message:
Logged In: YES 
user_id=11375

Unassigning -- anyone want to review my bug fix so I can check it 
in?

(leogah's idea of using the regex from RFC2396 is a good one, but 
that 
large a change should probably go into 2.3, not a .1 release.)


----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2002-02-20 13:56

Message:
Logged In: YES 
user_id=356893

The current version of the URI specification (RFC2396) 
includes a regexp for parsing URIs. For evil edge cases, I 
usually cut and paste directly into re.

Would it be an idea just to incorporate it rather than 
hammer the kinks out of the ad-hoc parser? If so, I'll hack 
on it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-02-13 10:45

Message:
Logged In: YES 
user_id=6656

Sorry, don't know *anything* about URLs and don't really
have the time to learn now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 10:07:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 02:07:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-530236 ] os.py assumes existence of statvfs_resul
Message-ID: <E16loca-0004f3-00@usw-sf-web1.sourceforge.net>

Bugs item #530236, was opened at 2002-03-15 11:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530236&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Michael Hudson (mwh)
Summary: os.py assumes existence of statvfs_resul

Initial Comment:
Os.py rev. 1.52 assumes that stat_result and statvfs_result exist on all platforms.

statvfs_result doesn't exist on MacOS (classic), and there may even be platforms that don't have stat_result.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530236&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 10:20:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 02:20:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-530236 ] os.py assumes existence of statvfs_resul
Message-ID: <E16lop7-0000CS-00@usw-sf-web2.sourceforge.net>

Bugs item #530236, was opened at 2002-03-15 10:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530236&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Jack Jansen (jackjansen)
Assigned to: Michael Hudson (mwh)
Summary: os.py assumes existence of statvfs_resul

Initial Comment:
Os.py rev. 1.52 assumes that stat_result and statvfs_result exist on all platforms.

statvfs_result doesn't exist on MacOS (classic), and there may even be platforms that don't have stat_result.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-15 10:20

Message:
Logged In: YES 
user_id=6656

Damn, I knew I'd need to worry about this, but forgot.

Fixed in revision 1.53 of os.py.

Sorry.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530236&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 12:44:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 04:44:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16lr43-0008AW-00@usw-sf-web3.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 13:34:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 05:34:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-516299 ] urlparse can get fragments wrong
Message-ID: <E16lrqt-00071I-00@usw-sf-web1.sourceforge.net>

Bugs item #516299, was opened at 2002-02-11 23:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse can get fragments wrong

Initial Comment:
urlparse.urlparse() goes wrong on a URL such as
'http://amk.ca#foo', where there's a fragment
identifier and 
the hostname isn't followed by a slash.  It returns
'amk.ca#foo'
as the hostname portion of the URL.

While looking at that, I realized that test_urlparse()
only tests urljoin(), not urlparse() or urlunparse(). 
The attached patch
also adds a minimal test suite for urlparse(), but it
should
be still more comprehensive.  Unfortunately the RFC
doesn't include test cases, so I haven't done this yet.

(Assigned to you at random, Michael; feel free to
unassign it
if you lack the time.)


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 08:34

Message:
Logged In: YES 
user_id=11375

Oops, sorry.  Revised version of the patch attached, that 
just adds the diffs for test_urlparse.

This would be a 2.2.1 candidate, assuming my fix is 
otherwise correct.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-15 05:03

Message:
Logged In: YES 
user_id=6656

Well, make test now says this:

test test_urlparse produced unexpected output:
**********************************************************************
*** lines 2-6 of actual output doesn't appear in expected
output after line 1:
+ http://www.python.org = ('http', 'www.python.org', '', '',
'', '')
+ http://www.python.org#abc = ('http', 'www.python.org', '',
'', '', 'abc')
+ http://www.python.org/#abc = ('http', 'www.python.org',
'/', '', '', 'abc')
+ http://a/b/c/d;p?q#f = ('http', 'a', '/b/c/d', 'p', 'q', 'f')
+
**********************************************************************

did you just forget to update output/test_urlparse?

Is this a 2.2.1 candidate?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 12:52

Message:
Logged In: YES 
user_id=11375

Unassigning -- anyone want to review my bug fix so I can check it 
in?

(leogah's idea of using the regex from RFC2396 is a good one, but 
that 
large a change should probably go into 2.3, not a .1 release.)


----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2002-02-20 08:56

Message:
Logged In: YES 
user_id=356893

The current version of the URI specification (RFC2396) 
includes a regexp for parsing URIs. For evil edge cases, I 
usually cut and paste directly into re.

Would it be an idea just to incorporate it rather than 
hammer the kinks out of the ad-hoc parser? If so, I'll hack 
on it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-02-13 05:45

Message:
Logged In: YES 
user_id=6656

Sorry, don't know *anything* about URLs and don't really
have the time to learn now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 15:07:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 07:07:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16ltJD-0003ZG-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 10:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 04:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 16:46:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 08:46:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-523825 ] python-mode.el: honor-comment-indent bug
Message-ID: <E16luqy-0005Qk-00@usw-sf-web4.sourceforge.net>

Bugs item #523825, was opened at 2002-02-28 07:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523825&group_id=5470

Category: Demos and Tools
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Christian Stork (cst)
Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode.el: honor-comment-indent bug

Initial Comment:
Minor bug in the Python Emacs mode (simple patch provided):

Choosing neither t nor nil for the custom variable
py-honor-comment-indentation prevents proper indention
after unindented code.  Also it wrongly honors
block-comments wrt indention.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-15 11:46

Message:
Logged In: YES 
user_id=12800

Accepted, with a few minor mods.  See newly uploaded
attachment for what I will apply to the Python 2.3 trunk.

Thanks!  (New patch is a 2.2.1 candidate).


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 12:51

Message:
Logged In: YES 
user_id=6656

<poke/>

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-03 13:13

Message:
Logged In: YES 
user_id=6656

Barry, is this sensible?  Is it a 2.2.1 candidate?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523825&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 16:49:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 08:49:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-521937 ] email module: object instantiation fails
Message-ID: <E16lut9-0000rE-00@usw-sf-web1.sourceforge.net>

Bugs item #521937, was opened at 2002-02-23 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521937&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Sheila King (sheilaking)
Assigned to: Barry Warsaw (bwarsaw)
Summary: email module: object instantiation fails

Initial Comment:
email module fails to instantiate an object when
reading in a poorly formed message from either the
message_from_file or message_from_string object.

I have commented on this already on the python-list. I
will include links to the discussions below:
http://mail.python.org/pipermail/python-list/2002-February/085513.html
http://mail.python.org/pipermail/python-list/2002-February/089220.html



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-15 11:49

Message:
Logged In: YES 
user_id=12800

In private email w/ Sheila, we agreed that the current
behavior of the stock parsers is the intended behavior (i.e.
that there is one very strict parser and one fairly lenient
parser).  Other instantiation behavior, such as one that
guesses the missing MIME chrome, would be the domain of a
new parser, which Sheila thinks she might try to write and
contribute.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-24 01:06

Message:
Logged In: YES 
user_id=31435

Assigned to Barry.  Short course:  trying to load an ill-
formed msg can raise an exception under the email package 
where under earlier libraries the same inupt allowed making 
some (non-exceptional) progress.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521937&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 16:51:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 08:51:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-513683 ] email.Parser uses LF as line sep.
Message-ID: <E16luvP-0002aM-00@usw-sf-web3.sourceforge.net>

Bugs item #513683, was opened at 2002-02-06 04:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513683&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Brian Takashi Hooper (bthooper)
Assigned to: Barry Warsaw (bwarsaw)
Summary: email.Parser uses LF as line sep.

Initial Comment:
I'm not sure what the best solution is for this, but some email 
clients sent multipart MIME messages using CRLF as the line 
separator instead of just LF, which seems to be assumed in 
email.Parser.Parser._parsebody. Maybe I'm reading the RFC 
wrong, but it seems like it says that lines of a mail message should be 
separated using CRLF (although I'm sure many clients don't do that 
either)...


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-15 11:51

Message:
Logged In: YES 
user_id=12800

Closing this as Won't Fix because the email package's
philosophy is to process messages uses native line endings.
 Any conversions to/from RFC line endings must happen
outside the package (e.g. by the delivering MTA, or by
smtplib for outgoing mail).

----------------------------------------------------------------------

Comment By: Brian Takashi Hooper (bthooper)
Date: 2002-02-06 09:41

Message:
Logged In: YES 
user_id=450505

OK, that seems like a satisfactory answer.
I do actually happen to be 
using Postfix on FreeBSD, albeit a little old (maybe a year or so), and am 
piping mails to a Python script, which is where I observed this problem. 
Maybe something with my local setup? (I didn't set up Postfix, but I don't 
see why it wouldn't be doing the default thing)

Maybe it would be safer 
not to make assumptions about the input message, and process line endings 
to native before parsing? This would be my vote anyways (I tend to avoid 
thoroughly reading documentation unless something doesn't work as I 
intuit it should :-)


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-02-06 07:32

Message:
Logged In: YES 
user_id=12800

My philosophy so far (and I *think* this is documented in
the latest rev of the .tex file), is that the email package
should deal with native line endings, and that it is the job
of a delivering mta to convert from rfc line endings (crlf)
to native.  It is certainly the case that smtplib converts
from native to rfc line endings when sending the message
out.  Most mtas (e.g. postfix) when piping the message to a
process or onto a file will convert to native line endings,
at least in my experience.

This may not be a very useful assumption though, and it is
probably more robust to be able to deal with either line
endings.  There have been some movements in this direction
in the cvs snapshot of the mimelib/email package where
support for multibyte charsets (e.g. Japanese) have been
added.  You might want to check out that project's cvs trunk
and see if it helps your situation, or submit a bug report
there and we'll prototype the fix in that project first. 
Eventually all that code will be ported back to the Python
2.3 tree.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513683&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 17:39:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 09:39:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lvg8-0001RO-00@usw-sf-web1.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 18:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 16:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 01:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 01:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 17:50:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 09:50:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16lvqW-0003GL-00@usw-sf-web3.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 13:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 18:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 18:05:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 10:05:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16lw5U-0001kQ-00@usw-sf-web1.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 13:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 18:14:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 10:14:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lwDc-0005l2-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-15 13:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 10:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 04:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 18:27:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 10:27:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lwQ9-000207-00@usw-sf-web1.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 13:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 13:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 10:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 04:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 18:42:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 10:42:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lwek-0002Au-00@usw-sf-web1.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 19:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. Löwis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 19:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 19:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 18:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 16:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 01:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 01:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 18:55:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 10:55:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16lwrM-0003yz-00@usw-sf-web3.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 13:55

Message:
Logged In: YES 
user_id=6380

Indeed, but that's a different problem worthy of a separate
bug report. It happens in the unpatched code too, so I don't
think it is a result of my patch -- it just so happens that
your patch also addressed this. But I believe getdoc()
should work for Unicode strings just fine.

I've uploaded inspect3.txt which addresses a different
cosmetic issue but is otherwise the same as inspect2.txt.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 13:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. Löwis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 13:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 13:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 10:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 04:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Fri Mar 15 23:22:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 15:22:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-523117 ] ref.ps and ref.pdf formatting
Message-ID: <E16m11v-0004rD-00@usw-sf-web1.sourceforge.net>

Bugs item #523117, was opened at 2002-02-26 15:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 8
Submitted By: David R Young (youngdr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref.ps and ref.pdf formatting

Initial Comment:
I have noticed what seems to be a formatting problem in both ref.ps (when 
viewed with GSview 4.1) and ref.pdf (when viewed with Acrobat 5.0.5). One 
example is on page 33 in section 5.3.4. The text of the modified BNF 
grammar notation for a rule seems to be much too long to fit on one line. 
Since it is not wrapped, a lot of the rule is not printed.

They are the files from pdf-letter-2.2.zip and postscript-letter-2.2.zip.

They are from 2001/December/21.



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-15 18:22

Message:
Logged In: YES 
user_id=3066

Fixed in time for the 2.2.1 release candidate:
Doc/perl/python.perl  1.116.4.2
Doc/ref/ref2.tex  1.34.6.1
Doc/ref/ref5.tex  1.53.4.1
Doc/ref/ref6.tex  1.47.4.1
Doc/ref/ref7.tex  1.29.8.3
Doc/ref/refa1.tex  1.9.8.2
Doc/texinputs/python.sty  1.88.4.1

Also on the development trunk:
Doc/perl/python.perl  1.118
Doc/ref/ref2.tex  1.35
Doc/ref/ref5.tex  1.54
Doc/ref/ref6.tex  1.48
Doc/ref/ref7.tex  1.32
Doc/ref/refa1.tex  1.11
Doc/texinputs/python.sty  1.89


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-14 11:58

Message:
Logged In: YES 
user_id=6656

Setting group.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-14 09:44

Message:
Logged In: YES 
user_id=3066

This bug exists in both the 2.2 branch and the trunk.  It
should be considered a high-priority bug, especially for 2.2.1.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523117&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 06:26:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 22:26:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-529708 ] error in re docs or in sre
Message-ID: <E16m7eL-0004Kf-00@usw-sf-web2.sourceforge.net>

Bugs item #529708, was opened at 2002-03-13 20:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Wolfson (rumjuggler)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: error in re docs or in sre

Initial Comment:
The docs for positive lookbehind assertions state that
"(?<=abc)def will match "abcdef", since the lookbehind
will back up 3 characters and check if the contained
pattern matches", but that doesn't gibe with experience:

>>> import re
>>> f = re.compile('(?<=abc)def')
>>> print f.match('abcdef')
None
>>> 

I don't know enough about REs to know if this is a
documentation error or an sre error, though.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-16 01:26

Message:
Logged In: YES 
user_id=3066

Added clarifications and examples in Doc/lib/libre.tex
revisions 1.78, 1.73.6.3, and 1.60.2.4.

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-14 01:50

Message:
Logged In: YES 
user_id=38376

the documentation is confused.  <= means that the
pattern following the assertion ("def") will only
match if preceeded by the assertion ("abc").

>>> re.search("(?<=abc)def", "abcdef").group(0)
'def'

>>> re.search("(?<=abc)...", "abcdef").group(0)
'def'

>>> re.search("(?<=c)\w", "abcdef").group(0)
'd'


here's a slighty better example: match words, but
only if they're preceeded with a hyphen:

>>> re.search("(?<=-)\w+", "spam -egg").group(0)
'egg'


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 01:42

Message:
Logged In: YES 
user_id=31435

Changed to Docs and reassigned to Fred.  Reassign to /F if 
it will help.

The example works fine (and matches 'def') if .search() is 
used instead of .match().  It shouldn't match if .match() 
is used (and doesn't).  This is a confusion due to the 
reader mistaking the word "match" used to describe that the 
regexp, well, *matches* <wink>, with the method named "match
()" that merely constrains the match to begin at the start 
of the string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529708&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 06:36:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 15 Mar 2002 22:36:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-520959 ] ref.pdf dictionary display doc error
Message-ID: <E16m7nR-0004Qt-00@usw-sf-web2.sourceforge.net>

Bugs item #520959, was opened at 2002-02-21 08:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520959&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ray Foulkes (rfoulkes)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref.pdf dictionary display doc error

Initial Comment:
In Python Reference Manual Release 2.2 dated december 21 2001, ref.pdf in pdf-a4-2.2.zip
I think

5.2.5 Dictionary displays
A dictionary display is a possibly empty series of key/datum pairs enclosed in curly braces:
dict display ::= "" [key datum list] ""
key datum list ::= key datum ("," key datum)* [","]
key datum ::= expression ":" expression

Should read

5.2.5 Dictionary displays
A dictionary display is a possibly empty series of key/datum pairs enclosed in curly braces:
dict display ::= "{" [key datum list] "}"
key datum list ::= key datum ("," key datum)* [","]
key datum ::= expression ":" expression

i.e. the curly braces vanished when looking at it using Acrobat reader 5.0

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-16 01:36

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/ref/ref5.tex revisions 1.53.4.2 and 1.55.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520959&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 08:22:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 00:22:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-522682 ] pydoc: HTML not escaped
Message-ID: <E16m9SI-0001ar-00@usw-sf-web1.sourceforge.net>

Bugs item #522682, was opened at 2002-02-25 22:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522682&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc: HTML not escaped

Initial Comment:
In the part 'Data and non-method functions', the 
variables are not escaped for HTML. I discovered this 
while looking at pyweblib.forms[1], which uses some 
HTML like <form>, <input>, etc. in it's docstrings. 
Also, \n isn't replaced by <br>.

I'm not sure what the new behavior should be, but I do 
know that this is quite ugly to see(and it can break 
all of the layout, with a nicely placed </table>).

[1]
http://www.stroeder.com/pylib/PyWebLib/pydoc/pyweblib.f
orms.html

----------------------------------------------------------------------

>Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2002-03-16 08:22

Message:
Logged In: YES 
user_id=469548

It was fixed in that version, thanks!

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 18:47

Message:
Logged In: YES 
user_id=11375

It looks like this bug was fixed by a recent checkin (rev.
1.58 of pydoc.py).  Can you please grab a copy of pydoc.py
from the current CVS and see if the problem is fixed?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522682&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 09:49:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 01:49:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-530637 ] Popen3 might cause dead lock
Message-ID: <E16mAoa-00071J-00@usw-sf-web4.sourceforge.net>

Bugs item #530637, was opened at 2002-03-16 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Popen3 might cause dead lock

Initial Comment:
Please include a hint in the documentation of popen3
that it can produce a dead lock.

Example:

The subprocess writes a lot of data to stderr and
blocks and your application reads from stdout. It
might result in a dead lock

An other explanation to this can be found here:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Unfortunately popen3 is documented twice. Would be nice
if there is a
hint to deadlocks at both places. I am programming
quite long and I
lost hours debugging why this happens sometimes and
sometimes not. (It
only happens if you have a lot of output)

In the documentation of Perl there is a hint
to this problem, too.

thomas

(I already submitted this feature request to
python-docs@python.org. But received no response)









----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530637&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 10:49:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 02:49:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-448951 ] Bug in re group handling
Message-ID: <E16mBkk-00033S-00@usw-sf-web1.sourceforge.net>

Bugs item #448951, was opened at 2001-08-08 02: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: Closed
>Resolution: Fixed
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: Just van Rossum (jvr)
Date: 2002-03-16 11:49

Message:
Logged In: YES 
user_id=92689

Yep, works for me. Apparently fixed by patch #468169, 
which /F accepted. I've closed this one.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-10 02:53

Message:
Logged In: YES 
user_id=44345

This looks like another item that works in current CVS.
I get "None" for group(1) in the 0# case. -skip


----------------------------------------------------------------------

Comment By: Matthew Mueller (donut)
Date: 2001-10-05 06:39

Message:
Logged In: YES 
user_id=65253

I posted a fix as patch #468169 since I don't seem to have
access to add it here.


----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2001-08-30 18: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  Sat Mar 16 16:18:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 08:18:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-522274 ] tokenizer.py STARSTAR doesn't exist
Message-ID: <E16mGsa-0008CN-00@usw-sf-web3.sourceforge.net>

Bugs item #522274, was opened at 2002-02-24 18:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Evelyn Mitchell (efm)
Assigned to: Nobody/Anonymous (nobody)
Summary: tokenizer.py STARSTAR doesn't exist

Initial Comment:
pyChecker complains at line 774 of tokenizer.py
No module attribute (STARSTAR) found

The section is:

                if i < len(nodelist):
                    # should be DOUBLESTAR or STAR STAR
                    t = nodelist[i][0]
                    if t == token.DOUBLESTAR:
                        node = nodelist[i+1]
                    elif t == token.STARSTAR:
                        node = nodelist[i+2]
                    else:
                        raise ValueError, "unexpected
token: %s" % t
                    names.append(node[1])
                    flags = flags | CO_VARKEYWORDS

I've verified that there is no STARSTAR in token.py.
I'd patch this to be token.STAR, which does exist, but
this module has no self tests or unit tests, so I
wouldn't be able to know if it broke anything.

My wild guess is that the intention is to refer to two
STAR tokens rather than a DOUBLESTAR token (and that is
because the increment is 2 rather than 1), but I think
that evidence is pretty slim.

----------------------------------------------------------------------

>Comment By: Evelyn Mitchell (efm)
Date: 2002-03-16 09:18

Message:
Logged In: YES 
user_id=13263

Sorry, too much caffine. 

The file is compiler/transformer.py

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-10 11:48

Message:
Logged In: YES 
user_id=92689

I don't see a file "tokenizer.py" in the repository, only 
"tokenize.py", which only has 262 lines. What is this 
bug about?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 17:37:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 09:37:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-528132 ] classmethod().__get__() segfault
Message-ID: <E16mI7O-0002uN-00@usw-sf-web2.sourceforge.net>

Bugs item #528132, was opened at 2002-03-10 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470

Category: Type/class unification
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: classmethod().__get__() segfault

Initial Comment:
Calling the __get__ method of a classmethod object 
with a single argument causes a segmentation fault in 
the interpreter :

  def f(): pass
  classmethod(f).__get__(0)

This is caused by an internal inconsistency between 
the __get__ wrapper function in C that calls the 
tp_descr_get slot with a NULL third argument in this 
case and some tp_descr_get slot implementations (like 
the classmethods') which dereference it with no check.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:37

Message:
Logged In: YES 
user_id=6656

Oopsie, we'll have this one fixed for 2.2.1.

I think you mangaged to submit this bug during a time when
bug email was somewhat hosed...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 17:40:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 09:40:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-513033 ] unsafe call to PyThreadState_Swap
Message-ID: <E16mIA5-0007YA-00@usw-sf-web1.sourceforge.net>

Bugs item #513033, was opened at 2002-02-04 23:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jake McGuire (jamcguir)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unsafe call to PyThreadState_Swap

Initial Comment:
It appears that there is a blatantly unsafe call to 
PyThreadState_Swap in the functions on_hook and 
on_completer in Modules/Readline.c

The diff adding these calls is viewable at 
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/python/python/dist/src/Modules/readline
.c.diff?r1=2.5&r2=2.6&only_with_tag=MAIN

The call to PyThreadState_Swap is added directly below 
a comment pointing out that readline() is called with 
the interpreter lock released.  Viewing the code shows 
that the interpreter lock is indeed released before 
calling readline (in myreadline.c).

Multithreaded programs that define callback functions 
suffer from intermittent crashes, often Py_FatalError-
ing claiming "tstate mix-up" from ceval.c

Removing the calls to PyThreadState_Swap makes these 
problems go away.

Can someone explain how the call to PyThreadState_Swap 
is indeed the right thing to be doing?

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:40

Message:
Logged In: YES 
user_id=6656

jamcguir (or indeed anyone else), can you provide a patch
for this pronto?  I'd kind of like to have it fixed in
2.2.1, but this is obscure enough that I'm not going to hold
up the release for it.

----------------------------------------------------------------------

Comment By: Jake McGuire (jamcguir)
Date: 2002-02-04 23:55

Message:
Logged In: YES 
user_id=448911

Unfortunately, the scenario isn't really *simple*.

I think it goes like this:

Thread A defines a readline startup hook.
Thread A calls PyOS_Readline() in myreadline.c
Thread A calls Py_BEGIN_ALLOW_THREADS, saving its thread 
state and setting the global thread state to NULL.
Thread A calls readline.
Thread A gets blocked, and Thread B gets scheduled.
Thread B grabs the global interpreter lock, and restores 
its thread state.
Thread B gets suspended, and Thread A gets scheduled.
-- note: Thread B has the intepreter lock --
Thread A calls PyThreadState_Swap in on_hook(), setting the 
current global thread state to NULL
Thread A calls PyEval_RestoreThread, which blocks waiting 
for the global interpreter lock
Thread B gets scheduled, tries to run, but finds that the 
global thread state is NULL.  Bad things happen.

Proposed solution:
Change Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in 
myreadline.c:PyOS_Readline to calls to PyEval_SaveThread 
and PyEval_RestoreThread.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-04 23:41

Message:
Logged In: YES 
user_id=31435

Guido's checkin comment said:

"""
Darn.  When thread support is disabled, the BEGIN/END 
macros don't save and restore the tstate, but explicitly 
calling PyEval_SaveThread() does reset it!  While I think 
about how to fix this for real, here's a fix that avoids 
getting a fatal error.
"""

Therefore I assigned the bug to Guido <wink>.  It would 
help if you could describe a specific simple scenario that 
provokes the problems you're seeing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 17:43:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 09:43:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mICv-0007aE-00@usw-sf-web1.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 20:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 19:21:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 11:21:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-522274 ] compiler/transformer.py STARSTAR doesn't exist
Message-ID: <E16mJkb-0001fn-00@usw-sf-web3.sourceforge.net>

Bugs item #522274, was opened at 2002-02-24 20:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Evelyn Mitchell (efm)
>Assigned to: Jeremy Hylton (jhylton)
>Summary: compiler/transformer.py STARSTAR doesn't exist

Initial Comment:
pyChecker complains at line 774 of tokenizer.py
No module attribute (STARSTAR) found

The section is:

                if i < len(nodelist):
                    # should be DOUBLESTAR or STAR STAR
                    t = nodelist[i][0]
                    if t == token.DOUBLESTAR:
                        node = nodelist[i+1]
                    elif t == token.STARSTAR:
                        node = nodelist[i+2]
                    else:
                        raise ValueError, "unexpected
token: %s" % t
                    names.append(node[1])
                    flags = flags | CO_VARKEYWORDS

I've verified that there is no STARSTAR in token.py.
I'd patch this to be token.STAR, which does exist, but
this module has no self tests or unit tests, so I
wouldn't be able to know if it broke anything.

My wild guess is that the intention is to refer to two
STAR tokens rather than a DOUBLESTAR token (and that is
because the increment is 2 rather than 1), but I think
that evidence is pretty slim.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 14:21

Message:
Logged In: YES 
user_id=6380

I think the STARSTAR should be STAR.  Jeremy, can you
confirm & fix? Also, there needs to be a unittest for this
code, apparently!

----------------------------------------------------------------------

Comment By: Evelyn Mitchell (efm)
Date: 2002-03-16 11:18

Message:
Logged In: YES 
user_id=13263

Sorry, too much caffine. 

The file is compiler/transformer.py

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-10 13:48

Message:
Logged In: YES 
user_id=92689

I don't see a file "tokenizer.py" in the repository, only 
"tokenize.py", which only has 262 lines. What is this 
bug about?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 20:30:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 12:30:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-522682 ] pydoc: HTML not escaped
Message-ID: <E16mKp2-00010v-00@usw-sf-web1.sourceforge.net>

Bugs item #522682, was opened at 2002-02-25 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522682&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Johannes Gijsbers (jlgijsbers)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc: HTML not escaped

Initial Comment:
In the part 'Data and non-method functions', the 
variables are not escaped for HTML. I discovered this 
while looking at pyweblib.forms[1], which uses some 
HTML like <form>, <input>, etc. in it's docstrings. 
Also, \n isn't replaced by <br>.

I'm not sure what the new behavior should be, but I do 
know that this is quite ugly to see(and it can break 
all of the layout, with a nicely placed </table>).

[1]
http://www.stroeder.com/pylib/PyWebLib/pydoc/pyweblib.f
orms.html

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-16 15:30

Message:
Logged In: YES 
user_id=11375

OK; I'll close this bug.  Thanks for your report!


----------------------------------------------------------------------

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2002-03-16 03:22

Message:
Logged In: YES 
user_id=469548

It was fixed in that version, thanks!

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 13:47

Message:
Logged In: YES 
user_id=11375

It looks like this bug was fixed by a recent checkin (rev.
1.58 of pydoc.py).  Can you please grab a copy of pydoc.py
from the current CVS and see if the problem is fixed?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522682&group_id=5470


From noreply@sourceforge.net  Sat Mar 16 20:36:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 12:36:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16mKv6-00015Q-00@usw-sf-web1.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
>Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-16 15:36

Message:
Logged In: YES 
user_id=11375

The asyncore.py in 2.1.1 seems to be revision 1.10 of 
the file; it's rev. 1.28 in 2.2 and is now at 1.30, so 
there have been a number of changes to asyncore, though 
none seem relevant.  Did you try your code on 2.2 with 
the 2.1.1
asyncore?  That would let us figure out if it's due to 
a change in asyncore or the underlying socket or select
module.

(Actually, another thing to check is whether the select 
or the poll module is being used; maybe that changed 
for you between 2.1.1 and 2.2.)



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-14 21:52

Message:
Logged In: YES 
user_id=482117

My question then is why didn't it do this when I ran my app
with python 2.1.1. Something has changed in 2.2 and I don't
think it was asyncore, I do know some work was done to the
low level socket and select modules so they could handle
IPV6. I understand why the None is being returned, but an
accept shouldn't even be called on a write event coming from
a select or poll.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
Logged In: YES 
user_id=11375

Looking at the implementation of accept() in asyncore.py, it will 
return 
None when the socket is in non-blocking mode and the accept() would block.  
There's really nothing else accept() could
return in this case, so you'll 
probably have to write your code to 
handle this case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 05:46:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 21:46:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-530882 ] import and execfile don't handle utf-16
Message-ID: <E16mTVQ-0002j4-00@usw-sf-web4.sourceforge.net>

Bugs item #530882, was opened at 2002-03-17 05:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terrel Shumway (terrelshumway)
Assigned to: Nobody/Anonymous (nobody)
Summary: import and execfile don't handle utf-16

Initial Comment:
import and execfile don't handle utf-16 encoded files,
but if I read the file with an appropriate encoder, 
exec works fine on the loaded uncode string.

Also, changing site.encoding to utf-16 has a 
detrimental effect. (I need to understand this better.)

I understand that the general problem is difficult to 
solve, but it seems it would be fairly easy to handle 
for the specific case of utf-16 file with some byte 
order mark at the begining: if import/execfile fail 
and the file starts with some BOM, re-read the file 
with an appropriate codec.


Use this code to reproduce the problem
--------------
import sys
print sys.getdefaultencoding()

code = u'print "this is a test: OK"'

import traceback
import codecs

codecs.open("foo.py","w+","utf-16").write(code)

try:
    execfile("foo.py")
except:
    traceback.print_exc()

try:
    import foo
except:
    traceback.print_exc()


uu = codecs.open("foo.py","r","utf-16").read()

exec(uu)
--------------
produces this output
--------------
ascii
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 12, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 17, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
this is a test: OK

--------------
If I edit site.py to change encoding to "utf-16", I get
--------------
utf-16
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 15, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 20, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 27, in ?
    exec(uu)
TypeError: expected string without null bytes
----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 05:52:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 21:52:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-530882 ] import and execfile don't handle utf-16
Message-ID: <E16mTaO-0006mi-00@usw-sf-web1.sourceforge.net>

Bugs item #530882, was opened at 2002-03-17 05:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470

>Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terrel Shumway (terrelshumway)
Assigned to: Nobody/Anonymous (nobody)
Summary: import and execfile don't handle utf-16

Initial Comment:
import and execfile don't handle utf-16 encoded files,
but if I read the file with an appropriate encoder, 
exec works fine on the loaded uncode string.

Also, changing site.encoding to utf-16 has a 
detrimental effect. (I need to understand this better.)

I understand that the general problem is difficult to 
solve, but it seems it would be fairly easy to handle 
for the specific case of utf-16 file with some byte 
order mark at the begining: if import/execfile fail 
and the file starts with some BOM, re-read the file 
with an appropriate codec.


Use this code to reproduce the problem
--------------
import sys
print sys.getdefaultencoding()

code = u'print "this is a test: OK"'

import traceback
import codecs

codecs.open("foo.py","w+","utf-16").write(code)

try:
    execfile("foo.py")
except:
    traceback.print_exc()

try:
    import foo
except:
    traceback.print_exc()


uu = codecs.open("foo.py","r","utf-16").read()

exec(uu)
--------------
produces this output
--------------
ascii
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 12, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 17, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
this is a test: OK

--------------
If I edit site.py to change encoding to "utf-16", I get
--------------
utf-16
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 15, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 20, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 27, in ?
    exec(uu)
TypeError: expected string without null bytes
----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 05:53:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 16 Mar 2002 21:53:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-530882 ] import and execfile don't handle utf-16
Message-ID: <E16mTbn-0002nC-00@usw-sf-web4.sourceforge.net>

Bugs item #530882, was opened at 2002-03-17 05:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470

>Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Terrel Shumway (terrelshumway)
Assigned to: Nobody/Anonymous (nobody)
Summary: import and execfile don't handle utf-16

Initial Comment:
import and execfile don't handle utf-16 encoded files,
but if I read the file with an appropriate encoder, 
exec works fine on the loaded uncode string.

Also, changing site.encoding to utf-16 has a 
detrimental effect. (I need to understand this better.)

I understand that the general problem is difficult to 
solve, but it seems it would be fairly easy to handle 
for the specific case of utf-16 file with some byte 
order mark at the begining: if import/execfile fail 
and the file starts with some BOM, re-read the file 
with an appropriate codec.


Use this code to reproduce the problem
--------------
import sys
print sys.getdefaultencoding()

code = u'print "this is a test: OK"'

import traceback
import codecs

codecs.open("foo.py","w+","utf-16").write(code)

try:
    execfile("foo.py")
except:
    traceback.print_exc()

try:
    import foo
except:
    traceback.print_exc()


uu = codecs.open("foo.py","r","utf-16").read()

exec(uu)
--------------
produces this output
--------------
ascii
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 12, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 17, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
this is a test: OK

--------------
If I edit site.py to change encoding to "utf-16", I get
--------------
utf-16
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 15, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 20, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 27, in ?
    exec(uu)
TypeError: expected string without null bytes
----


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 17:33:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 09:33:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-530882 ] import and execfile don't handle utf-16
Message-ID: <E16meWw-0003Ze-00@usw-sf-web4.sourceforge.net>

Bugs item #530882, was opened at 2002-03-17 06:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470

Category: Unicode
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Terrel Shumway (terrelshumway)
Assigned to: Nobody/Anonymous (nobody)
Summary: import and execfile don't handle utf-16

Initial Comment:
import and execfile don't handle utf-16 encoded files,
but if I read the file with an appropriate encoder, 
exec works fine on the loaded uncode string.

Also, changing site.encoding to utf-16 has a 
detrimental effect. (I need to understand this better.)

I understand that the general problem is difficult to 
solve, but it seems it would be fairly easy to handle 
for the specific case of utf-16 file with some byte 
order mark at the begining: if import/execfile fail 
and the file starts with some BOM, re-read the file 
with an appropriate codec.


Use this code to reproduce the problem
--------------
import sys
print sys.getdefaultencoding()

code = u'print "this is a test: OK"'

import traceback
import codecs

codecs.open("foo.py","w+","utf-16").write(code)

try:
    execfile("foo.py")
except:
    traceback.print_exc()

try:
    import foo
except:
    traceback.print_exc()


uu = codecs.open("foo.py","r","utf-16").read()

exec(uu)
--------------
produces this output
--------------
ascii
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 12, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 17, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
this is a test: OK

--------------
If I edit site.py to change encoding to "utf-16", I get
--------------
utf-16
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 15, in ?
    execfile("foo.py")
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 20, in ?
    import foo
  File "<string>", line 1
      &#9632;p
     ^
 SyntaxError: invalid syntax
Traceback (most recent call last):
  File "C:\opt\unicode-exec.py", line 27, in ?
    exec(uu)
TypeError: expected string without null bytes
----


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 18:33

Message:
Logged In: YES 
user_id=21627

This is not a bug. The language reference clearly says, in

http://www.python.org/doc/current/ref/lexical.html

"Python uses the 7-bit ASCII character set for program text
and string literals."

PEP 263 (if accepted) will extend this to other encodings.
However, UTF-16 is not in the list of encodings supported
under this PEP, as it is not an ASCII superset.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530882&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 19:00:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 11:00:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16mftf-0004Xg-00@usw-sf-web4.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 17:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-17 14:00

Message:
Logged In: YES 
user_id=31435

I applied type2.txt and inspect3.txt to the trunk and to 
release22-maint.  If you believe there are other bugs here 
that need fixing day, please open new bug reports.

Lib/inspect.py
    new revision: 1.28
    new revision: 1.26.10.2
Objects/typeobject.c
    new revision: 2.130
    new revision: 2.126.4.4

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 13:55

Message:
Logged In: YES 
user_id=6380

Indeed, but that's a different problem worthy of a separate
bug report. It happens in the unpatched code too, so I don't
think it is a result of my patch -- it just so happens that
your patch also addressed this. But I believe getdoc()
should work for Unicode strings just fine.

I've uploaded inspect3.txt which addresses a different
cosmetic issue but is otherwise the same as inspect2.txt.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 13:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. Löwis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 13:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 13:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 10:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 04:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-14 19:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 19:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 20:11:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 12:11:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-528132 ] classmethod().__get__() segfault
Message-ID: <E16mgzo-0000zX-00@usw-sf-web1.sourceforge.net>

Bugs item #528132, was opened at 2002-03-10 15:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: classmethod().__get__() segfault

Initial Comment:
Calling the __get__ method of a classmethod object 
with a single argument causes a segmentation fault in 
the interpreter :

  def f(): pass
  classmethod(f).__get__(0)

This is caused by an internal inconsistency between 
the __get__ wrapper function in C that calls the 
tp_descr_get slot with a NULL third argument in this 
case and some tp_descr_get slot implementations (like 
the classmethods') which dereference it with no check.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-17 20:11

Message:
Logged In: YES 
user_id=6656

Guido, is this fix sane?

No other implementation of tp_descr_get seems to be at risk.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:37

Message:
Logged In: YES 
user_id=6656

Oopsie, we'll have this one fixed for 2.2.1.

I think you mangaged to submit this bug during a time when
bug email was somewhat hosed...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 20:54:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 12:54:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mhfI-0001U8-00@usw-sf-web1.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 20:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 21:27:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 13:27:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-529146 ] ICGlue byte alignment issue
Message-ID: <E16miBT-0006Aq-00@usw-sf-web4.sourceforge.net>

Bugs item #529146, was opened at 2002-03-12 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: ICGlue byte alignment issue

Initial Comment:
When using IC to read the Internet Configuration data (from Internet Control Panel), the type and creator codes appear to be misaligned.

For example, with the JPG entry, I receive back:

"EGog" & "le  ", instead of the proper: "JPEG" &"ogle" entries.....



----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-17 22:27

Message:
Logged In: YES 
user_id=45365

This was fixed in 1.8 on the trunk, 1.7.6.1 on the 221 branch. The problem was a header/library mismatch.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-13 00:12

Message:
Logged In: YES 
user_id=45365

Raised the priority and put this in the 221 candidate group to make sure I don't forget to fix this before 2.2.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529146&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 21:29:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 13:29:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-505587 ] Fix hardlink against NavServices
Message-ID: <E16miDC-0006CT-00@usw-sf-web4.sourceforge.net>

Bugs item #505587, was opened at 2002-01-19 00:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505587&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Fix hardlink against NavServices

Initial Comment:
PPC PythonCore 2.2 apparently hardlinks against NavigationServices, which is not part of standard MacOS 8.1. Most people have it, but not all.

Reported by Brian Benjamin <brianb@inow.com>, who might also be willing to test a 2.2.1 fix.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-17 22:29

Message:
Logged In: YES 
user_id=45365

Although the fix hasn't been test yet (I don't have access to 8.1) I'll close it anyway and have someone test the fix with 221c1. I'll reopen the bug if it turns out it wasn't fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505587&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 22:08:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 14:08:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mip0-0006AX-00@usw-sf-web2.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 23:08

Message:
Logged In: YES 
user_id=21627

This falls in the "doctor, it hurts when I do this"
category, and it is not a regression over 2.1.x, so I don't
think it is critical to fix for 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 18:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 22:10:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 14:10:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16miqr-0002Ow-00@usw-sf-web1.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 13:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 23:10

Message:
Logged In: YES 
user_id=38376

as neal points out, the 3rd define (after the #endif)
should be removed.

(my CVS workspace is broken right now, so I cannot
patch this myself -- at least not tonight...)

</F>

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 19:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 18:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 22:10:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 14:10:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-528132 ] classmethod().__get__() segfault
Message-ID: <E16miri-0002PE-00@usw-sf-web1.sourceforge.net>

Bugs item #528132, was opened at 2002-03-10 10:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: classmethod().__get__() segfault

Initial Comment:
Calling the __get__ method of a classmethod object 
with a single argument causes a segmentation fault in 
the interpreter :

  def f(): pass
  classmethod(f).__get__(0)

This is caused by an internal inconsistency between 
the __get__ wrapper function in C that calls the 
tp_descr_get slot with a NULL third argument in this 
case and some tp_descr_get slot implementations (like 
the classmethods') which dereference it with no check.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 17:10

Message:
Logged In: YES 
user_id=6380

Alas, it looks I can still force a segfault by calling the
resulting unbound method with a bogus argument. I'll look
into this now.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-17 15:11

Message:
Logged In: YES 
user_id=6656

Guido, is this fix sane?

No other implementation of tp_descr_get seems to be at risk.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 12:37

Message:
Logged In: YES 
user_id=6656

Oopsie, we'll have this one fixed for 2.2.1.

I think you mangaged to submit this bug during a time when
bug email was somewhat hosed...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 22:44:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 14:44:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mjOO-0006ZQ-00@usw-sf-web2.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Walter Dörwald (doerwalter)
Assigned to: M.-A. Lemburg (lemburg)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 23:44

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the two bugs.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 23:08

Message:
Logged In: YES 
user_id=21627

This falls in the "doctor, it hurts when I do this"
category, and it is not a regression over 2.1.x, so I don't
think it is critical to fix for 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 18:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:06:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:06:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-482460 ] dumbdbm fails to overwrite existing key
Message-ID: <E16mjjT-0004NS-00@usw-sf-web3.sourceforge.net>

Bugs item #482460, was opened at 2001-11-16 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
Resolution: None
Priority: 4
Submitted By: Michael McCandless (mikemccand)
Assigned to: Skip Montanaro (montanaro)
Summary: dumbdbm fails to overwrite existing key

Initial Comment:

Here's a simple test case that shows the bug:

  import dumbdbm

  db = dumbdbm.open('db', 'c')
  db['1'] = 'hello'
  db['1'] = 'hello2'
  db.close()

  db = dumbdbm.open('db', 'c')
  print db['1']
  db.close()

This prints out 'hello' but should print out 'hello2'.  As far as I can tell, this bug did not exist 1.5.2, 
but then appeared in 2.0 and is still present  in 2.2b1.

The problem is, when overwriting the key, dumbdbm fails to update the .dir file.  I believe this 
patch fixes the bug:

> diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new 
*** Lib/dumbdbm.py      Tue Sep  4 15:14:13 2001
--- Lib/dumbdbm.py.new  Fri Nov 16 08:16:42 2001
***************
*** 124,129 ****
--- 124,132 ----
              else:
                  pos, siz = self._addval(val)
                  self._index[key] = pos, siz
+             tup = (pos, siz)
+             if self._index[key] != tup:
+                 self._addkey(key, tup)

      def __delitem__(self, key):
          del self._index[key]




----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-17 17:06

Message:
Logged In: YES 
user_id=44345

v 1.16 fixes this bug by calling _commit() when the file
is closed.

added test case to test_dumbdbm.py and verified that it
does fail using Python 2.1 and succeeds with current CVS


----------------------------------------------------------------------

Comment By: Michael McCandless (mikemccand)
Date: 2001-12-06 15:12

Message:
Logged In: YES 
user_id=323786


Please note that this bug is not just a performance issue -- dumbdbm fails to save data for certain keys, 
even when it's used entirely normally.  The different proposed fixes, however, have different performance 
characteristics ...

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 14:47

Message:
Logged In: YES 
user_id=3066

Assigned to Skip since he's shown an interest.  ;-)  Just
use your judgement, Skip; I've lowered the priority since
performance and space savings just aren't important for dumbdbm.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-11-16 10:16

Message:
Logged In: YES 
user_id=44345

Performance isn't a big issue with dumbdbm, so I think the
code should be as simple as possible.  I have a local
version I was working on a bit.  I simply delete then 
add in __setitem__:

    def __setitem__(self, key, val):
       if not type(key) == type('') == type(val):
            raise TypeError, "keys and values must be strings"
        if self._index.has_key(key):
            del self[key]
            
        (pos, siz) = self._addval(val)
        self._addkey(key, (pos, siz))

I also have code in my local version to reuse space
though.  I also want to add file locking (which is
the motivation for me to be fiddling with this
stuff).



----------------------------------------------------------------------

Comment By: Michael McCandless (mikemccand)
Date: 2001-11-16 07:38

Message:
Logged In: YES 
user_id=323786


Sorry -- that previous patch does not work.  I believe this one does:

> diff -c Lib/dumbdbm.py Lib/dumbdbm.py.new 
*** Lib/dumbdbm.py      Fri Nov 16 08:36:36 2001
--- Lib/dumbdbm.py.new  Fri Nov 16 08:36:50 2001
***************
*** 116,121 ****
--- 116,122 ----
              self._addkey(key, (pos, siz))
          else:
              pos, siz = self._index[key]
+             startTup = (pos, siz)
              oldblocks = (siz + _BLOCKSIZE - 1) / _BLOCKSIZE
              newblocks = (len(val) + _BLOCKSIZE - 1) / _BLOCKSIZE
              if newblocks <= oldblocks:
***************
*** 124,129 ****
--- 125,133 ----
              else:
                  pos, siz = self._addval(val)
                  self._index[key] = pos, siz
+             tup = (pos, siz)
+             if startTup != tup:
+                 self._addkey(key, tup)

      def __delitem__(self, key):
          del self._index[key]

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482460&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:08:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:08:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E16mjl1-0007Jq-00@usw-sf-web4.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 06:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
>Assigned to: Skip Montanaro (montanaro)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03:14

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 02:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 09:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 04:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 10:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 12:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 10:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 04:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-30 00:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:08:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:08:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-528132 ] classmethod().__get__() segfault
Message-ID: <E16mjlG-0006qS-00@usw-sf-web2.sourceforge.net>

Bugs item #528132, was opened at 2002-03-10 10:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: classmethod().__get__() segfault

Initial Comment:
Calling the __get__ method of a classmethod object 
with a single argument causes a segmentation fault in 
the interpreter :

  def f(): pass
  classmethod(f).__get__(0)

This is caused by an internal inconsistency between 
the __get__ wrapper function in C that calls the 
tp_descr_get slot with a NULL third argument in this 
case and some tp_descr_get slot implementations (like 
the classmethods') which dereference it with no check.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 18:08

Message:
Logged In: YES 
user_id=6380

Alas, not tonight. Tomorrow morning for sure.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 17:10

Message:
Logged In: YES 
user_id=6380

Alas, it looks I can still force a segfault by calling the
resulting unbound method with a bogus argument. I'll look
into this now.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-17 15:11

Message:
Logged In: YES 
user_id=6656

Guido, is this fix sane?

No other implementation of tp_descr_get seems to be at risk.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 12:37

Message:
Logged In: YES 
user_id=6656

Oopsie, we'll have this one fixed for 2.2.1.

I think you mangaged to submit this bug during a time when
bug email was somewhat hosed...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:14:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:14:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error
Message-ID: <E16mjr3-0004Sl-00@usw-sf-web3.sourceforge.net>

Bugs item #531145, was opened at 2002-03-18 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sslerror is not a socket.error

Initial Comment:
Python 2.1.2 (#1, Mar 16 2002, 00:56:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
>>> socket.sslerror
<class socket.sslerror at 0x809c39c>
>>> try: raise socket.sslerror
... except socket.error: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.sslerror
>>> 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:17:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:17:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-469972 ] xmlrpclib won't marshal new types
Message-ID: <E16mjuP-00038V-00@usw-sf-web1.sourceforge.net>

Bugs item #469972, was opened at 2001-10-10 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=469972&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib won't marshal new types

Initial Comment:
Maybe xmlrpclib should be modified to allow it to marshal subclasses of builtin types (ints, strings, etc).  Here's a simple example that demonstrates that it currently won't work with a subclass of str:

>>> import xmlrpclib
>>> class MyString(str):
...   pass
... 
>>> s = MyString("sdfsdfsdf")
>>> s
'sdfsdfsdf'
>>> s.__class__
<class '__main__.MyString'>
>>> xmlrpclib.dumps((s,))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 752, in dumps
    data = m.dumps(params)
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 448, in dumps
    self.__dump(v)
  File "/usr/local/lib/python2.2/xmlrpclib.py", line 459, in __dump
    raise TypeError, "cannot marshal %s objects" % type(value)
TypeError: cannot marshal <class '__main__.MyString'> objects


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-17 17:17

Message:
Logged In: YES 
user_id=44345

closing this bug report.  Perhaps in the future 
subclasses of builtins could be marshalled, but extra
instance attributes wouldn't be.

libxmlrpclib.tex v 1.8 adds a note about this limitation
as suggested by Andrew.



----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-08 12:33

Message:
Logged In: YES 
user_id=11375

Maybe we should just document that xmlrpclib won't handle 
subclasses?


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-10-19 11:00

Message:
Logged In: YES 
user_id=44345

I don't think #471893 applies here.  While xmlrpclib will marshal the dict of an instance object, it is seen as a marshalled dict at the other end and would be unmarshalled as a dict without special effort on the part of the programmer.  XML-RPC only supports a small, fixed set of types: ints, booleans, floats, date-time strings, lists and dicts.

My concern with allowing XML-RPC marshalling of a subclass of strings (for example), is that the programmer might be led to believe their extra instance attributes would be marshalled as well.  While I submitted this bug report, I was simply recording someone else's observation.


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2001-10-19 09:16

Message:
Logged In: YES 
user_id=72053

1) anything but the base types aren't part of the
xmlrpc spec

2) be very very careful about unmarshalling any but basic
objects, because of possible security attacks.  See
item 471893 for some more info.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=469972&group_id=5470


From noreply@sourceforge.net  Sun Mar 17 23:28:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 15:28:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-505488 ] python-mode.el sets TMPDIR to /usr/tmp
Message-ID: <E16mk50-0007X4-00@usw-sf-web4.sourceforge.net>

Bugs item #505488, was opened at 2002-01-18 12:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode.el sets TMPDIR to /usr/tmp

Initial Comment:
all python versions. Not sure why, but on most systems 
this directory does not exist. Probably should be
/var/tmp ...(variable py-temp-directory).


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-17 17:28

Message:
Logged In: YES 
user_id=44345

proposed patch attached.  Suggest adding /var/tmp ahead
of /usr/tmp.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 03:10:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 19:10:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-528132 ] classmethod().__get__() segfault
Message-ID: <E16mnXe-0000yr-00@usw-sf-web2.sourceforge.net>

Bugs item #528132, was opened at 2002-03-10 10:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: classmethod().__get__() segfault

Initial Comment:
Calling the __get__ method of a classmethod object 
with a single argument causes a segmentation fault in 
the interpreter :

  def f(): pass
  classmethod(f).__get__(0)

This is caused by an internal inconsistency between 
the __get__ wrapper function in C that calls the 
tp_descr_get slot with a NULL third argument in this 
case and some tp_descr_get slot implementations (like 
the classmethods') which dereference it with no check.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 22:10

Message:
Logged In: YES 
user_id=6380

Fixed it, both in 2.2.1 branch and in 2.3 trunk. The "idiot
fix" (not my words) below didn't quite do it, but letting
type default to obj->ob_type does the trick.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 18:08

Message:
Logged In: YES 
user_id=6380

Alas, not tonight. Tomorrow morning for sure.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 17:10

Message:
Logged In: YES 
user_id=6380

Alas, it looks I can still force a segfault by calling the
resulting unbound method with a bogus argument. I'll look
into this now.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-17 15:11

Message:
Logged In: YES 
user_id=6656

Guido, is this fix sane?

No other implementation of tp_descr_get seems to be at risk.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 12:37

Message:
Logged In: YES 
user_id=6656

Oopsie, we'll have this one fixed for 2.2.1.

I think you mangaged to submit this bug during a time when
bug email was somewhat hosed...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528132&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 03:09:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 19:09:59 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-481961 ] Add atoi/atof to string class
Message-ID: <E16mnX5-0000yE-00@usw-sf-web2.sourceforge.net>

Feature Requests item #481961, was opened at 2001-11-14 23:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=481961&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Justin Shaw (justinshaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add atoi/atof to string class

Initial Comment:
Just as you can call split() and strip() either from 
the string module or as a string method, it would be 
nice to be able to to the same for atoi() and atof().

Example:
# Current implementation
numStr = '3.14159'
intStr = '2'
pi     = string.atof(numbStr)
two    = string.atio(intStr)

# Proposed implementation
pi  = '3.14159'.atof()
two = '2'.atoi()

Please keep churning out the great work!
Justin Shaw


----------------------------------------------------------------------

>Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-17 22:09

Message:
Logged In: YES 
user_id=135558

Skip this ... I like int("2") better.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=481961&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 03:15:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 19:15:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-513033 ] unsafe call to PyThreadState_Swap
Message-ID: <E16mnbx-0005ca-00@usw-sf-web1.sourceforge.net>

Bugs item #513033, was opened at 2002-02-04 18:16
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jake McGuire (jamcguir)
Assigned to: Guido van Rossum (gvanrossum)
Summary: unsafe call to PyThreadState_Swap

Initial Comment:
It appears that there is a blatantly unsafe call to 
PyThreadState_Swap in the functions on_hook and 
on_completer in Modules/Readline.c

The diff adding these calls is viewable at 
http://cvs.sourceforge.net/cgi-
bin/viewcvs.cgi/python/python/dist/src/Modules/readline
.c.diff?r1=2.5&r2=2.6&only_with_tag=MAIN

The call to PyThreadState_Swap is added directly below 
a comment pointing out that readline() is called with 
the interpreter lock released.  Viewing the code shows 
that the interpreter lock is indeed released before 
calling readline (in myreadline.c).

Multithreaded programs that define callback functions 
suffer from intermittent crashes, often Py_FatalError-
ing claiming "tstate mix-up" from ceval.c

Removing the calls to PyThreadState_Swap makes these 
problems go away.

Can someone explain how the call to PyThreadState_Swap 
is indeed the right thing to be doing?

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-17 22:15

Message:
Logged In: YES 
user_id=6380

That's ancient history and will take some time to wrap my
brains around. I don't have time for this tonight, maybe
tomorrow but I doubt the priority can be raised enough to
catch my attention long enough to matter. But it should be
fixed for 2.3.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 12:40

Message:
Logged In: YES 
user_id=6656

jamcguir (or indeed anyone else), can you provide a patch
for this pronto?  I'd kind of like to have it fixed in
2.2.1, but this is obscure enough that I'm not going to hold
up the release for it.

----------------------------------------------------------------------

Comment By: Jake McGuire (jamcguir)
Date: 2002-02-04 18:55

Message:
Logged In: YES 
user_id=448911

Unfortunately, the scenario isn't really *simple*.

I think it goes like this:

Thread A defines a readline startup hook.
Thread A calls PyOS_Readline() in myreadline.c
Thread A calls Py_BEGIN_ALLOW_THREADS, saving its thread 
state and setting the global thread state to NULL.
Thread A calls readline.
Thread A gets blocked, and Thread B gets scheduled.
Thread B grabs the global interpreter lock, and restores 
its thread state.
Thread B gets suspended, and Thread A gets scheduled.
-- note: Thread B has the intepreter lock --
Thread A calls PyThreadState_Swap in on_hook(), setting the 
current global thread state to NULL
Thread A calls PyEval_RestoreThread, which blocks waiting 
for the global interpreter lock
Thread B gets scheduled, tries to run, but finds that the 
global thread state is NULL.  Bad things happen.

Proposed solution:
Change Py_BEGIN_ALLOW_THREADS and Py_END_ALLOW_THREADS in 
myreadline.c:PyOS_Readline to calls to PyEval_SaveThread 
and PyEval_RestoreThread.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-04 18:41

Message:
Logged In: YES 
user_id=31435

Guido's checkin comment said:

"""
Darn.  When thread support is disabled, the BEGIN/END 
macros don't save and restore the tstate, but explicitly 
calling PyEval_SaveThread() does reset it!  While I think 
about how to fix this for real, here's a fix that avoids 
getting a fatal error.
"""

Therefore I assigned the bug to Guido <wink>.  It would 
help if you could describe a specific simple scenario that 
provokes the problems you're seeing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513033&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 03:43:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 19:43:32 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-481961 ] Add atoi/atof to string class
Message-ID: <E16mo3Y-0007JY-00@usw-sf-web3.sourceforge.net>

Feature Requests item #481961, was opened at 2001-11-14 23:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=481961&group_id=5470

>Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Thomas Justin Shaw (justinshaw)
>Assigned to: Tim Peters (tim_one)
Summary: Add atoi/atof to string class

Initial Comment:
Just as you can call split() and strip() either from 
the string module or as a string method, it would be 
nice to be able to to the same for atoi() and atof().

Example:
# Current implementation
numStr = '3.14159'
intStr = '2'
pi     = string.atof(numbStr)
two    = string.atio(intStr)

# Proposed implementation
pi  = '3.14159'.atof()
two = '2'.atoi()

Please keep churning out the great work!
Justin Shaw


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-17 22:43

Message:
Logged In: YES 
user_id=31435

I like int("2") a lot better myself <wink>.  Closing as 
requested.

----------------------------------------------------------------------

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-17 22:09

Message:
Logged In: YES 
user_id=135558

Skip this ... I like int("2") better.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=481961&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 05:13:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 21:13:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Message-ID: <E16mpSL-0002Eq-00@usw-sf-web2.sourceforge.net>

Bugs item #531205, was opened at 2002-03-18 00:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Bugs in rfc822.parseaddr()

Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former.  It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.

Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py. 
Once solution might include fixing it in the email
package only.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 07:05:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 17 Mar 2002 23:05:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-508157 ] urllib.urlopen results.readline is slow
Message-ID: <E16mrDF-0003Mh-00@usw-sf-web2.sourceforge.net>

Bugs item #508157, was opened at 2002-01-24 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Keith Davidson (kbdavidson)
>Assigned to: Greg Stein (gstein)
Summary: urllib.urlopen results.readline is slow

Initial Comment:
The socket file object underlying the return from 
urllib.urlopen() is opened without any buffering 
resulting in very slow performance of results.readline
().  The specific problem is in the 
httplib.HTTPResponse constructor.  It calls 
sock.makefile() with a 0 for the buffer size.  Forcing 
the buffer size to 4096 results in the time for 
calling readline() on a 60K character line to go from 
16 seconds to .27 seconds (there is other processing 
going on here but the magnitude of the difference is 
correct).

I am using Python 2.0 so I can not submit a patch 
easily but the problem appears to still be present in 
the 2.2 source.  The specific change is to change the 
0 in sock.makefile() to 4096 or some other reasonable 
buffer size:

class HTTPResponse:
    def __init__(self, sock, debuglevel=0):
        self.fp = sock.makefile('rb', 0)    <= change 
to 4096
        self.debuglevel = debuglevel



----------------------------------------------------------------------

>Comment By: Greg Stein (gstein)
Date: 2002-03-17 23:05

Message:
Logged In: YES 
user_id=6501

Andrew is correct. The buffering was turned off
(specifically) so that the reading of one response will not
consume a portion of the next response.

Jeremy first found the over-reading problem a couple years
ago, and we solved the problem then. To read the thread:
http://mail.python.org/pipermail/python-dev/2000-June/004409.html

After the HTTP response's headers have been read, then it
can be determined whether the connection will be closed at
the end of the response, or whether it will stay open for
more requests to be performed. If it is going to be closed,
then it is possible to use buffering. Of course, that is
*after* the headers, so you'd actually need to do a second
dup/makefile and turn on buffering. This also means that you
wouldn't get the buffering benefits while reading headers.

It could be possible to redesign the connection/response
classes to keep a buffer in the connection object, but that
is quite a bit more involved. It also complicates the
passing of the socket to the response object in some cases.

I'm going to close this as "invalid" since the proposed fix
would break the code.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 15:32

Message:
Logged In: YES 
user_id=11375

Greg Stein originally wrote it;  I'll ping him.

I suspect it might be because of 
HTTP pipelining; if multiple
responses will be returned over a socket, you 
probably can't use buffering because the buffer might consume the end of 
response #1 and the start of response #2.  


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-25 06:12

Message:
Logged In: YES 
user_id=6380

I wonder why the author explicitly turned off buffering.
There probably was a reason? Without knowing why, we can't
just change it.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-01-24 13:54

Message:
Logged In: NO 

What platform?

--Guido (not logged in)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508157&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 09:07:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 01:07:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-531262 ] Wrong result for Canvas.tag_bind(t, s)
Message-ID: <E16mt7X-0000t5-00@usw-sf-web1.sourceforge.net>

Bugs item #531262, was opened at 2002-03-18 09:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Brunel (ebrunel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong result for Canvas.tag_bind(t, s)

Initial Comment:
When a binding is defined for a tag in a Tkinter 
Canvas, trying to get the callback using the 
"tag_bind" method with 2 parameters returns a useless 
value:

----------------------------
from Tkinter import *

root = Tk()

## Create the canvas
c = Canvas(root)
c.pack()

## Create the item
tId = c.create_text(100, 100, text='spam')

## Create the binding
def foo(event): print 'bar'
c.tag_bind(tId, '<Button-1>', foo)

## Get and print the binding
print c.tag_bind(tId, '<Button-1>')

root.mainloop()
---------------------------

The programs prints something looking like: 'if 
{"[136128196foo %# %b %f %h %k %s %t %w %x %y %A %E 
%K %N %W %T %X %Y %D]" == "break"} break'. Trying to 
pass this value as the third parameter of tag_unbind 
for example results in a TclError:

Traceback (most recent call last):
  File "tkCanvasBindings2.py", line 16, in ?
    c.tag_unbind(tId, '<Button-1>', f)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 1904, in 
tag_unbind
    self.deletecommand(funcid)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 297, in 
deletecommand
    self.tk.deletecommand(name)
TclError: can't delete Tcl command

This happens apparently on all platforms (tried 
Win2K, Linux Mandrake 8.0 and Solaris 2.7).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 10:10:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 02:10:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mu6P-0005PT-00@usw-sf-web2.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 20:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Walter Dörwald (doerwalter)
>Assigned to: Martin v. Löwis (loewis)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-18 10:10

Message:
Logged In: YES 
user_id=38388

Assigned to Martin. I don't have time for this the next two weeks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 22:44

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the two bugs.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 22:08

Message:
Logged In: YES 
user_id=21627

This falls in the "doctor, it hurts when I do this"
category, and it is not a regression over 2.1.x, so I don't
think it is critical to fix for 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 10:44:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 02:44:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error
Message-ID: <E16mudH-00020F-00@usw-sf-web1.sourceforge.net>

Bugs item #531145, was opened at 2002-03-18 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sslerror is not a socket.error

Initial Comment:
Python 2.1.2 (#1, Mar 16 2002, 00:56:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
>>> socket.sslerror
<class socket.sslerror at 0x809c39c>
>>> try: raise socket.sslerror
... except socket.error: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.sslerror
>>> 


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-18 11:44

Message:
Logged In: YES 
user_id=21627

Why is this a bug?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 10:47:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 02:47:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-531291 ] Carbon.Res FS-based method problems
Message-ID: <E16mugH-0006BX-00@usw-sf-web4.sourceforge.net>

Bugs item #531291, was opened at 2002-03-18 11:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531291&group_id=5470

Category: Macintosh
Group: Python 2.2
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.Res FS-based method problems

Initial Comment:
The Carbon.Res FSRef-based methods have problems with OSErr results not being returned as exceptions, and the resulting FSRef not being passed back correctly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531291&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 11:58:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 03:58:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-531306 ] ucs4 build horked.
Message-ID: <E16mvmX-00048Y-00@usw-sf-web3.sourceforge.net>

Bugs item #531306, was opened at 2002-03-18 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ucs4 build horked.

Initial Comment:
Try this:

>>> u'\U00010001\U00020002'.encode('utf-8')
Segmentation fault (core dumped)

I thought we'd shaken these out by now?

test_unicode also fails on the trunk in a ucs4 build,
but in a different way.  I don't know if it's related
(unicodeobject.c is fairly different on the trunk and
the branch).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 12:29:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 04:29:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-531306 ] ucs4 build horked.
Message-ID: <E16mwGn-00073J-00@usw-sf-web2.sourceforge.net>

Bugs item #531306, was opened at 2002-03-18 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ucs4 build horked.

Initial Comment:
Try this:

>>> u'\U00010001\U00020002'.encode('utf-8')
Segmentation fault (core dumped)

I thought we'd shaken these out by now?

test_unicode also fails on the trunk in a ucs4 build,
but in a different way.  I don't know if it's related
(unicodeobject.c is fairly different on the trunk and
the branch).

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:29

Message:
Logged In: YES 
user_id=6656

I have a fix for this.  Just testing that it does no damage
in a ucs2 build.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 12:36:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 04:36:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-516299 ] urlparse can get fragments wrong
Message-ID: <E16mwNm-0004f8-00@usw-sf-web3.sourceforge.net>

Bugs item #516299, was opened at 2002-02-12 04:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: Michael Hudson (mwh)
Summary: urlparse can get fragments wrong

Initial Comment:
urlparse.urlparse() goes wrong on a URL such as
'http://amk.ca#foo', where there's a fragment
identifier and 
the hostname isn't followed by a slash.  It returns
'amk.ca#foo'
as the hostname portion of the URL.

While looking at that, I realized that test_urlparse()
only tests urljoin(), not urlparse() or urlunparse(). 
The attached patch
also adds a minimal test suite for urlparse(), but it
should
be still more comprehensive.  Unfortunately the RFC
doesn't include test cases, so I haven't done this yet.

(Assigned to you at random, Michael; feel free to
unassign it
if you lack the time.)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:36

Message:
Logged In: YES 
user_id=6656

I'll get to this in a minute.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 13:34

Message:
Logged In: YES 
user_id=11375

Oops, sorry.  Revised version of the patch attached, that 
just adds the diffs for test_urlparse.

This would be a 2.2.1 candidate, assuming my fix is 
otherwise correct.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-15 10:03

Message:
Logged In: YES 
user_id=6656

Well, make test now says this:

test test_urlparse produced unexpected output:
**********************************************************************
*** lines 2-6 of actual output doesn't appear in expected
output after line 1:
+ http://www.python.org = ('http', 'www.python.org', '', '',
'', '')
+ http://www.python.org#abc = ('http', 'www.python.org', '',
'', '', 'abc')
+ http://www.python.org/#abc = ('http', 'www.python.org',
'/', '', '', 'abc')
+ http://a/b/c/d;p?q#f = ('http', 'a', '/b/c/d', 'p', 'q', 'f')
+
**********************************************************************

did you just forget to update output/test_urlparse?

Is this a 2.2.1 candidate?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 17:52

Message:
Logged In: YES 
user_id=11375

Unassigning -- anyone want to review my bug fix so I can check it 
in?

(leogah's idea of using the regex from RFC2396 is a good one, but 
that 
large a change should probably go into 2.3, not a .1 release.)


----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2002-02-20 13:56

Message:
Logged In: YES 
user_id=356893

The current version of the URI specification (RFC2396) 
includes a regexp for parsing URIs. For evil edge cases, I 
usually cut and paste directly into re.

Would it be an idea just to incorporate it rather than 
hammer the kinks out of the ad-hoc parser? If so, I'll hack 
on it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-02-13 10:45

Message:
Logged In: YES 
user_id=6656

Sorry, don't know *anything* about URLs and don't really
have the time to learn now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 12:44:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 04:44:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-531306 ] ucs4 build horked.
Message-ID: <E16mwUh-0004kS-00@usw-sf-web3.sourceforge.net>

Bugs item #531306, was opened at 2002-03-18 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ucs4 build horked.

Initial Comment:
Try this:

>>> u'\U00010001\U00020002'.encode('utf-8')
Segmentation fault (core dumped)

I thought we'd shaken these out by now?

test_unicode also fails on the trunk in a ucs4 build,
but in a different way.  I don't know if it's related
(unicodeobject.c is fairly different on the trunk and
the branch).

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:44

Message:
Logged In: YES 
user_id=6656

Fixed in unicodeobject.c revision 2.124.6.5.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:29

Message:
Logged In: YES 
user_id=6656

I have a fix for this.  Just testing that it does no damage
in a ucs2 build.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 12:44:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 04:44:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-531306 ] ucs4 build horked.
Message-ID: <E16mwUt-0004kl-00@usw-sf-web3.sourceforge.net>

Bugs item #531306, was opened at 2002-03-18 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: ucs4 build horked.

Initial Comment:
Try this:

>>> u'\U00010001\U00020002'.encode('utf-8')
Segmentation fault (core dumped)

I thought we'd shaken these out by now?

test_unicode also fails on the trunk in a ucs4 build,
but in a different way.  I don't know if it's related
(unicodeobject.c is fairly different on the trunk and
the branch).

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:44

Message:
Logged In: YES 
user_id=6656

Fixed in unicodeobject.c revision 2.124.6.5.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:29

Message:
Logged In: YES 
user_id=6656

I have a fix for this.  Just testing that it does no damage
in a ucs2 build.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531306&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 12:56:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 04:56:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16mwgg-0004tE-00@usw-sf-web3.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 20:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
>Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 7
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Martin v. Löwis (loewis)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:56

Message:
Logged In: YES 
user_id=6656

Applied in Objects/unicodeobject.c revision 2.124.6.6, thanks!

I also added the cases from the report to test_unicode.py
revision 1.47.6.1.

These changes will need to go onto the trunk, at some future
point.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-18 10:10

Message:
Logged In: YES 
user_id=38388

Assigned to Martin. I don't have time for this the next two weeks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 22:44

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the two bugs.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 22:08

Message:
Logged In: YES 
user_id=21627

This falls in the "doctor, it hurts when I do this"
category, and it is not a regression over 2.1.x, so I don't
think it is critical to fix for 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 17:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 13:00:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 05:00:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16mwkg-0004vy-00@usw-sf-web3.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
>Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 13:00

Message:
Logged In: YES 
user_id=6656

That was easy enough; fixed in revision 2.21.16.1 of
Modules/sre.h.

Will need to go onto the trunk, later...

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 22:10

Message:
Logged In: YES 
user_id=38376

as neal points out, the 3rd define (after the #endif)
should be removed.

(my CVS workspace is broken right now, so I cannot
patch this myself -- at least not tonight...)

</F>

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 18:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 17:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 13:06:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 05:06:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-516299 ] urlparse can get fragments wrong
Message-ID: <E16mwqE-000503-00@usw-sf-web3.sourceforge.net>

Bugs item #516299, was opened at 2002-02-12 04:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Michael Hudson (mwh)
Summary: urlparse can get fragments wrong

Initial Comment:
urlparse.urlparse() goes wrong on a URL such as
'http://amk.ca#foo', where there's a fragment
identifier and 
the hostname isn't followed by a slash.  It returns
'amk.ca#foo'
as the hostname portion of the URL.

While looking at that, I realized that test_urlparse()
only tests urljoin(), not urlparse() or urlunparse(). 
The attached patch
also adds a minimal test suite for urlparse(), but it
should
be still more comprehensive.  Unfortunately the RFC
doesn't include test cases, so I haven't done this yet.

(Assigned to you at random, Michael; feel free to
unassign it
if you lack the time.)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-18 13:06

Message:
Logged In: YES 
user_id=6656

Fixed in:
Lib/urlparse.py revisions 1.31.6.1 & 1.32
Lib/test/test_urlparse.py 1.2.24.1 &  1.3
Lib/test/output/test_urlpare 1.2.24.1 & 1.3

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 12:36

Message:
Logged In: YES 
user_id=6656

I'll get to this in a minute.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 13:34

Message:
Logged In: YES 
user_id=11375

Oops, sorry.  Revised version of the patch attached, that 
just adds the diffs for test_urlparse.

This would be a 2.2.1 candidate, assuming my fix is 
otherwise correct.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-15 10:03

Message:
Logged In: YES 
user_id=6656

Well, make test now says this:

test test_urlparse produced unexpected output:
**********************************************************************
*** lines 2-6 of actual output doesn't appear in expected
output after line 1:
+ http://www.python.org = ('http', 'www.python.org', '', '',
'', '')
+ http://www.python.org#abc = ('http', 'www.python.org', '',
'', '', 'abc')
+ http://www.python.org/#abc = ('http', 'www.python.org',
'/', '', '', 'abc')
+ http://a/b/c/d;p?q#f = ('http', 'a', '/b/c/d', 'p', 'q', 'f')
+
**********************************************************************

did you just forget to update output/test_urlparse?

Is this a 2.2.1 candidate?

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 17:52

Message:
Logged In: YES 
user_id=11375

Unassigning -- anyone want to review my bug fix so I can check it 
in?

(leogah's idea of using the regex from RFC2396 is a good one, but 
that 
large a change should probably go into 2.3, not a .1 release.)


----------------------------------------------------------------------

Comment By: Richard Brodie (leogah)
Date: 2002-02-20 13:56

Message:
Logged In: YES 
user_id=356893

The current version of the URI specification (RFC2396) 
includes a regexp for parsing URIs. For evil edge cases, I 
usually cut and paste directly into re.

Would it be an idea just to incorporate it rather than 
hammer the kinks out of the ad-hoc parser? If so, I'll hack 
on it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-02-13 10:45

Message:
Logged In: YES 
user_id=6656

Sorry, don't know *anything* about URLs and don't really
have the time to learn now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516299&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 14:22:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 06:22:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests
Message-ID: <E16my1j-0004hv-00@usw-sf-web1.sourceforge.net>

Bugs item #450225, was opened at 2001-08-12 06:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urljoin fails RFC tests

Initial Comment:
I've put together a test suite for Python's URLparse 
module, based on the tests in Appendix C of 
RFC2396 (the URI RFC). They're available at:

http://lists.w3.org/Archives/Public/uri/2001Aug/
0013.html

The major problem seems to be that it treats 
queries and parameters as special components 
(not just normal parts of the path), making this 
related to:

http://sourceforge.net/tracker/?group_id=5470&
atid=105470&func=detail&aid=210834

----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-18 14:22

Message:
Logged In: YES 
user_id=76089

I think it would be better btw if '..' components taking 
you 'off the top' were stripped. RFC 2396 says this is 
valid behaviour, and it's what 'real' browsers do.

i.e.
  http://a/b/ + ../../../d == http://a/d


----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 18:34

Message:
Logged In: YES 
user_id=122141

Oops, meant to attach it...

----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 18:30

Message:
Logged In: YES 
user_id=122141

Sure, here they are:



import urlparse

base = 'http://a/b/c/d;p?q'

assert urlparse.urljoin(base, 'g:h') == 'g:h'
assert urlparse.urljoin(base, 'g') ==   'http://a/b/c/g'
assert urlparse.urljoin(base, './g') == 'http://a/b/c/g'
assert urlparse.urljoin(base, 'g/') ==  'http://a/b/c/g/'
assert urlparse.urljoin(base, '/g') ==  'http://a/g'
assert urlparse.urljoin(base, '//g') == 'http://g'
assert urlparse.urljoin(base, '?y') ==  'http://a/b/c/?y'
assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y'
assert urlparse.urljoin(base, '#s') ==  'http://a/b/c/
d;p?q#s'
assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s'
assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/
g?y#s'
assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x'
assert urlparse.urljoin(base, 'g;x') ==  'http://a/b/c/g;x'
assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/
g;x?y#s'
assert urlparse.urljoin(base, '.') ==  'http://a/b/c/'
assert urlparse.urljoin(base, './') ==  'http://a/b/c/'
assert urlparse.urljoin(base, '..') ==  'http://a/b/'
assert urlparse.urljoin(base, '../') ==  'http://a/b/'
assert urlparse.urljoin(base, '../g') ==  'http://a/b/g'
assert urlparse.urljoin(base, '../..') ==  'http://a/'
assert urlparse.urljoin(base, '../../') ==  'http://a/'
assert urlparse.urljoin(base, '../../g') ==  'http://a/g'

assert urlparse.urljoin(base, '') == base

assert urlparse.urljoin(base, '../../../g')    ==  'http://a/../g'
assert urlparse.urljoin(base, '../../../../g') ==  'http://a/../../g'

assert urlparse.urljoin(base, '/./g') ==  'http://a/./g'
assert urlparse.urljoin(base, '/../g')         ==  'http://a/../g'
assert urlparse.urljoin(base, 'g.')            ==  'http://a/b/c/
g.'
assert urlparse.urljoin(base, '.g')            ==  'http://a/b/c/
.g'
assert urlparse.urljoin(base, 'g..')           == 'http://a/b/c/
g..'
assert urlparse.urljoin(base, '..g')           == 'http://a/b/c/
..g'

assert urlparse.urljoin(base, './../g')        ==  'http://a/b/g'
assert urlparse.urljoin(base, './g/.')         ==  'http://a/b/c/
g/'
assert urlparse.urljoin(base, 'g/./h')         ==  'http://a/b/c/
g/h'
assert urlparse.urljoin(base, 'g/../h')        ==  'http://a/b/c/
h'
assert urlparse.urljoin(base, 'g;x=1/./y')     ==  
'http://a/b/c/g;x=1/y'
assert urlparse.urljoin(base, 'g;x=1/../y')    ==  'http://a/b/
c/y'

assert urlparse.urljoin(base, 'g?y/./x')       ==  
'http://a/b/c/g?y/./x'
assert urlparse.urljoin(base, 'g?y/../x')      == 
'http://a/b/c/g?y/../x'
assert urlparse.urljoin(base, 'g#s/./x')       ==  'http://a/b/
c/g#s/./x'
assert urlparse.urljoin(base, 'g#s/../x')      ==  'http://a/b/
c/g#s/../x'



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-05 18:05

Message:
Logged In: YES 
user_id=3066

This looks like its probably related to #478038; I'll try to
tackle them together.  Can you attach your tests to the bug
report on SF?  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 14:32:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 06:32:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] coercian related - complex builtin
Message-ID: <E16myBX-0004p3-00@usw-sf-web1.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Nobody/Anonymous (nobody)
Summary: coercian related - complex builtin

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 14:49:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 06:49:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16myRb-000516-00@usw-sf-web1.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

>Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Arthur Siegel (aj_siegel)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 15:39:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 07:39:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-531291 ] Carbon.Res FS-based method problems
Message-ID: <E16mzE1-0000rT-00@usw-sf-web2.sourceforge.net>

Bugs item #531291, was opened at 2002-03-18 11:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531291&group_id=5470

Category: Macintosh
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.Res FS-based method problems

Initial Comment:
The Carbon.Res FSRef-based methods have problems with OSErr results not being returned as exceptions, and the resulting FSRef not being passed back correctly.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-18 16:39

Message:
Logged In: YES 
user_id=45365

Fixed in _resmodule.c rev. 1.10 on the trunk and 1.7.4.2 in the 221 branch.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531291&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 16:05:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 08:05:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-531398 ] 221 still doesn't work on OS 8.1
Message-ID: <E16mzdM-0001An-00@usw-sf-web2.sourceforge.net>

Bugs item #531398, was opened at 2002-03-18 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: 221 still doesn't work on OS 8.1

Initial Comment:
The current problem is that InterfaceLib--FSRenameUnicode is undefined. Let's try and weak-link InterfaceLib and hope that doesn't cause a string of new problems.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 16:33:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 08:33:59 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16n059-0006HH-00@usw-sf-web1.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 20:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 11:33

Message:
Logged In: YES 
user_id=12800

Here's a simplification, based on re.  I added a bunch of
test cases that failed under stock email 1.2, passed with
your patch, and still pass with mine.  Let me know what you
think.  If you like it, I'll commit this to the email
package and fold it into the Python distro.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-12 17:52

Message:
Logged In: YES 
user_id=85984

Take a look at the attached formataddr()
implementation.

Unlike dump_address_pair(), it takes care
to both double-quote the fullname only
when necessary, and also escape any
delimiting lexical tokens with a backslash.
This will hopefully produce a more RFC 2822 
compliant result.



----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 13:07

Message:
Logged In: YES 
user_id=85984

Yes, I think formataddr() is a much better
name.  dump_address_pair() is not very intuitive
at all IMO.




----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 12:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 17:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 17:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 10:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 18:00:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 10:00:04 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16n1QS-0008Jq-00@usw-sf-web3.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


----------------------------------------------------------------------

>Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-18 11:00

Message:
Logged In: YES 
user_id=85984

Looks good to me.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 09:33

Message:
Logged In: YES 
user_id=12800

Here's a simplification, based on re.  I added a bunch of
test cases that failed under stock email 1.2, passed with
your patch, and still pass with mine.  Let me know what you
think.  If you like it, I'll commit this to the email
package and fold it into the Python distro.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-12 15:52

Message:
Logged In: YES 
user_id=85984

Take a look at the attached formataddr()
implementation.

Unlike dump_address_pair(), it takes care
to both double-quote the fullname only
when necessary, and also escape any
delimiting lexical tokens with a backslash.
This will hopefully produce a more RFC 2822 
compliant result.



----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 11:07

Message:
Logged In: YES 
user_id=85984

Yes, I think formataddr() is a much better
name.  dump_address_pair() is not very intuitive
at all IMO.




----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 10:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 10:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 15:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 15:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 08:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 18:01:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 10:01:28 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-494034 ] a smarter rfc822.dump_address_pair()
Message-ID: <E16n1Ro-0002NE-00@usw-sf-web2.sourceforge.net>

Feature Requests item #494034, was opened at 2001-12-16 20:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jason R. Mastaler (jasonrm)
Assigned to: Barry Warsaw (bwarsaw)
Summary: a smarter rfc822.dump_address_pair()

Initial Comment:
Please see:
http://mail.python.org/pipermail/python-list/2001-December/075881.html

I'm turning this into a feature request since
I didn't get any responses on comp.lang.python.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 13:01

Message:
Logged In: YES 
user_id=12800

Excellent!  I'm commiting this to standalone email pkg first
(for v1.3) and will merge it into the Python distro for
python 2.3.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-18 13:00

Message:
Logged In: YES 
user_id=85984

Looks good to me.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 11:33

Message:
Logged In: YES 
user_id=12800

Here's a simplification, based on re.  I added a bunch of
test cases that failed under stock email 1.2, passed with
your patch, and still pass with mine.  Let me know what you
think.  If you like it, I'll commit this to the email
package and fold it into the Python distro.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-12 17:52

Message:
Logged In: YES 
user_id=85984

Take a look at the attached formataddr()
implementation.

Unlike dump_address_pair(), it takes care
to both double-quote the fullname only
when necessary, and also escape any
delimiting lexical tokens with a backslash.
This will hopefully produce a more RFC 2822 
compliant result.



----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 13:07

Message:
Logged In: YES 
user_id=85984

Yes, I think formataddr() is a much better
name.  dump_address_pair() is not very intuitive
at all IMO.




----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:49

Message:
Logged In: YES 
user_id=12800

Oh, and how motivated would you be to writing a new
implementation of parseaddr()? <wink>.

There are two problems with the one from rfc822.py.  First,
we've got the ugly workaround for a bug in older versions
(where realname='' and emailaddr=None).  Second, it has a
nasty bug when the email address contains embedded spaces:
it collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more involved to
implement in an RFC 2822 compliant way, but it would be very
cool.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-07 12:45

Message:
Logged In: YES 
user_id=12800

I'd like to gradually reduce the dependence on rfc822.py so
please write the new implementation for email.Utils.  This
is exactly the route taken for formatdate().

Also, let's come up with a better name than
dump_address_pairs().  We have a parsedate() and a
formatdate().  We've got a parseaddr() so what do you think
about formataddr()?  We can keep dump_address_pairs as a
back-compat alias.

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2002-03-07 12:40

Message:
Logged In: YES 
user_id=85984

I'd like to take a shot at coding a better
dump_address_pair method.  Before I start, should
the diff be against rfc822 or email.Utils? (which
currently just imports dump_address_pair from
rfc822).  Perhaps a new implementation like this
should just go into email, and
rfc822.dump_address_pair() can just be left as is,
similar to how the formatdate method was
reimplemented for email.

Let me know what you think.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 17:41

Message:
Logged In: YES 
user_id=12800

If you get to it before I do, upload it here... :)

----------------------------------------------------------------------

Comment By: Jason R. Mastaler (jasonrm)
Date: 2001-12-17 17:28

Message:
Logged In: YES 
user_id=85984

Thanks Barry.  If you don't think you'll have time to
write the code for this, I can try and work on a patch.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-12-17 10:04

Message:
Logged In: YES 
user_id=12800

Claiming this item.  There appears to be no groups set for
the feature request tracker, but I'll look at this for
Python 2.3 (to late to add it to Python 2.2).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=494034&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 18:48:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 10:48:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16n2As-00030Q-00@usw-sf-web2.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.3
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-18 13:48

Message:
Logged In: YES 
user_id=33168

Fixed in revision: 2.22.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 08:00

Message:
Logged In: YES 
user_id=6656

That was easy enough; fixed in revision 2.21.16.1 of
Modules/sre.h.

Will need to go onto the trunk, later...

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 17:10

Message:
Logged In: YES 
user_id=38376

as neal points out, the 3rd define (after the #endif)
should be removed.

(my CVS workspace is broken right now, so I cannot
patch this myself -- at least not tonight...)

</F>

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 13:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 18:53:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 10:53:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-505488 ] python-mode.el sets TMPDIR to /usr/tmp
Message-ID: <E16n2Gb-00034X-00@usw-sf-web2.sourceforge.net>

Bugs item #505488, was opened at 2002-01-18 13:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode.el sets TMPDIR to /usr/tmp

Initial Comment:
all python versions. Not sure why, but on most systems 
this directory does not exist. Probably should be
/var/tmp ...(variable py-temp-directory).


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 13:53

Message:
Logged In: YES 
user_id=12800

Hmm, first, the Summary is incorrect since python-mode never
sets $TMPDIR, although it does read $TMPDIR.  Note that
python-mode also should never use /usr/tmp if it doesn't
exist; it'll just go down the line of $TMPDIR, /usr/tmp,
/tmp,  and then . looking for a writable existing directory.

I don't mind adding /var/tmp to that list, but it should be
done after /tmp, since I think on many systems /var/tmp may
not be writable by everyone.  You can always override this
by setting the TMPDIR environment variable.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-17 18:28

Message:
Logged In: YES 
user_id=44345

proposed patch attached.  Suggest adding /var/tmp ahead
of /usr/tmp.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505488&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 19:03:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 11:03:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-474585 ] Deprecate modules
Message-ID: <E16n2Pe-0008FC-00@usw-sf-web1.sourceforge.net>

Bugs item #474585, was opened at 2001-10-24 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Deprecate modules

Initial Comment:
The following modules should be marked as deprecated
because the new email package provides all the
functionality (using different APIs perhaps, and it
steals some implementation from rfc822.py, but still...)

rfc822.py
mimetools.py
MIMEWriter.py

Technically mimify.py should be deprecated too, however
the email package doesn't provide the run-as-script
functionality.  That would be easy to provide as a
Tools/script, so I still think it should be deprecated.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 14:03

Message:
Logged In: YES 
user_id=12800

I'm not sure it's worth formally deprecating these modules
anymore.  We should probably just let people find and start
using email pkg.  The older modules will bitrot of their own
accord.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-13 17:02

Message:
Logged In: YES 
user_id=12800

Postponing until Python 2.3

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-24 18:06

Message:
Logged In: YES 
user_id=12800

Assigning back to me and re-opening.  Not sure it'll be
worth it, but this way it'll keep bugging me. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-24 17:42

Message:
Logged In: YES 
user_id=3066

After discussion with Guido, this appears to be too
agressive a deprecation schedule for these modules,
especially rfc822.  A good first step would be to
demonstrate that all uses of these modules can use the email
package.  Perhaps implementations of these modules should be
made using the facilities of the email package?

(Don't check them into the library yet; perhaps add them to
nondist/sandbox/Lib/ first.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 19:07:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 11:07:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-474585 ] Deprecate modules
Message-ID: <E16n2TO-0003EG-00@usw-sf-web2.sourceforge.net>

Bugs item #474585, was opened at 2001-10-24 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Deprecate modules

Initial Comment:
The following modules should be marked as deprecated
because the new email package provides all the
functionality (using different APIs perhaps, and it
steals some implementation from rfc822.py, but still...)

rfc822.py
mimetools.py
MIMEWriter.py

Technically mimify.py should be deprecated too, however
the email package doesn't provide the run-as-script
functionality.  That would be easy to provide as a
Tools/script, so I still think it should be deprecated.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-18 14:07

Message:
Logged In: YES 
user_id=3066

I disagree.  If the expectation is that these modules will
be allowed to bitrot, then we need to formally deprecate and
point to the proper replacements.  That's what deprecation
is *for*.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 14:03

Message:
Logged In: YES 
user_id=12800

I'm not sure it's worth formally deprecating these modules
anymore.  We should probably just let people find and start
using email pkg.  The older modules will bitrot of their own
accord.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-13 17:02

Message:
Logged In: YES 
user_id=12800

Postponing until Python 2.3

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-24 18:06

Message:
Logged In: YES 
user_id=12800

Assigning back to me and re-opening.  Not sure it'll be
worth it, but this way it'll keep bugging me. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-24 17:42

Message:
Logged In: YES 
user_id=3066

After discussion with Guido, this appears to be too
agressive a deprecation schedule for these modules,
especially rfc822.  A good first step would be to
demonstrate that all uses of these modules can use the email
package.  Perhaps implementations of these modules should be
made using the facilities of the email package?

(Don't check them into the library yet; perhaps add them to
nondist/sandbox/Lib/ first.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 19:28:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 11:28:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-474585 ] Deprecate modules
Message-ID: <E16n2ny-0003Tz-00@usw-sf-web2.sourceforge.net>

Bugs item #474585, was opened at 2001-10-24 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Open
>Resolution: Later
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Deprecate modules

Initial Comment:
The following modules should be marked as deprecated
because the new email package provides all the
functionality (using different APIs perhaps, and it
steals some implementation from rfc822.py, but still...)

rfc822.py
mimetools.py
MIMEWriter.py

Technically mimify.py should be deprecated too, however
the email package doesn't provide the run-as-script
functionality.  That would be easy to provide as a
Tools/script, so I still think it should be deprecated.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 14:28

Message:
Logged In: YES 
user_id=6380

I'm with Fred. They need to be deprecated. The deprecation
schedule should be slow because they're so popular (at least
rfc822 is, I don't think the others are).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-18 14:07

Message:
Logged In: YES 
user_id=3066

I disagree.  If the expectation is that these modules will
be allowed to bitrot, then we need to formally deprecate and
point to the proper replacements.  That's what deprecation
is *for*.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 14:03

Message:
Logged In: YES 
user_id=12800

I'm not sure it's worth formally deprecating these modules
anymore.  We should probably just let people find and start
using email pkg.  The older modules will bitrot of their own
accord.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-13 17:02

Message:
Logged In: YES 
user_id=12800

Postponing until Python 2.3

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-24 18:06

Message:
Logged In: YES 
user_id=12800

Assigning back to me and re-opening.  Not sure it'll be
worth it, but this way it'll keep bugging me. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-24 17:42

Message:
Logged In: YES 
user_id=3066

After discussion with Guido, this appears to be too
agressive a deprecation schedule for these modules,
especially rfc822.  A good first step would be to
demonstrate that all uses of these modules can use the email
package.  Perhaps implementations of these modules should be
made using the facilities of the email package?

(Don't check them into the library yet; perhaps add them to
nondist/sandbox/Lib/ first.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 19:28:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 11:28:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-474585 ] Deprecate modules
Message-ID: <E16n2o9-0000zt-00@usw-sf-web3.sourceforge.net>

Bugs item #474585, was opened at 2001-10-24 15:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Deprecate modules

Initial Comment:
The following modules should be marked as deprecated
because the new email package provides all the
functionality (using different APIs perhaps, and it
steals some implementation from rfc822.py, but still...)

rfc822.py
mimetools.py
MIMEWriter.py

Technically mimify.py should be deprecated too, however
the email package doesn't provide the run-as-script
functionality.  That would be easy to provide as a
Tools/script, so I still think it should be deprecated.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 14:28

Message:
Logged In: YES 
user_id=12800

Okay, I'll follow the formal PEP 4 deprecation procedure.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 14:28

Message:
Logged In: YES 
user_id=6380

I'm with Fred. They need to be deprecated. The deprecation
schedule should be slow because they're so popular (at least
rfc822 is, I don't think the others are).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-18 14:07

Message:
Logged In: YES 
user_id=3066

I disagree.  If the expectation is that these modules will
be allowed to bitrot, then we need to formally deprecate and
point to the proper replacements.  That's what deprecation
is *for*.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-18 14:03

Message:
Logged In: YES 
user_id=12800

I'm not sure it's worth formally deprecating these modules
anymore.  We should probably just let people find and start
using email pkg.  The older modules will bitrot of their own
accord.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-11-13 17:02

Message:
Logged In: YES 
user_id=12800

Postponing until Python 2.3

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-24 18:06

Message:
Logged In: YES 
user_id=12800

Assigning back to me and re-opening.  Not sure it'll be
worth it, but this way it'll keep bugging me. :)

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-10-24 17:42

Message:
Logged In: YES 
user_id=3066

After discussion with Guido, this appears to be too
agressive a deprecation schedule for these modules,
especially rfc822.  A good first step would be to
demonstrate that all uses of these modules can use the email
package.  Perhaps implementations of these modules should be
made using the facilities of the email package?

(Don't check them into the library yet; perhaps add them to
nondist/sandbox/Lib/ first.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474585&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 20:23:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 12:23:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-531145 ] socket.sslerror is not a socket.error
Message-ID: <E16n3fa-00049E-00@usw-sf-web2.sourceforge.net>

Bugs item #531145, was opened at 2002-03-18 00:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Bastian Kleineidam (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sslerror is not a socket.error

Initial Comment:
Python 2.1.2 (#1, Mar 16 2002, 00:56:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
>>> socket.sslerror
<class socket.sslerror at 0x809c39c>
>>> try: raise socket.sslerror
... except socket.error: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.sslerror
>>> 


----------------------------------------------------------------------

>Comment By: Bastian Kleineidam (calvin)
Date: 2002-03-18 21:23

Message:
Logged In: YES 
user_id=9205

The documentation says for socket.error: "This exception is
raised for socket- or address-related errors." I think
socket.sslerror is such an error, because then you can write

try: sock.write("") # could be ssl-socket
except socket.error: pass

The other way would be
_exceptions = [socket.error]
if hasattr(socket, "sslerror"):
    _exceptions.append(socket.sslerror)
try: sock.write("")
except _exceptions: pass

Anyway, I assume this is a minor "bug".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-18 11:44

Message:
Logged In: YES 
user_id=21627

Why is this a bug?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531145&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 20:55:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 12:55:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar'
Message-ID: <E16n49n-00018U-00@usw-sf-web1.sourceforge.net>

Bugs item #500073, was opened at 2002-01-06 00:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Bernard YUE (berniey)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser fail to handle '&foobar'

Initial Comment:
HTMLParser did not distingish between &foobar; and 
&foobar.  The later is still considered as a 
charref/entityref.  Below is my posposed fix:

File:  sgmllib.py

# SGMLParser.goahead()
# line 162-176
# from
            elif rawdata[i] == '&':
                match = charref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_charref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_entityref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue

# to
            elif rawdata[i] == '&'
                match = charref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an charref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else:
                        name = match.group(1)
                        self.handle_charref(name)
                        i = match.end(0)
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an entitiyref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else: 
                        name = match.group(1)
                        self.handle_entityref(name)
                        i = match.end(0)
                    continue



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-18 12:55

Message:
Logged In: NO 

no entiendo el proyecto pyton ni el funcionamiento del 
server no he encontrado ningun archivo pdf que te pueda 
explicar el desarrollo en español atte sebastia

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 22:02

Message:
Logged In: YES 
user_id=3066

Bump the priority so I'll have to look at this when I'm not
too tired to think straight.

----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 22:35

Message:
Logged In: YES 
user_id=419276

Hi Guys,

I felt embarrass as I confuss everybody here.  Martin is nearly 
100% right.  Except that all &foo, &foo;, &#bar, &#bar; are all 
valid entity in HTML 4.01 as well if it was defined (I did not put 
enough test case in the old test.html to spot my mistake, when I 
ran it with the W3C Html validator, the new one should include 
all cases).  Hence the existing sgmllib.py was correct<Oops!>.

However, all the major browsers (IE, Natscape, Konqueror, Opera) 
choose to print the invalid HTML as plain text.  Hence I think 
htmllib.py might as well follow the crowd as well.

My suggestion is to added functions 
HTMLParser.unknown_charref() and and 
HTMLParser.unknown_entityref() as follows (files attached):

    # --- treat unknown entity as plain text

    def unknown_charref(self, ref):
        self.handle_data( '&#' + ref)

    def unknown_entityref(self, ref): 
        self.handle_data( '&'+ ref)

Sorry again for my previous incorrect patches.

Bernie


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 21:30

Message:
Logged In: YES 
user_id=21627

I still recommend to reject this patch, it is plain wrong.
Do we all agree that an HTML Document containing &you is
ill-formed (all HTML versions)? If so, it is a matter of
best-effort what to do with it.

In SGML, it is well-formed to omit the semicolon from the
entity name in a entity reference in certain cases, see

http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi

Therefore, omission of the semicolon does *not* mean that
you don't have an entity reference, and sgmllib's processing
of entity references is completely correct - it would be an
error to treat &you as data. 

Therefore, your document is correct SGML. It just fails to
be correct HTML, since the entity 'you' is not defined.

If you want to process such a document in a specific way, I
recommend to subclass HTMLParser, overriding unknown_entityref.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 20:42

Message:
Logged In: YES 
user_id=6380

I'm reassigning this to Fred.

In 2.2, the new HTMLParser may or may not still have this
problem.

In 2.1.2, I think that "fixing" it would be too big a risk
of breaking existing code, so I think it should not be
fixed.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 20:33

Message:
Logged In: YES 
user_id=44345

Bernie,

I tried your patch.  It looks good to me.  I was a tad
confused 
when I first read your bug report.  I thought
you were suggesting that 
"&foo" be interpreted as a
charref/entityref.  Instead you are 
tightening up the
parser.

That seems reasonable to me.  Martin, what 
do you think?

Skip


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 17:04

Message:
Logged In: YES 
user_id=419276

Hi again,

I just run the test.html with w3c's HTML validator.  &you does 
indeed treated as an invalid entityref in HTML 4.01.  I've displays 
test.html under IE, Netscape and Konqueror and it all gave the 
result I've expected.  I am not sure if sgmllib.py should stick with 
the standard or go with the general defacto interpretation.

But I think it is more sensable to treat &you as text.


Bernie


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 16:43

Message:
Logged In: YES 
user_id=419276

Hi Martin and Skip,

Sorry for not explain myself clearly.  What I mean is that &foobar 
should have been treated as '&foobar' literally (i.e. text), and 
&forbat; should be an entityref and &#forbar; as charref.

Currently, sgmllib treated &foobar as entityref and &#foobar as 
charref and match it against entityref table and charref table.  
Ignores the entity when a match is not found.

My suggested change should fix this problem.  Run test.py 
(test.py and test.html attached)

>./test.py

Me! Me & You! Copyright@copy;abc Copyright©abc © ©

But we are expecting:
Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

My suggested change will print the expected output.

# test.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3c.org/TR/html4/strict.dtd">

<html>
<head dir="ltr" lang="en">
  <TITLE>Testing Page</TITLE>
  <META name="AUTHOR" content="Bernard Yue">
  <META name="DESCRIPTION" content="Testing Page">
</head>
<body>
  <p>Me&you!  Me & You! Copyright@copy;abc 
Copyright&#169;abc &copy; &#169;
  </p>
</body>
</html>

# test.py
#!/usr/bin/env python

from htmllib import HTMLParser
from formatter import AbstractFormatter, DumbWriter


def test():
    _formatter = AbstractFormatter( DumbWriter())
    _parser = HTMLParser( _formatter)
    _f = open( './test.html')

    _parser.feed( _f.read())
    _f.close()
    _parser.close()
    print ''

if __name__ == '__main__':
    test()




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 14:02

Message:
Logged In: YES 
user_id=21627

I fail to see the problem as well. Please attach an example
document to this report. Without a detailed analysis of the
problem in question, there is zero chance that any change
like this is accepted.

Here is my analysis from your report: It seems that you
complain that sgmllib, when it sees an ill-formed document,
behaves in a particular way, whereas you expect to behave it
in a different way. Since the document is ill-formed
anyways, any behaviour is as good as any other.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 13:03

Message:
Logged In: YES 
user_id=44345

Bernie,

I see nothing wrong in principal with recognizing 
"&nbsp"
when the user should have typed "&nbsp;", but I wonder
about 
the validity of "&nbsp".  You mentioned it's still
a charref or 
entityref.  Is that documented somewhere or
is it simply a practical 
approach to a common problem?

Thanks,

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 21:00:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 13:00:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-500073 ] HTMLParser fail to handle '&foobar'
Message-ID: <E16n4FN-0004b1-00@usw-sf-web2.sourceforge.net>

Bugs item #500073, was opened at 2002-01-06 03:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Bernard YUE (berniey)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: HTMLParser fail to handle '&foobar'

Initial Comment:
HTMLParser did not distingish between &foobar; and 
&foobar.  The later is still considered as a 
charref/entityref.  Below is my posposed fix:

File:  sgmllib.py

# SGMLParser.goahead()
# line 162-176
# from
            elif rawdata[i] == '&':
                match = charref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_charref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    name = match.group(1)
                    self.handle_entityref(name)
                    i = match.end(0)
                    if rawdata[i-1] != ';': i = i-1
                    continue

# to
            elif rawdata[i] == '&'
                match = charref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an charref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else:
                        name = match.group(1)
                        self.handle_charref(name)
                        i = match.end(0)
                    continue
                match = entityref.match(rawdata, i)
                if match:
                    if rawdata[match.end(0)-1] != ';':
                        # not really an entitiyref
                        self.handle_data(rawdata[i])
                        i = i+1
                    else: 
                        name = match.group(1)
                        self.handle_entityref(name)
                        i = match.end(0)
                    continue



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 16:00

Message:
Logged In: YES 
user_id=6380

http://www.python.org/doc/NonEnglish.html#spanish

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-18 15:55

Message:
Logged In: NO 

no entiendo el proyecto pyton ni el funcionamiento del 
server no he encontrado ningun archivo pdf que te pueda 
explicar el desarrollo en español atte sebastia

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-13 01:02

Message:
Logged In: YES 
user_id=3066

Bump the priority so I'll have to look at this when I'm not
too tired to think straight.

----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-09 01:35

Message:
Logged In: YES 
user_id=419276

Hi Guys,

I felt embarrass as I confuss everybody here.  Martin is nearly 
100% right.  Except that all &foo, &foo;, &#bar, &#bar; are all 
valid entity in HTML 4.01 as well if it was defined (I did not put 
enough test case in the old test.html to spot my mistake, when I 
ran it with the W3C Html validator, the new one should include 
all cases).  Hence the existing sgmllib.py was correct<Oops!>.

However, all the major browsers (IE, Natscape, Konqueror, Opera) 
choose to print the invalid HTML as plain text.  Hence I think 
htmllib.py might as well follow the crowd as well.

My suggestion is to added functions 
HTMLParser.unknown_charref() and and 
HTMLParser.unknown_entityref() as follows (files attached):

    # --- treat unknown entity as plain text

    def unknown_charref(self, ref):
        self.handle_data( '&#' + ref)

    def unknown_entityref(self, ref): 
        self.handle_data( '&'+ ref)

Sorry again for my previous incorrect patches.

Bernie


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-09 00:30

Message:
Logged In: YES 
user_id=21627

I still recommend to reject this patch, it is plain wrong.
Do we all agree that an HTML Document containing &you is
ill-formed (all HTML versions)? If so, it is a matter of
best-effort what to do with it.

In SGML, it is well-formed to omit the semicolon from the
entity name in a entity reference in certain cases, see

http://bip.cnrs-mrs.fr/bip10/scowl.htm#semi

Therefore, omission of the semicolon does *not* mean that
you don't have an entity reference, and sgmllib's processing
of entity references is completely correct - it would be an
error to treat &you as data. 

Therefore, your document is correct SGML. It just fails to
be correct HTML, since the entity 'you' is not defined.

If you want to process such a document in a specific way, I
recommend to subclass HTMLParser, overriding unknown_entityref.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-08 23:42

Message:
Logged In: YES 
user_id=6380

I'm reassigning this to Fred.

In 2.2, the new HTMLParser may or may not still have this
problem.

In 2.1.2, I think that "fixing" it would be too big a risk
of breaking existing code, so I think it should not be
fixed.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 23:33

Message:
Logged In: YES 
user_id=44345

Bernie,

I tried your patch.  It looks good to me.  I was a tad
confused 
when I first read your bug report.  I thought
you were suggesting that 
"&foo" be interpreted as a
charref/entityref.  Instead you are 
tightening up the
parser.

That seems reasonable to me.  Martin, what 
do you think?

Skip


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 20:04

Message:
Logged In: YES 
user_id=419276

Hi again,

I just run the test.html with w3c's HTML validator.  &you does 
indeed treated as an invalid entityref in HTML 4.01.  I've displays 
test.html under IE, Netscape and Konqueror and it all gave the 
result I've expected.  I am not sure if sgmllib.py should stick with 
the standard or go with the general defacto interpretation.

But I think it is more sensable to treat &you as text.


Bernie


----------------------------------------------------------------------

Comment By: Bernard YUE (berniey)
Date: 2002-01-08 19:43

Message:
Logged In: YES 
user_id=419276

Hi Martin and Skip,

Sorry for not explain myself clearly.  What I mean is that &foobar 
should have been treated as '&foobar' literally (i.e. text), and 
&forbat; should be an entityref and &#forbar; as charref.

Currently, sgmllib treated &foobar as entityref and &#foobar as 
charref and match it against entityref table and charref table.  
Ignores the entity when a match is not found.

My suggested change should fix this problem.  Run test.py 
(test.py and test.html attached)

>./test.py

Me! Me & You! Copyright@copy;abc Copyright©abc © ©

But we are expecting:
Me&you! Me & You! Copyright@copy;abc Copyright©abc © ©

My suggested change will print the expected output.

# test.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
        "http://www.w3c.org/TR/html4/strict.dtd">

<html>
<head dir="ltr" lang="en">
  <TITLE>Testing Page</TITLE>
  <META name="AUTHOR" content="Bernard Yue">
  <META name="DESCRIPTION" content="Testing Page">
</head>
<body>
  <p>Me&you!  Me & You! Copyright@copy;abc 
Copyright&#169;abc &copy; &#169;
  </p>
</body>
</html>

# test.py
#!/usr/bin/env python

from htmllib import HTMLParser
from formatter import AbstractFormatter, DumbWriter


def test():
    _formatter = AbstractFormatter( DumbWriter())
    _parser = HTMLParser( _formatter)
    _f = open( './test.html')

    _parser.feed( _f.read())
    _f.close()
    _parser.close()
    print ''

if __name__ == '__main__':
    test()




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 17:02

Message:
Logged In: YES 
user_id=21627

I fail to see the problem as well. Please attach an example
document to this report. Without a detailed analysis of the
problem in question, there is zero chance that any change
like this is accepted.

Here is my analysis from your report: It seems that you
complain that sgmllib, when it sees an ill-formed document,
behaves in a particular way, whereas you expect to behave it
in a different way. Since the document is ill-formed
anyways, any behaviour is as good as any other.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-01-08 16:03

Message:
Logged In: YES 
user_id=44345

Bernie,

I see nothing wrong in principal with recognizing 
"&nbsp"
when the user should have typed "&nbsp;", but I wonder
about 
the validity of "&nbsp".  You mentioned it's still
a charref or 
entityref.  Is that documented somewhere or
is it simply a practical 
approach to a common problem?

Thanks,

Skip


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500073&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 21:30:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 13:30:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16n4iF-0002Um-00@usw-sf-web3.sourceforge.net>

Bugs item #529713, was opened at 2002-03-13 20:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Bob Plankers (plankers)
Date: 2002-03-18 15:30

Message:
Logged In: YES 
user_id=485432

Okay, try this. The old value of $LINKCC wasn't being 
appended to the new value for $LINKCC. Removing the 
parentheses helps.

I took the liberty of doing that for the Monterey64 and 
dgux entries as well. It works nicely for AIX.

The new patch contains the Makefile.pre.in changes, too.

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 03:11

Message:
Logged In: YES 
user_id=21627

The chunk on changing LDSHARED to BLDSHARED is definitely right.

On the chunk using $(CC) - I cannot really see why this is
necessary. Right above the AIX assignment of LINKCC, there
is a test with three alternatives ($CXX is empty, it is
needed to link a C++ program, it is not needed). In either
case, LINKCC is set. So it is surprising why LINKCC is then
not set in the right-hand side of the AIX assignment.

Can you please investigate? Perhaps putting echo statements
would be sufficient, or 'set -x' right above that entire
chain of if statements.

Notice that I hesitate to accept your patch because we also
have bug reports where user complain that LINKCC should use
the C++ compiler if available. The test is designed to
enable that feature; your patch would break it.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-15 00:34

Message:
Logged In: YES 
user_id=485432

I am attaching a patch for the linking problem, as well as 
a problem where under AIX the modules were not building at 
all. On a machine where Python is not installed it was 
looking for ld_so_aix in /usr/local/lib/...wherever instead 
of in Modules/ld_so_aix.

The linking problem simply changes a $(LINKCC) to \.

Let me know if this sucks. :-) It seems to work fine 
building under Linux (RHL 7.2) with the patches, but that 
certainly is not a comprehensive test.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-14 10:34

Message:
Logged In: YES 
user_id=485432

Okay, I'll take a look. I should be able to find the 
appropriate spots in configure.in/Makefile.pre.in for the 
$(CC). The problem didn't look so straightforward yesterday 
when I was prowling around in there. :-) Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 01:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 22:29:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 14:29:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-531616 ] HTTPS not working
Message-ID: <E16n5cs-000690-00@usw-sf-web4.sourceforge.net>

Bugs item #531616, was opened at 2002-03-18 17:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPS not working 

Initial Comment:
Opening https:// URLs doesn't work for me with 2.2.1.  If I drop back to 
rev. 1.43 of httplib.py, it works again, so something happened with 
the big sendall() patch to break HTTPS.  

To see the bug, try running 
urllib.py with the -t switch:


---------- https://synergy.as.cmu.edu/~geek/ ----------

Traceback (most recent call last):
  File "urllib.py", line 1453, in ?
    
main()
  File "urllib.py", line 1444, in main
    test(args)
  File 
"urllib.py", line 1406, in test
    fn, h = urlretrieve(url, None, 
reporthook)
  File "urllib.py", line 80, in urlretrieve
    return 
_urlopener.retrieve(url, filename, reporthook, data)
  File 
"urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File 
"urllib.py", line 178, in open
    return getattr(self, name)(url)
  File 
"urllib.py", line 373, in open_https
    errcode, errmsg, headers = 
h.getreply()
  File "/data/python2/dist/src/Lib/httplib.py", line 
727, in getreply
    response = self._conn.getresponse()
  File 
"/data/python2/dist/src/Lib/httplib.py", line 572, in getresponse
    
response = self.response_class(self.sock)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 98, in __init__
    
self.fp = sock.makefile('rb', 0)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 607, in makefile
    
buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version
number')
ute 
Lib>



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 22:54:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 14:54:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-531616 ] HTTPS not working
Message-ID: <E16n60x-0003Wb-00@usw-sf-web3.sourceforge.net>

Bugs item #531616, was opened at 2002-03-18 17:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPS not working 

Initial Comment:
Opening https:// URLs doesn't work for me with 2.2.1.  If I drop back to 
rev. 1.43 of httplib.py, it works again, so something happened with 
the big sendall() patch to break HTTPS.  

To see the bug, try running 
urllib.py with the -t switch:


---------- https://synergy.as.cmu.edu/~geek/ ----------

Traceback (most recent call last):
  File "urllib.py", line 1453, in ?
    
main()
  File "urllib.py", line 1444, in main
    test(args)
  File 
"urllib.py", line 1406, in test
    fn, h = urlretrieve(url, None, 
reporthook)
  File "urllib.py", line 80, in urlretrieve
    return 
_urlopener.retrieve(url, filename, reporthook, data)
  File 
"urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File 
"urllib.py", line 178, in open
    return getattr(self, name)(url)
  File 
"urllib.py", line 373, in open_https
    errcode, errmsg, headers = 
h.getreply()
  File "/data/python2/dist/src/Lib/httplib.py", line 
727, in getreply
    response = self._conn.getresponse()
  File 
"/data/python2/dist/src/Lib/httplib.py", line 572, in getresponse
    
response = self.response_class(self.sock)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 98, in __init__
    
self.fp = sock.makefile('rb', 0)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 607, in makefile
    
buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version
number')
ute 
Lib>



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-18 17:54

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.47 of httplib.py.  

The FakeSocket class needed a 
sendall method.  Without it, the sendall() call got the method on the 
underlying socket object, and that messed up SSL.

That fixes this 
particular bug.  httplib may use other methods of sockets that FakeSocket 
doesn't support; I'll try to scan the code and check.  (I'll leave this bug open 
until that's done.)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470


From noreply@sourceforge.net  Mon Mar 18 23:12:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 15:12:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-531616 ] HTTPS not working
Message-ID: <E16n6J5-0003lx-00@usw-sf-web3.sourceforge.net>

Bugs item #531616, was opened at 2002-03-18 17:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: A.M. Kuchling (akuchling)
Summary: HTTPS not working 

Initial Comment:
Opening https:// URLs doesn't work for me with 2.2.1.  If I drop back to 
rev. 1.43 of httplib.py, it works again, so something happened with 
the big sendall() patch to break HTTPS.  

To see the bug, try running 
urllib.py with the -t switch:


---------- https://synergy.as.cmu.edu/~geek/ ----------

Traceback (most recent call last):
  File "urllib.py", line 1453, in ?
    
main()
  File "urllib.py", line 1444, in main
    test(args)
  File 
"urllib.py", line 1406, in test
    fn, h = urlretrieve(url, None, 
reporthook)
  File "urllib.py", line 80, in urlretrieve
    return 
_urlopener.retrieve(url, filename, reporthook, data)
  File 
"urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File 
"urllib.py", line 178, in open
    return getattr(self, name)(url)
  File 
"urllib.py", line 373, in open_https
    errcode, errmsg, headers = 
h.getreply()
  File "/data/python2/dist/src/Lib/httplib.py", line 
727, in getreply
    response = self._conn.getresponse()
  File 
"/data/python2/dist/src/Lib/httplib.py", line 572, in getresponse
    
response = self.response_class(self.sock)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 98, in __init__
    
self.fp = sock.makefile('rb', 0)
  File 
"/data/python2/dist/src/Lib/httplib.py", line 607, in makefile
    
buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version
number')
ute 
Lib>



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-18 18:12

Message:
Logged In: YES 
user_id=11375

The httplib inspection took less time than I thought, and there don't seem to 
be any other methods that are necessary.
(The makefile() method of 
FakeSocket is rather frightening, though, and I wonder if it would work 
correctly in the face of pipelining, but that's not related to this 
bug.)

Marking as closed, ending this dialogue with myself.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-18 17:54

Message:
Logged In: YES 
user_id=11375

Fixed in revision 1.47 of httplib.py.  

The FakeSocket class needed a 
sendall method.  Without it, the sendall() call got the method on the 
underlying socket object, and that messed up SSL.

That fixes this 
particular bug.  httplib may use other methods of sockets that FakeSocket 
doesn't support; I'll try to scan the code and check.  (I'll leave this bug open 
until that's done.)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531616&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 03:33:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 18 Mar 2002 19:33:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-530143 ] Typo in 3.16 copy_reg doc
Message-ID: <E16nANr-0000vM-00@usw-sf-web4.sourceforge.net>

Bugs item #530143, was opened at 2002-03-14 21:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in 3.16 copy_reg doc

Initial Comment:
On the page at <http://www.python.org/doc/current/lib/module-copyreg.html> in the second 
half about the pickle function, it says, in part:

> pickle(type, function[, constructor]) 
>     Declares that function should be used as a ``reduction'' function for objects of type type;
>     type should not a class object. function should return either a string or a tuple containing 
>     two or three elements. 

The part that says "type should not a class object" seems wrong. I think it should probably be 
"type should be a class object".


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-18 22:33

Message:
Logged In: YES 
user_id=3066

Actually, the docs are right, aside from not being very
clear.  This functionality is there to support extension
types introduced before the __reduce__() method was defined
in the pickle protocol.

I've clarified this in Doc/lib/libcopyreg.tex revisions
1.10.8.1 and 1.11.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 14:41:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 06:41:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16nKnO-0003wJ-00@usw-sf-web1.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 13:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-19 15:41

Message:
Logged In: YES 
user_id=21627

Isn't there also some interaction with sre_compile.MAXCODE?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-18 19:48

Message:
Logged In: YES 
user_id=33168

Fixed in revision: 2.22.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 14:00

Message:
Logged In: YES 
user_id=6656

That was easy enough; fixed in revision 2.21.16.1 of
Modules/sre.h.

Will need to go onto the trunk, later...

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 23:10

Message:
Logged In: YES 
user_id=38376

as neal points out, the 3rd define (after the #endif)
should be removed.

(my CVS workspace is broken right now, so I cannot
patch this myself -- at least not tonight...)

</F>

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 19:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 18:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 15:16:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 07:16:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-529713 ] Linking under AIX failing
Message-ID: <E16nLLu-0007Gi-00@usw-sf-web4.sourceforge.net>

Bugs item #529713, was opened at 2002-03-14 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bob Plankers (plankers)
Assigned to: Nobody/Anonymous (nobody)
Summary: Linking under AIX failing

Initial Comment:
I am encountering a situation where Python fails to 
link after compiling under AIX, using the VisualAge 
C/C++ 5.0 compilers. After configuring the source with:

env CC=cc CXX=xlC ./configure --prefix=/usr/local --
host=rs6000-ibm-aix4.3.3.0

I issue a 'make' which runs properly until it attempts 
to link:

        ar cr libpython2.2.a Modules/config.o  
Modules/getpath.o  Modules/main.o  Modules/gcmodule.o 
        ar cr libpython2.2.a Modules/threadmodule.o  
Modules/signalmodule.o  Modules/posixmodule.o  
Modules/_sre.o  Modules/newmodule.o  
Modules/symtablemodule.o  Modules/xxsubtype.o
        ranlib libpython2.2.a
        ./Modules/makexp_aix Modules/python.exp "" 
libpython2.2.a;   -Wl,-bE:Modules/python.exp -lld -o 
python  Modules/python.o  libpython2.2.a -ldl    -lm  
/bin/sh: -Wl,-bE:Modules/python.exp:  not found
make: The error code from the last command is 127.


Stop.


...at this point, I can manually issue that last  
command, inserting a "cc_r" before the -Wl,-
bE:Modules/python.exp in the command.

In looking at the Makefile generated, it appears that 
the command to link Python is being issued without the 
proper $(CC) in it. The relative section in the 
Makefile is under "# Build the interpreter". I am not 
familiar with the platform specific build options or 
autoconf, but if you have questions or would like more 
information let me know (bob@plankers.com).

Thank you!

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-19 16:16

Message:
Logged In: YES 
user_id=21627

It turns out that the Makefile.pre.in change was already
made in Makefile.pre.in 1.74; the configure.in change was
made for the AIX case was made in configure.in 1.295.

I applied your change to the Monterey64 and dgux cases as
configure.in 1.298.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-18 22:30

Message:
Logged In: YES 
user_id=485432

Okay, try this. The old value of $LINKCC wasn't being 
appended to the new value for $LINKCC. Removing the 
parentheses helps.

I took the liberty of doing that for the Monterey64 and 
dgux entries as well. It works nicely for AIX.

The new patch contains the Makefile.pre.in changes, too.

Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 10:11

Message:
Logged In: YES 
user_id=21627

The chunk on changing LDSHARED to BLDSHARED is definitely right.

On the chunk using $(CC) - I cannot really see why this is
necessary. Right above the AIX assignment of LINKCC, there
is a test with three alternatives ($CXX is empty, it is
needed to link a C++ program, it is not needed). In either
case, LINKCC is set. So it is surprising why LINKCC is then
not set in the right-hand side of the AIX assignment.

Can you please investigate? Perhaps putting echo statements
would be sufficient, or 'set -x' right above that entire
chain of if statements.

Notice that I hesitate to accept your patch because we also
have bug reports where user complain that LINKCC should use
the C++ compiler if available. The test is designed to
enable that feature; your patch would break it.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-15 07:34

Message:
Logged In: YES 
user_id=485432

I am attaching a patch for the linking problem, as well as 
a problem where under AIX the modules were not building at 
all. On a machine where Python is not installed it was 
looking for ld_so_aix in /usr/local/lib/...wherever instead 
of in Modules/ld_so_aix.

The linking problem simply changes a $(LINKCC) to \.

Let me know if this sucks. :-) It seems to work fine 
building under Linux (RHL 7.2) with the patches, but that 
certainly is not a comprehensive test.

----------------------------------------------------------------------

Comment By: Bob Plankers (plankers)
Date: 2002-03-14 17:34

Message:
Logged In: YES 
user_id=485432

Okay, I'll take a look. I should be able to find the 
appropriate spots in configure.in/Makefile.pre.in for the 
$(CC). The problem didn't look so straightforward yesterday 
when I was prowling around in there. :-) Thanks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-14 08:21

Message:
Logged In: YES 
user_id=21627

Nobody of us has acccess to an AIX system, so if you cannot
figure out what to change, nobody can.

If you suspect that $(CC) needs to be added to some of the
commands, locate the command in the Makefile, and try
whether it works. Then please attach both the original and
the modified Makefile to this report. In turn, we can try to
produce a patch to configure.in which should make it add the
$(CC) automatically. You will then need to verify that the
patch works correctly, at which time we can apply it to the
Python source code in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529713&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 15:26:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 07:26:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-527521 ] httplib test causes SSL core dump
Message-ID: <E16nLVX-0007LD-00@usw-sf-web4.sourceforge.net>

Bugs item #527521, was opened at 2002-03-08 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib test causes SSL core dump

Initial Comment:
The test() function in the httplib module attempts to 
connect to SourceForge using SSL.  I've tried this 
with Python 2.1 and up, using OpenSSL 0.9.6.  The read 
call fails with an SSL error, then python dumps core 
instead OpenSSL.

I don't know if this is a Python bug or an SSL bug.  
At first blush, I'd guess that Python is probably 
using OpenSSL incorrectly.

Here's the Python traceback.

Traceback (most recent call last):
  File "../Lib/httplib.py", line 895, in ?
    test()
  File "../Lib/httplib.py", line 884, in test
    status, reason, headers = hs.getreply()
  File "../Lib/httplib.py", line 734, in getreply
    response = self._conn.getresponse()
  File "../Lib/httplib.py", line 579, in getresponse
    response = self.response_class(self.sock)
  File "../Lib/httplib.py", line 99, in __init__
    self.fp = sock.makefile('rb', 0)
  File "../Lib/httplib.py", line 614, in makefile
    buf = self.__ssl.read()
socket.sslerror: (1, 'error:1408F10B:SSL 
routines:SSL3_GET_RECORD:wrong version number')

And the gdb stack trace.

#0 0x401e96d1 in sk_pop_free () 
from /usr/local/ssl/lib/libcrypto.so.0.9.6
(gdb) bt
#0 0x401e96d1 in sk_pop_free () 
from /usr/local/ssl/lib/libcrypto.so.0.9.6
#1 0x40191068 in __DTOR_END__ () 
from /usr/local/ssl/lib/libssl.so.0.9.6
#2 0xe853 in ?? ()
Cannot access memory at address 0x5614ec83.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-19 10:26

Message:
Logged In: YES 
user_id=11375

This looks like a duplicate of bug #531616, though I 
didn't see Python dump core.  Try it with the current 
httplib in CVS; it should be fixed.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527521&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 15:41:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 07:41:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-526548 ] tixwidgets.py improperly indented
Message-ID: <E16nLjb-0003iG-00@usw-sf-web1.sourceforge.net>

Bugs item #526548, was opened at 2002-03-06 13:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526548&group_id=5470

Category: Demos and Tools
Group: Python 2.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Don Rozenberg (rozen)
Assigned to: Nobody/Anonymous (nobody)
Summary: tixwidgets.py improperly indented

Initial Comment:
Python-2.2/Demo/tix/tixwidgets.py is improperly 
indented and will not run.

I am attaching a working version.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-19 10:41

Message:
Logged In: YES 
user_id=11375

This is likely a duplicate of bug #517447, and is fixed in 
the current CVS tree.  Thanks for your report!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526548&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 15:45:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 07:45:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-530285 ] redefining SRE_CODE in Modules/sre.h
Message-ID: <E16nLo2-0004ZP-00@usw-sf-web3.sourceforge.net>

Bugs item #530285, was opened at 2002-03-15 07:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fredrik Lundh (effbot)
Summary: redefining SRE_CODE in Modules/sre.h

Initial Comment:
Taken from Modules/sre.h:

/* size of a code word (must be unsigned short or
   larger, and
   large enough to hold a Py_UNICODE character) */
#ifdef Py_UNICODE_WIDE
#define SRE_CODE unsigned long
#else
#define SRE_CODE unsigned short
#endif

#define SRE_CODE unsigned short

------------------

SRE_CODE is always an unsigned short.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-19 10:45

Message:
Logged In: YES 
user_id=33168

I'm not sure.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-19 09:41

Message:
Logged In: YES 
user_id=21627

Isn't there also some interaction with sre_compile.MAXCODE?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-18 13:48

Message:
Logged In: YES 
user_id=33168

Fixed in revision: 2.22.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 08:00

Message:
Logged In: YES 
user_id=6656

That was easy enough; fixed in revision 2.21.16.1 of
Modules/sre.h.

Will need to go onto the trunk, later...

----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2002-03-17 17:10

Message:
Logged In: YES 
user_id=38376

as neal points out, the 3rd define (after the #endif)
should be removed.

(my CVS workspace is broken right now, so I cannot
patch this myself -- at least not tonight...)

</F>

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-15 13:05

Message:
Logged In: YES 
user_id=33168

Regardless of the value of Py_UNICODE_WIDE, SRE_CODE will be
defined to unsigned short after the #ifdef because of the
#define after the #ifdef.

There is actually a warning produced that SRE_CODE is
redefined if Py_UNICODE_WIDE is set.

If SRE_CODE needs to be differerent, the 3rd #define of
SRE_CODE should be removed.  I tried this a while ago and
purify reported more errors.  (purify is still broken, so I
can't give any current info.)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-15 12:50

Message:
Logged In: YES 
user_id=21627

What do you mean with "SRE_CODE is always an unsigned
short"; if sre.h defines it as something different, it is
different.

It also needs to be different for Py_UNICODE_WIDE: For
SRE_OP_LITERAL, a Py_UNICODE is the argument. If Py_UNICODE
is 4 bytes, SRE_CODE must be also four bytes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530285&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 15:53:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 07:53:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-515434 ] Very slow performance
Message-ID: <E16nLvw-0007bW-00@usw-sf-web4.sourceforge.net>

Bugs item #515434, was opened at 2002-02-09 23:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515434&group_id=5470

Category: Regular Expressions
Group: Not a Bug
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Andy Miller (ajmiller)
Assigned to: Fredrik Lundh (effbot)
Summary: Very slow performance

Initial Comment:
While performance testing the RE module came across a 
case where it runs very slow (processing 4 or 5 lines 
of text per second on a P700 !!)

See the attached program for details

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-19 10:53

Message:
Logged In: YES 
user_id=11375

Marking as closed.

----------------------------------------------------------------------

Comment By: Andy Miller (ajmiller)
Date: 2002-02-10 15:13

Message:
Logged In: YES 
user_id=447946

I certainly agree that regular expressions can be fine 
tuned and some run faster than others - unfortunately the 
case in point runs very fast in Perl (the problem was 
originally found when replacing some Perl functionality 
with Python !)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 01:49

Message:
Logged In: YES 
user_id=31435

Patterns with highly ambiguous subpatterns (like your 
\w+.+\d+) may run extremely slowly in Python, or Perl, or 
any other language with a backtracking regexp engine.  See 
Friedl's "Mastering Regular Expressions" (O'Reilly) for an 
explanation.  You can learn how to write zippy regexps 
faster than fundamental consequences of the matching 
algorithm can be wished away <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515434&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 16:04:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 08:04:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-528914 ] PyTraceBack_Store/Fetch are absent
Message-ID: <E16nM6d-0007PN-00@usw-sf-web2.sourceforge.net>

Bugs item #528914, was opened at 2002-03-12 06:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528914&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yakov Markovitch (markovitch)
>Assigned to: A.M. Kuchling (akuchling)
Summary: PyTraceBack_Store/Fetch are absent

Initial Comment:
The implementations of PyTraceBack_Store and
PyTraceBack_Fetch functions are absent, though their
declarations are present in traceback.h.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-19 11:04

Message:
Logged In: YES 
user_id=11375

These functions were removed in 1997 (!).  The prototypes 
are removed as of rev. 2.19 of traceback.h.  

Thanks for your bug report!



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528914&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 16:20:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 08:20:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-514627 ] pydoc fails to generate html doc
Message-ID: <E16nMLK-0007rU-00@usw-sf-web4.sourceforge.net>

Bugs item #514627, was opened at 2002-02-07 21:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514627&group_id=5470

Category: Demos and Tools
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Raj Kunjithapadam (mmaster25)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc fails to generate html doc

Initial Comment:
pydoc on the python 2.2 distribution fails to generate
html doc(when option -w is given)
Traceback follows

Traceback (most recent call last):
  File "/opt/dump/Python-2.2/Lib/pydoc.py", line 2101, in ?
    if __name__ == '__main__': cli()
  File "/opt/dump/Python-2.2/Lib/pydoc.py", line 2070,
in cli
    writedoc(arg)
  File "/opt/dump/Python-2.2/Lib/pydoc.py", line 1341,
in writedoc
    object = locate(key, forceload)
  File "/opt/dump/Python-2.2/Lib/pydoc.py", line 1293,
in locate
    parts = split(path, '.')
  File "/opt/dump/Python-2.2/Lib/string.py", line 117,
in split
    return s.split(sep, maxsplit)
AttributeError: 'module' object has no attribute 'split'


On further investigation I was able to fix it.
Attached is the fix.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-19 11:20

Message:
Logged In: YES 
user_id=11375

Attaching a diff for Raj's modified version of pydoc.py, 
so the changes are clearly visible.




----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-10 13:04

Message:
Logged In: YES 
user_id=92689

I can reproduce the traceback by going into the Python 
src dir and typing
% pydoc -w Lib/os.py
The problem begins in cli(): writedoc() expects a string 
but arg as just been assigned a module by 
importfile(arg). I don't understand what's supposed to 
happen, but I doubt Raj's patch is the proper solution.
(Not sure how helpful this was, but Skip's cron job is 
pretty cool... ;-)

----------------------------------------------------------------------

Comment By: Raj Kunjithapadam (mmaster25)
Date: 2002-02-09 22:03

Message:
Logged In: YES 
user_id=452533

the commandline was
$pydoc -w <name of my python sourcefile>
I cannot give you the exact commandline and traceback as
I am unable to get thru my VPN now.
But I am pretty sure that was the commandline.

Refer to [ #514628 ] bug in pydoc on python 2.2 release
in Python - Patches.
--Raj


----------------------------------------------------------------------

Comment By: Raj Kunjithapadam (mmaster25)
Date: 2002-02-09 21:54

Message:
Logged In: YES 
user_id=452533

It happened to me on Redhat Linux 7.1
when I ran pydoc using the -w option to generate html output.

-w invokes the writedoc method and it expects an arg(filename)
instead of the module object returned by imp_load.

I have also submitted a fix for this.
Thanks for following up on this quickly.
--Raj


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 16:48

Message:
Logged In: YES 
user_id=6380

I want to believe you, but I cannot reproduce the traceback.
Can you tell me which command line you used to cause the
traceback, and on which operating system?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514627&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 16:34:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 08:34:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-530143 ] Typo in 3.16 copy_reg doc
Message-ID: <E16nMZA-00050u-00@usw-sf-web3.sourceforge.net>

Bugs item #530143, was opened at 2002-03-14 18:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470

Category: Documentation
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Typo in 3.16 copy_reg doc

Initial Comment:
On the page at <http://www.python.org/doc/current/lib/module-copyreg.html> in the second 
half about the pickle function, it says, in part:

> pickle(type, function[, constructor]) 
>     Declares that function should be used as a ``reduction'' function for objects of type type;
>     type should not a class object. function should return either a string or a tuple containing 
>     two or three elements. 

The part that says "type should not a class object" seems wrong. I think it should probably be 
"type should be a class object".


----------------------------------------------------------------------

>Comment By: Martin Miller (mrmiller)
Date: 2002-03-19 08:34

Message:
Logged In: YES 
user_id=257085

"type should not a class object" is not a complete sentence in English and is incorrect (if it means what I 
can only guess it means). In other words, I think the type argument to the pickle() function here "should be 
a class object". My comments are not about the need for the function or its functionality, so the response 
that "Actually, the docs are right." seems inappropriate...



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-18 19:33

Message:
Logged In: YES 
user_id=3066

Actually, the docs are right, aside from not being very
clear.  This functionality is there to support extension
types introduced before the __reduce__() method was defined
in the pickle protocol.

I've clarified this in Doc/lib/libcopyreg.tex revisions
1.10.8.1 and 1.11.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530143&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 17:37:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 09:37:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] breaking file iter loop leaves file in stale state
Message-ID: <E16nNY0-0005ZS-00@usw-sf-web3.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breaking file iter loop leaves file in stale state

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-03-19 17:37

Message:
Logged In: YES 
user_id=10327

I'm in favor for the "let files be their own iterator and set .next equal to .readline" solution. The above example can _really_ bite you.

The current xreadlinesmodule.c could be converted to a standalone module, if it really is necessary to optimize.

The trivial solution for this problem is to change CHUNKSIZE (in Modules/xreadlinesmodule) to 1. Or, even better, to convert it into an instance variable, so you can do this:

f=open(...)
fi=f.iter(chunk=2000)
for line in fi:
    ...

if you want speed, or just write

for line in f:

(which internally converts to f.iter(chunk=1))

if you want safety.

I'm not too firm with Python C interfacing, otherwise I'd write a patch... any takers?

----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-08 09:35

Message:
Logged In: YES 
user_id=18139

Tim wrote: "I'm sure Guido was aware of this."

    ...Wow, really?  That kind of puts a damper on
       my theory.  I guess it can't be a bug after
       all.  :)

Tim wrote: "Making the simplest-to-spell idiom as fast as 
possible was a deliberate decision at the time."

    ...*That* I believe.


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-08 09:08

Message:
Logged In: YES 
user_id=92689

At the cost of, what, sensible, predictable semantics?
- fast is better than slow
- but slow is better than unpredictable
Or something...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 01:16

Message:
Logged In: YES 
user_id=31435

I'm sure Guido was aware of this.  Making the simplest-to-
spell idiom as fast as possible was a deliberate decision 
at the time.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 01:06

Message:
Logged In: YES 
user_id=31392

If I understand the checkin message Guido wrote for 2.113, 
he didn't intend the current behavior.

> file_getiter(): make iter(file) be equivalent to 
>file.xreadlines().
> This should be faster.
>
> This means:
>
> (1) "for line in file:" won't work if the xreadlines 
module can't be
>    imported.
>
> (2) The body of "for line in file:" shouldn't use the 
file directly;
>     the effects (e.g. of file.readline(), file.seek() or 
even
>     file.tell()) would be undefined because of the 
buffering that goes
>     on in the xreadlines module.


----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 06:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 18:06:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 10:06:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-531966 ] email: problems generating multipart msg
Message-ID: <E16nO0K-0000Fb-00@usw-sf-web2.sourceforge.net>

Bugs item #531966, was opened at 2002-03-19 13:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: email: problems generating multipart msg

Initial Comment:
As reported in comp.lang.python, the example program 
given in Doc/lib/email.tex to wrap up a whole 
directory as a MIME message doesn't work if the 
directory is empty or contains only a single file.

As that script is fairly long, I've attached a 
shorter example script which also demonstrates the 
bug; coincidentally, I hit it yesterday at work.
The script crashes with:

  File 
"/data/python2/dist/src/Lib/email/Generator.py", line 
236, in _handle_multipart
    for part in msg.get_payload():
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 152, in __getitem__
    return self.get(name)
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 215, in get
    name = name.lower()
AttributeError: 'int' object has no attribute 'lower'



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 18:06:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 10:06:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-531966 ] email: problems generating multipart msg
Message-ID: <E16nO0e-0000Fj-00@usw-sf-web2.sourceforge.net>

Bugs item #531966, was opened at 2002-03-19 13:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: email: problems generating multipart msg

Initial Comment:
As reported in comp.lang.python, the example program 
given in Doc/lib/email.tex to wrap up a whole 
directory as a MIME message doesn't work if the 
directory is empty or contains only a single file.

As that script is fairly long, I've attached a 
shorter example script which also demonstrates the 
bug; coincidentally, I hit it yesterday at work.
The script crashes with:

  File 
"/data/python2/dist/src/Lib/email/Generator.py", line 
236, in _handle_multipart
    for part in msg.get_payload():
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 152, in __getitem__
    return self.get(name)
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 215, in get
    name = name.lower()
AttributeError: 'int' object has no attribute 'lower'



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 19:36:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 11:36:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-532007 ] urllib ftp broken if Win32 proxy
Message-ID: <E16nPPf-0006Ea-00@usw-sf-web1.sourceforge.net>

Bugs item #532007, was opened at 2002-03-19 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Medberry (medberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib ftp broken if Win32 proxy

Initial Comment:
If Win32 has a proxy enabled, ftp urls will NOT work in
urllib.

Here is a trace:
Traceback (most recent call last):
  File
"C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
line 301, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Python22\Lib\urllib.py", line 1457, in ?
    main()
  File "C:\Python22\Lib\urllib.py", line 1448, in main
    test(args)
  File "C:\Python22\Lib\urllib.py", line 1410, in test
    fn, h = urlretrieve(url, None, reporthook)
  File "C:\Python22\Lib\urllib.py", line 80, in urlretrieve
    return _urlopener.retrieve(url, filename,
reporthook, data)
  File "C:\Python22\Lib\urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File "C:\Python22\Lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\Lib\urllib.py", line 438, in open_ftp
    host, path = splithost(url)
  File "C:\Python22\Lib\urllib.py", line 944, in splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer

If the Win32 proxy is removed, it resumes working. In
urllib splithost, url is None or an empty tuple
(instead of the actual url.)

To reproduce, just enable a proxy on Win32 and execute
the "urllib.py -t" selftest. Disable the proxy and it
will be restored.

I haven't got the setup to check if web_proxy or
ftp_proxy on Posix machines causes the same problem.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 21:15:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 13:15:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-532115 ] netrc module broken:not parsing macdefs
Message-ID: <E16nQws-0008Gt-00@usw-sf-web3.sourceforge.net>

Bugs item #532115, was opened at 2002-03-19 21:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532115&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Winston Collier (wacollier)
Assigned to: Nobody/Anonymous (nobody)
Summary: netrc module broken:not parsing macdefs

Initial Comment:
The netrc module on linux and Solaris (and probably all
other platforms, possibly on higher versions as well)
is not properly parsing the .netrc module for macro
definitions (macdef).  Its is supposed to return a
dictionary of strings with the macdef name being the
key, but instead it only parses the first macdef entry,
and returns everything else as the string list,
including the macdefs that follow the first on in the
file.  Its ignoring the extra '\n' that delimits the
end of a macdef and the new 'macdef' statement for
subsequent macros.

example:

in .netrc
............
machine ftpme.foo.com
        login luserhaxor
        password im3733t

macdef downloadfoo
cd test
bin
get foo.test
quit

macdef uploadfoo
cd test
bin
put foo.test
quit

............
python:
............
>>> import netrc
>>> foo=netrc.netrc()
>>> foo.macros
{'downloadfoo': ['cd test\n', 'bin\n', 'get
foo.test\n', 'quit\n', '\n', 'macdef uploadfoo\n', 'cd
test\n', 'bin\n', 'put foo.test\n', 'quit\n', '\n']}
>>> foo.macros['downloadfoo']
['cd test\n', 'bin\n', 'get foo.test\n', 'quit\n',
'\n', 'macdef uploadfoo\n', 'cd test\n', 'bin\n', 'put
foo.test\n', 'quit\n', '\n']
>>> foo.macros['uploadfoo']
Traceback (most recent call last):
  File "<pyshell#45>", line 1, in ?
    foo.macros['uploadfoo']
KeyError: uploadfoo
>>> 

As you can see, its broken as far as parsing macdefs
into a dictionary goes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532115&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 21:25:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 13:25:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-532136 ] README seems wrong.
Message-ID: <E16nR76-0007X3-00@usw-sf-web1.sourceforge.net>

Bugs item #532136, was opened at 2002-03-19 21:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: README seems wrong.

Initial Comment:
Hi,

README says:

    IMPORTANT: If the tests fail and you decide to mail
a bug report,
    *don't* include the output of "make test".  It is
useless.  Run the
    failing test manually, as follows:

            python ../Lib/test/test_whatever.py

    (substituting the top of the source tree for .. if
you built in a
    different directory).  This runs the test in
verbose mode.

I suggest it would be better to write `./python'
otherwise the old,
installed, version is found by users that don't have
the current
directory in their path.

Also, at this point we're in the top level source
directory, so the 
newly built python is ./python.  So Lib isn't ../Lib
but ./Lib, i.e. 
it's in the current directory.  Consequently, the text
about 
substituting the top of the source tree for .. is right
if you built it 
in a different directory.  However, even if you built
it in the current 
directory you still need to substitute the .. AFAICS.

Cheers,


Ralph.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 21:34:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 13:34:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-532136 ] README seems wrong.
Message-ID: <E16nRFp-0007dr-00@usw-sf-web1.sourceforge.net>

Bugs item #532136, was opened at 2002-03-19 21:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 3
Submitted By: Ralph Corderoy (ralph)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: README seems wrong.

Initial Comment:
Hi,

README says:

    IMPORTANT: If the tests fail and you decide to mail
a bug report,
    *don't* include the output of "make test".  It is
useless.  Run the
    failing test manually, as follows:

            python ../Lib/test/test_whatever.py

    (substituting the top of the source tree for .. if
you built in a
    different directory).  This runs the test in
verbose mode.

I suggest it would be better to write `./python'
otherwise the old,
installed, version is found by users that don't have
the current
directory in their path.

Also, at this point we're in the top level source
directory, so the 
newly built python is ./python.  So Lib isn't ../Lib
but ./Lib, i.e. 
it's in the current directory.  Consequently, the text
about 
substituting the top of the source tree for .. is right
if you built it 
in a different directory.  However, even if you built
it in the current 
directory you still need to substitute the .. AFAICS.

Cheers,


Ralph.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 22:44:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 14:44:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-532007 ] urllib ftp broken if Win32 proxy
Message-ID: <E16nSLd-0000uO-00@usw-sf-web3.sourceforge.net>

Bugs item #532007, was opened at 2002-03-19 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Medberry (medberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib ftp broken if Win32 proxy

Initial Comment:
If Win32 has a proxy enabled, ftp urls will NOT work in
urllib.

Here is a trace:
Traceback (most recent call last):
  File
"C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
line 301, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Python22\Lib\urllib.py", line 1457, in ?
    main()
  File "C:\Python22\Lib\urllib.py", line 1448, in main
    test(args)
  File "C:\Python22\Lib\urllib.py", line 1410, in test
    fn, h = urlretrieve(url, None, reporthook)
  File "C:\Python22\Lib\urllib.py", line 80, in urlretrieve
    return _urlopener.retrieve(url, filename,
reporthook, data)
  File "C:\Python22\Lib\urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File "C:\Python22\Lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\Lib\urllib.py", line 438, in open_ftp
    host, path = splithost(url)
  File "C:\Python22\Lib\urllib.py", line 944, in splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer

If the Win32 proxy is removed, it resumes working. In
urllib splithost, url is None or an empty tuple
(instead of the actual url.)

To reproduce, just enable a proxy on Win32 and execute
the "urllib.py -t" selftest. Disable the proxy and it
will be restored.

I haven't got the setup to check if web_proxy or
ftp_proxy on Posix machines causes the same problem.



----------------------------------------------------------------------

>Comment By: David Medberry (medberry)
Date: 2002-03-19 15:44

Message:
Logged In: YES 
user_id=95087

This is _NOT_ a bug under Linux Python 2.2--it works just
fine there. (Makes me curious why it would behave
differently under Windows, but I'm not sure where to look yet.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470


From noreply@sourceforge.net  Tue Mar 19 22:46:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 14:46:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-532007 ] urllib ftp broken if Win32 proxy
Message-ID: <E16nSN5-0000vv-00@usw-sf-web3.sourceforge.net>

Bugs item #532007, was opened at 2002-03-19 12:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Medberry (medberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib ftp broken if Win32 proxy

Initial Comment:
If Win32 has a proxy enabled, ftp urls will NOT work in
urllib.

Here is a trace:
Traceback (most recent call last):
  File
"C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
line 301, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Python22\Lib\urllib.py", line 1457, in ?
    main()
  File "C:\Python22\Lib\urllib.py", line 1448, in main
    test(args)
  File "C:\Python22\Lib\urllib.py", line 1410, in test
    fn, h = urlretrieve(url, None, reporthook)
  File "C:\Python22\Lib\urllib.py", line 80, in urlretrieve
    return _urlopener.retrieve(url, filename,
reporthook, data)
  File "C:\Python22\Lib\urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File "C:\Python22\Lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\Lib\urllib.py", line 438, in open_ftp
    host, path = splithost(url)
  File "C:\Python22\Lib\urllib.py", line 944, in splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer

If the Win32 proxy is removed, it resumes working. In
urllib splithost, url is None or an empty tuple
(instead of the actual url.)

To reproduce, just enable a proxy on Win32 and execute
the "urllib.py -t" selftest. Disable the proxy and it
will be restored.

I haven't got the setup to check if web_proxy or
ftp_proxy on Posix machines causes the same problem.



----------------------------------------------------------------------

>Comment By: David Medberry (medberry)
Date: 2002-03-19 15:46

Message:
Logged In: YES 
user_id=95087

<bold>Is this bold?</bold>

----------------------------------------------------------------------

Comment By: David Medberry (medberry)
Date: 2002-03-19 15:44

Message:
Logged In: YES 
user_id=95087

This is _NOT_ a bug under Linux Python 2.2--it works just
fine there. (Makes me curious why it would behave
differently under Windows, but I'm not sure where to look yet.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 03:43:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 19 Mar 2002 19:43:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] breaking file iter loop leaves file in stale state
Message-ID: <E16nX0E-0004Ac-00@usw-sf-web3.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 10:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breaking file iter loop leaves file in stale state

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-19 22:43

Message:
Logged In: YES 
user_id=6380

There are two forces at work here.

You want the most common case (a single "for line in file"
that consumes the whole file) to run blindingly fast.

And you want full generality, basically equating next() with
readline() (except raising StopIteration on EOF).

Unfortunately, the only way to go blindingly fast is to do
aggressive buffering, and that's what xreadlines does. Until
we rewrite the entire I/O system so we have total control
over buffering ourselves, it's not easy to mix xreadlines
with other operations (readline, seek, tell).

We could make the default file iterator use readline, but
then it would become much slower, and we'd have to teach
people about xreadlines if they want speed. Or we could use
the current solution, where speed is the default, and you
have to be more careful when you use an unusual coding
style, like breaking out of the for loop and continuing in a
second for loop.

I'm not sure which requirement is more common (speed, or
generality), but since looping over all the lines of a (big)
file is such a common pattern, I would bet the speed is the
more important of the two.

In the past we've had a lot of flak about the slowness of
the general solution of looping over all lines in a file;
the xreadlines-based iterator is much faster, and I am
reluctant to change this back in Python 2.3; I'd rather
document it carefully (after all, "for line in lines" is a
new construct in Python 2.2, and people have to be told
about it; we might as well tell them about the limitations
and how to work around them).

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-03-19 12:37

Message:
Logged In: YES 
user_id=10327

I'm in favor for the "let files be their own iterator and set .next equal to .readline" solution. The above example can _really_ bite you.

The current xreadlinesmodule.c could be converted to a standalone module, if it really is necessary to optimize.

The trivial solution for this problem is to change CHUNKSIZE (in Modules/xreadlinesmodule) to 1. Or, even better, to convert it into an instance variable, so you can do this:

f=open(...)
fi=f.iter(chunk=2000)
for line in fi:
    ...

if you want speed, or just write

for line in f:

(which internally converts to f.iter(chunk=1))

if you want safety.

I'm not too firm with Python C interfacing, otherwise I'd write a patch... any takers?

----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-08 04:35

Message:
Logged In: YES 
user_id=18139

Tim wrote: "I'm sure Guido was aware of this."

    ...Wow, really?  That kind of puts a damper on
       my theory.  I guess it can't be a bug after
       all.  :)

Tim wrote: "Making the simplest-to-spell idiom as fast as 
possible was a deliberate decision at the time."

    ...*That* I believe.


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-08 04:08

Message:
Logged In: YES 
user_id=92689

At the cost of, what, sensible, predictable semantics?
- fast is better than slow
- but slow is better than unpredictable
Or something...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-07 20:16

Message:
Logged In: YES 
user_id=31435

I'm sure Guido was aware of this.  Making the simplest-to-
spell idiom as fast as possible was a deliberate decision 
at the time.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-07 20:06

Message:
Logged In: YES 
user_id=31392

If I understand the checkin message Guido wrote for 2.113, 
he didn't intend the current behavior.

> file_getiter(): make iter(file) be equivalent to 
>file.xreadlines().
> This should be faster.
>
> This means:
>
> (1) "for line in file:" won't work if the xreadlines 
module can't be
>    imported.
>
> (2) The body of "for line in file:" shouldn't use the 
file directly;
>     the effects (e.g. of file.readline(), file.seek() or 
even
>     file.tell()) would be undefined because of the 
buffering that goes
>     on in the xreadlines module.


----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 01:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 09:04:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 01:04:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-532388 ] reverse copy of sequence returns None
Message-ID: <E16nc10-0006dF-00@usw-sf-web1.sourceforge.net>

Bugs item #532388, was opened at 2002-03-20 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bing Ren (renbing)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse copy of sequence returns None

Initial Comment:
I tried to get a reversed sequence and keep the 
original, so I tried this:

>>> a=[1,2,3,4]
>>> b=(a[:]).reverse()
>>> b
>>> b=a[:]
>>> b.reverse()
>>> b
[4, 3, 2, 1]
>>>

I think this should be a bug. I tried to search this 
bug but get no result. Hope my submit helps.

My version:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 09:05:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 01:05:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-532388 ] reverse copy of sequence returns None
Message-ID: <E16nc2Q-0006eI-00@usw-sf-web1.sourceforge.net>

Bugs item #532388, was opened at 2002-03-20 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
>Priority: 7
Submitted By: Bing Ren (renbing)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse copy of sequence returns None

Initial Comment:
I tried to get a reversed sequence and keep the 
original, so I tried this:

>>> a=[1,2,3,4]
>>> b=(a[:]).reverse()
>>> b
>>> b=a[:]
>>> b.reverse()
>>> b
[4, 3, 2, 1]
>>>

I think this should be a bug. I tried to search this 
bug but get no result. Hope my submit helps.

My version:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 09:15:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 01:15:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-532388 ] reverse copy of sequence returns None
Message-ID: <E16ncBk-0006lY-00@usw-sf-web1.sourceforge.net>

Bugs item #532388, was opened at 2002-03-20 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470

Category: None
>Group: Not a Bug
Status: Open
Resolution: None
>Priority: 1
Submitted By: Bing Ren (renbing)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse copy of sequence returns None

Initial Comment:
I tried to get a reversed sequence and keep the 
original, so I tried this:

>>> a=[1,2,3,4]
>>> b=(a[:]).reverse()
>>> b
>>> b=a[:]
>>> b.reverse()
>>> b
[4, 3, 2, 1]
>>>

I think this should be a bug. I tried to search this 
bug but get no result. Hope my submit helps.

My version:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 09:16:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 01:16:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-532388 ] reverse copy of sequence returns None
Message-ID: <E16ncCf-0007jP-00@usw-sf-web3.sourceforge.net>

Bugs item #532388, was opened at 2002-03-20 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470

Category: None
Group: Not a Bug
>Status: Deleted
Resolution: None
Priority: 1
Submitted By: Bing Ren (renbing)
Assigned to: Nobody/Anonymous (nobody)
Summary: reverse copy of sequence returns None

Initial Comment:
I tried to get a reversed sequence and keep the 
original, so I tried this:

>>> a=[1,2,3,4]
>>> b=(a[:]).reverse()
>>> b
>>> b=a[:]
>>> b.reverse()
>>> b
[4, 3, 2, 1]
>>>

I think this should be a bug. I tried to search this 
bug but get no result. Hope my submit helps.

My version:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532388&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 13:37:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 05:37:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-532467 ] 6.9 The raise statement is confusing
Message-ID: <E16ngHB-0001Nx-00@usw-sf-web1.sourceforge.net>

Bugs item #532467, was opened at 2002-03-20 07:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Patrick K. O'Brien (pobrien)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: 6.9 The raise statement is confusing

Initial Comment:
The description supplied for "6.9 The raise statement" 
is confusing. In particular, it starts by explaining 
the intent of each "expresssion" and midway switches 
to "object" instead of expression. In particular, I 
can't make heads or tails out of the following passage:

"If the first object is a string, it then raises the 
exception identified by the first object, with the 
second one (or None) as its parameter. If the first 
object is a class or instance, it raises the exception 
identified by the class of the instance determined in 
the previous step, with the instance as its parameter."

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532467&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:09:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:09:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nkWx-0005kY-00@usw-sf-web3.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:15:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:15:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-532621 ] gzip.GzipFile needs an iterator
Message-ID: <E16nkcJ-0004v6-00@usw-sf-web1.sourceforge.net>

Bugs item #532621, was opened at 2002-03-20 13:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile needs an iterator

Initial Comment:
  In order to maintain the parallel between the GzipFile and normal 
file objects, an iterator should be defined.  This should be a very 
simple patch.

See:
 
http://groups.google.com/groups?hl=en&ie=utf-8&oe=utf-
8&th=faa18b5e51ec9cf0&rnum=1


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:26:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:26:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-532621 ] gzip.GzipFile needs an iterator
Message-ID: <E16nknU-00053U-00@usw-sf-web1.sourceforge.net>

Bugs item #532621, was opened at 2002-03-20 13:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile needs an iterator

Initial Comment:
  In order to maintain the parallel between the GzipFile and normal 
file objects, an iterator should be defined.  This should be a very 
simple patch.

See:
 
http://groups.google.com/groups?hl=en&ie=utf-8&oe=utf-
8&th=faa18b5e51ec9cf0&rnum=1


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 13:26

Message:
Logged In: YES 
user_id=6380

Feel free to submit a patch. It's not likely that one of the
core developers will find this urgent enough to bother.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:34:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:34:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-532631 ] Confusions in formatfloat
Message-ID: <E16nkuR-00061s-00@usw-sf-web3.sourceforge.net>

Bugs item #532631, was opened at 2002-03-20 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: Confusions in formatfloat

Initial Comment:
stringobject.c's formatfloat seems confused in a 
couple respects.

1. Testing "fabs(x)/1e25 >= 1e25" is pretty baffling.  
What is it intending to do?  If it means what it says, 
it should be the simpler "fabs(x) >= 1e50".  But maybe 
it really intended to test "fabs(x) >= 1e25".

2. The "worst case length calc" is fantasy in some %f 
cases.  It assumes there's one digit before the 
decimal point, but, e.g., '%.100f'% 1e49 produces 
dozens of digits before the decimal point.  We're 
saved from a buffer overrun thanks to the PyOS_snprintf
() following, but unclear that truncation is sensible 
here (e.g., the user asked for a precision of 100 
here, but only gets back 50 digits after the decimal 
point).

Complication:  we're deliberately replacing C's %f 
with C's %g in some cases, but the docs don't document 
the rules Python intends for %f.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532631&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:37:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:37:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-522426 ] undocumented argument in filecmp.cmpfile
Message-ID: <E16nkxb-0005CG-00@usw-sf-web1.sourceforge.net>

Bugs item #522426, was opened at 2002-02-25 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: undocumented argument in filecmp.cmpfile

Initial Comment:
The filecmp.cmpfiles function is described like 
this:

cmpfiles(dir1, dir2, common[, shallow[, 
use_statcache]]) 

The documentation doesn't point out what 
common is and I haven't been able to figure it out myself.

This is 
on my version of python (2.1 on Windows) and in the latest version.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 13:37

Message:
Logged In: YES 
user_id=33168

Attached is a patch from the docstring.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:37:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:37:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-532621 ] gzip.GzipFile needs an iterator
Message-ID: <E16nkxk-0005CK-00@usw-sf-web1.sourceforge.net>

Bugs item #532621, was opened at 2002-03-20 18:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: gzip.GzipFile needs an iterator

Initial Comment:
  In order to maintain the parallel between the GzipFile and normal 
file objects, an iterator should be defined.  This should be a very 
simple patch.

See:
 
http://groups.google.com/groups?hl=en&ie=utf-8&oe=utf-
8&th=faa18b5e51ec9cf0&rnum=1


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-20 18:37

Message:
Logged In: YES 
user_id=35752

Fixed in gzip.py 1.30 (just to prove Guido wrong :-).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 18:26

Message:
Logged In: YES 
user_id=6380

Feel free to submit a patch. It's not likely that one of the
core developers will find this urgent enough to bother.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532621&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:45:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:45:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nl5O-0008NS-00@usw-sf-web2.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 19:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 19:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:50:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:50:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-522426 ] undocumented argument in filecmp.cmpfile
Message-ID: <E16nlAX-0008RC-00@usw-sf-web2.sourceforge.net>

Bugs item #522426, was opened at 2002-02-25 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: undocumented argument in filecmp.cmpfile

Initial Comment:
The filecmp.cmpfiles function is described like 
this:

cmpfiles(dir1, dir2, common[, shallow[, 
use_statcache]]) 

The documentation doesn't point out what 
common is and I haven't been able to figure it out myself.

This is 
on my version of python (2.1 on Windows) and in the latest version.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-20 13:50

Message:
Logged In: YES 
user_id=3066

Accepted; thanks, Neal!  Please check in for the trunk, &
the 2.2.1 branch if you have a checkout.  (Otherwise, mwh
needs to do that. ;-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 13:37

Message:
Logged In: YES 
user_id=33168

Attached is a patch from the docstring.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:51:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:51:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-522426 ] undocumented argument in filecmp.cmpfile
Message-ID: <E16nlAt-0008Re-00@usw-sf-web2.sourceforge.net>

Bugs item #522426, was opened at 2002-02-25 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Philippe Fremy (pfremy)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: undocumented argument in filecmp.cmpfile

Initial Comment:
The filecmp.cmpfiles function is described like 
this:

cmpfiles(dir1, dir2, common[, shallow[, 
use_statcache]]) 

The documentation doesn't point out what 
common is and I haven't been able to figure it out myself.

This is 
on my version of python (2.1 on Windows) and in the latest version.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-20 13:50

Message:
Logged In: YES 
user_id=3066

Accepted; thanks, Neal!  Please check in for the trunk, &
the 2.2.1 branch if you have a checkout.  (Otherwise, mwh
needs to do that. ;-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 13:37

Message:
Logged In: YES 
user_id=33168

Attached is a patch from the docstring.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:55:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:55:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-522426 ] undocumented argument in filecmp.cmpfile
Message-ID: <E16nlF8-0005Ql-00@usw-sf-web1.sourceforge.net>

Bugs item #522426, was opened at 2002-02-25 08:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Neal Norwitz (nnorwitz)
Summary: undocumented argument in filecmp.cmpfile

Initial Comment:
The filecmp.cmpfiles function is described like 
this:

cmpfiles(dir1, dir2, common[, shallow[, 
use_statcache]]) 

The documentation doesn't point out what 
common is and I haven't been able to figure it out myself.

This is 
on my version of python (2.1 on Windows) and in the latest version.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 13:55

Message:
Logged In: YES 
user_id=33168

Checked in libfilecmp.tex as 1.5.18.1 and 1.6.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-20 13:50

Message:
Logged In: YES 
user_id=3066

Accepted; thanks, Neal!  Please check in for the trunk, &
the 2.2.1 branch if you have a checkout.  (Otherwise, mwh
needs to do that. ;-)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 13:37

Message:
Logged In: YES 
user_id=33168

Attached is a patch from the docstring.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522426&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 18:56:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 10:56:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E16nlG3-0008VQ-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 19:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 19:07:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 11:07:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nlQg-0005aC-00@usw-sf-web1.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 14:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 13:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 19:45:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 11:45:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-532687 ] "realpath" for posixpath module
Message-ID: <E16nm1f-0000fc-00@usw-sf-web2.sourceforge.net>

Bugs item #532687, was opened at 2002-03-20 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
Summary: "realpath" for posixpath module

Initial Comment:
It would be nice to be able to have a function which 
resolves a path to its "real" path (removing any 
symlinks in the path) available from the posixpath 
library.  Below (and attached, in case the rendering 
gets munged by SF) is a Python implementation that 
might be useful.  It may be better to just wrap the 
realpath UNIX API call, but I'm not sure whether there 
are cross-platform nuances to it.

I suppose this could go in to Jeremy's Small Features 
PEP.

import os

def realpath(p):
    p = os.path.abspath(p)
    path_list = p.split(os.sep)
    orig_len = len(path_list)
    changed = 0
    i = 1
    while not changed and i < orig_len:
        head = path_list[:i]
        tail = path_list[i:]
        head_s = os.sep.join(head)
        tail_s = os.sep.join(tail)
        if os.path.islink(head_s):
            head_s = os.readlink(head_s)
            path_list = head_s.split(os.sep)
            path_list.extend(tail)
            p = os.sep.join(path_list)
            p = realpath(p)
            changed = 1
        i = i + 1
    return p


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 21:24:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 13:24:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E16nnYv-0001sf-00@usw-sf-web2.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 06:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Skip Montanaro (montanaro)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 15:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03:14

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 02:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 09:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 04:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 10:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 12:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 10:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 04:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-30 00:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 21:44:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 13:44:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16nnsG-0007VG-00@usw-sf-web1.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 13:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

>Comment By: Chris Withers (fresh)
Date: 2002-03-20 21:44

Message:
Logged In: YES 
user_id=24723

Can I close this?

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-14 20:22

Message:
Logged In: YES 
user_id=24723

This was an application problem, see:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Here's my new code which solves the problem, maybe
NonBlockingReader belongs in a library somewhere?

cheers,

Chris

PS:

from os import getcwd, chdir, system, popen3

from threading import Thread

class NonBlockingReader(Thread):

    def __init__(self,file):
        Thread.__init__(self)
        self.file = file
        
    def run(self):
        self.result = self.file.read()

    def read(self):
        return self.result
    
dir=getcwd()
chdir('E:\ZopeTests\sandbox\Zope3')
(i,c,e) = popen3('c:\python22\python test.py')
chdir(dir)

print "popened"
ct = NonBlockingReader(c)
print "ct created"
et = NonBlockingReader(e)
print "et created"
ct.start()
print "ct started"
et.start()
print "et started"
ct.join()
print "ct joined"
et.join()
print "et joined"

print ct.read()+et.read()

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 19:29

Message:
Logged In: YES 
user_id=68151

http://ezwiki.com/2.54/python/popenTest.py

This test works on 
Linux and Win2k.
It makes me think raw_input should flush 
stdout.
It's tricky getting this sort of thing to work.

Looks like 
test_popen2.py uses "more.exe" on Win98.
That might be a 
problem?
The client program must flush stdout after each write.


----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 17:27

Message:
Logged In: YES 
user_id=68151

I don't know about Win98*. But the example 
given did hang in Linux also.

The 
problem as posted here seems to be caused 
by fp.read() blocking until the spawned 
program exits. Using os.read() on Linux 
avoids this problem. I'll give it a try on 
Win2k and XP today. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 09:19

Message:
Logged In: YES 
user_id=31435

If would help a lot if someone produced a small, self-
contained test case that reproduced the problem.  The usual 
outcome of *trying* to is the discovery that popen() on 
Windows hangs "for no identifiable reason at all".  
Example:  there's a test_popen2.py in the std Python test 
suite.  It hangs about 1 time in 200 when I run it on 
Win98SE.  There's no identifiable cause; it just hangs 
sometimes, and when it does it's always hung in the bowels 
of MS's code.  There are no races in the Python code 
driving it.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 23:54

Message:
Logged In: YES 
user_id=68151

os.read() doesn't block.
I'd expect you have to 
call os.read in a loop. 


i,o,e=os.popen3("../../python 
errXX.py")
print os.read(o.fileno(),10000), 
os.read(e.fileno(),10000)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 18:22

Message:
Logged In: YES 
user_id=31435

Chris, which version of Windows are you talking about?  You 
identified W2K for Thomas Guettler, but didn't say which 
version you were using.  The popen implementations are 
radically different across Windows flavors, so knowing 
which one you're using is important.

Alas, "important" doesn't necessarily imply helpful 
<wink>.  Historically, popen-on-Windows bugs don't get 
fixed, because they hit a brick wall after blame gets 
traced to MS internals.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-09 18:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 14:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:00:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:00:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-532687 ] "realpath" for posixpath module
Message-ID: <E16no7p-0002J6-00@usw-sf-web2.sourceforge.net>

Bugs item #532687, was opened at 2002-03-20 14:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "realpath" for posixpath module

Initial Comment:
It would be nice to be able to have a function which 
resolves a path to its "real" path (removing any 
symlinks in the path) available from the posixpath 
library.  Below (and attached, in case the rendering 
gets munged by SF) is a Python implementation that 
might be useful.  It may be better to just wrap the 
realpath UNIX API call, but I'm not sure whether there 
are cross-platform nuances to it.

I suppose this could go in to Jeremy's Small Features 
PEP.

import os

def realpath(p):
    p = os.path.abspath(p)
    path_list = p.split(os.sep)
    orig_len = len(path_list)
    changed = 0
    i = 1
    while not changed and i < orig_len:
        head = path_list[:i]
        tail = path_list[i:]
        head_s = os.sep.join(head)
        tail_s = os.sep.join(tail)
        if os.path.islink(head_s):
            head_s = os.readlink(head_s)
            path_list = head_s.split(os.sep)
            path_list.extend(tail)
            p = os.sep.join(path_list)
            p = realpath(p)
            changed = 1
        i = i + 1
    return p


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:00

Message:
Logged In: YES 
user_id=6380

Eh, Chris, in Python 2.2 there already *is* a realpath()
which seems to do what you want. You can close the request
if you agree that's good enough -- if not, I'd like to hear
about where it's lacking. :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:05:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:05:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-532687 ] "realpath" for posixpath module
Message-ID: <E16noDB-0007le-00@usw-sf-web1.sourceforge.net>

Bugs item #532687, was opened at 2002-03-20 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "realpath" for posixpath module

Initial Comment:
It would be nice to be able to have a function which 
resolves a path to its "real" path (removing any 
symlinks in the path) available from the posixpath 
library.  Below (and attached, in case the rendering 
gets munged by SF) is a Python implementation that 
might be useful.  It may be better to just wrap the 
realpath UNIX API call, but I'm not sure whether there 
are cross-platform nuances to it.

I suppose this could go in to Jeremy's Small Features 
PEP.

import os

def realpath(p):
    p = os.path.abspath(p)
    path_list = p.split(os.sep)
    orig_len = len(path_list)
    changed = 0
    i = 1
    while not changed and i < orig_len:
        head = path_list[:i]
        tail = path_list[i:]
        head_s = os.sep.join(head)
        tail_s = os.sep.join(tail)
        if os.path.islink(head_s):
            head_s = os.readlink(head_s)
            path_list = head_s.split(os.sep)
            path_list.extend(tail)
            p = os.sep.join(path_list)
            p = realpath(p)
            changed = 1
        i = i + 1
    return p


----------------------------------------------------------------------

>Comment By: Chris McDonough (chrism)
Date: 2002-03-20 22:05

Message:
Logged In: YES 
user_id=32974

Whoops!  No, that's fine, please close the request.  I'm 
stuck in 2.1.X land until Zope works on 2.2.  Sorry to 
waste bandwidth. ;-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 22:00

Message:
Logged In: YES 
user_id=6380

Eh, Chris, in Python 2.2 there already *is* a realpath()
which seems to do what you want. You can close the request
if you agree that's good enough -- if not, I'd like to hear
about where it's lacking. :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:07:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:07:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-532687 ] "realpath" for posixpath module
Message-ID: <E16noEu-0000B1-00@usw-sf-web3.sourceforge.net>

Bugs item #532687, was opened at 2002-03-20 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
>Resolution: Rejected
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "realpath" for posixpath module

Initial Comment:
It would be nice to be able to have a function which 
resolves a path to its "real" path (removing any 
symlinks in the path) available from the posixpath 
library.  Below (and attached, in case the rendering 
gets munged by SF) is a Python implementation that 
might be useful.  It may be better to just wrap the 
realpath UNIX API call, but I'm not sure whether there 
are cross-platform nuances to it.

I suppose this could go in to Jeremy's Small Features 
PEP.

import os

def realpath(p):
    p = os.path.abspath(p)
    path_list = p.split(os.sep)
    orig_len = len(path_list)
    changed = 0
    i = 1
    while not changed and i < orig_len:
        head = path_list[:i]
        tail = path_list[i:]
        head_s = os.sep.join(head)
        tail_s = os.sep.join(tail)
        if os.path.islink(head_s):
            head_s = os.readlink(head_s)
            path_list = head_s.split(os.sep)
            path_list.extend(tail)
            p = os.sep.join(path_list)
            p = realpath(p)
            changed = 1
        i = i + 1
    return p


----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2002-03-20 22:05

Message:
Logged In: YES 
user_id=32974

Whoops!  No, that's fine, please close the request.  I'm 
stuck in 2.1.X land until Zope works on 2.2.  Sorry to 
waste bandwidth. ;-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 22:00

Message:
Logged In: YES 
user_id=6380

Eh, Chris, in Python 2.2 there already *is* a realpath()
which seems to do what you want. You can close the request
if you agree that's good enough -- if not, I'd like to hear
about where it's lacking. :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:07:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:07:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-532687 ] "realpath" for posixpath module
Message-ID: <E16noFG-0000BH-00@usw-sf-web3.sourceforge.net>

Bugs item #532687, was opened at 2002-03-20 19:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470

Category: Python Library
Group: Feature Request
>Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Chris McDonough (chrism)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "realpath" for posixpath module

Initial Comment:
It would be nice to be able to have a function which 
resolves a path to its "real" path (removing any 
symlinks in the path) available from the posixpath 
library.  Below (and attached, in case the rendering 
gets munged by SF) is a Python implementation that 
might be useful.  It may be better to just wrap the 
realpath UNIX API call, but I'm not sure whether there 
are cross-platform nuances to it.

I suppose this could go in to Jeremy's Small Features 
PEP.

import os

def realpath(p):
    p = os.path.abspath(p)
    path_list = p.split(os.sep)
    orig_len = len(path_list)
    changed = 0
    i = 1
    while not changed and i < orig_len:
        head = path_list[:i]
        tail = path_list[i:]
        head_s = os.sep.join(head)
        tail_s = os.sep.join(tail)
        if os.path.islink(head_s):
            head_s = os.readlink(head_s)
            path_list = head_s.split(os.sep)
            path_list.extend(tail)
            p = os.sep.join(path_list)
            p = realpath(p)
            changed = 1
        i = i + 1
    return p


----------------------------------------------------------------------

Comment By: Chris McDonough (chrism)
Date: 2002-03-20 22:05

Message:
Logged In: YES 
user_id=32974

Whoops!  No, that's fine, please close the request.  I'm 
stuck in 2.1.X land until Zope works on 2.2.  Sorry to 
waste bandwidth. ;-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 22:00

Message:
Logged In: YES 
user_id=6380

Eh, Chris, in Python 2.2 there already *is* a realpath()
which seems to do what you want. You can close the request
if you agree that's good enough -- if not, I'd like to hear
about where it's lacking. :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532687&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:10:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:10:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E16noHe-00030H-00@usw-sf-web4.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Type/class unification
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:10:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:10:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E16noHt-00030b-00@usw-sf-web4.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

>Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:22:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:22:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16noTw-0003A6-00@usw-sf-web4.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 22:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Nobody/Anonymous (nobody)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:24:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:24:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16noVo-000818-00@usw-sf-web1.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 22:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 22:55:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 14:55:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-527783 ] popen3 hangs on windows
Message-ID: <E16nozf-0000lN-00@usw-sf-web3.sourceforge.net>

Bugs item #527783, was opened at 2002-03-09 08:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470

Category: Python Library
>Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Chris Withers (fresh)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen3 hangs on windows

Initial Comment:
The following hangs on windows:

(i,o,e)=popen('python test.py')
result=o.read()+e.read()

...where test.py is the test.py of a Zope 3 CVS
checkout. I suspected a Zope 3 problem, but Thomas
Guettler also expereinced this in a different context:

popen3() of the python (2.1.2) which comes with zope
hangs on W2K:
 
 (stdin, stdout, stderr)=popen3('wvWare -x wvware.xml
foo.doc')
 text=stdout.read()

Then again, having seen bug #481896, I'm not sure this
is confined to windows.

Any ideas?

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-20 17:55

Message:
Logged In: YES 
user_id=31435

Closed as not-a-bug.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-20 16:44

Message:
Logged In: YES 
user_id=24723

Can I close this?

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-14 15:22

Message:
Logged In: YES 
user_id=24723

This was an application problem, see:
http://mail.python.org/pipermail/python-dev/2000-September/009460.html

Here's my new code which solves the problem, maybe
NonBlockingReader belongs in a library somewhere?

cheers,

Chris

PS:

from os import getcwd, chdir, system, popen3

from threading import Thread

class NonBlockingReader(Thread):

    def __init__(self,file):
        Thread.__init__(self)
        self.file = file
        
    def run(self):
        self.result = self.file.read()

    def read(self):
        return self.result
    
dir=getcwd()
chdir('E:\ZopeTests\sandbox\Zope3')
(i,c,e) = popen3('c:\python22\python test.py')
chdir(dir)

print "popened"
ct = NonBlockingReader(c)
print "ct created"
et = NonBlockingReader(e)
print "et created"
ct.start()
print "ct started"
et.start()
print "et started"
ct.join()
print "ct joined"
et.join()
print "et joined"

print ct.read()+et.read()

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 14:29

Message:
Logged In: YES 
user_id=68151

http://ezwiki.com/2.54/python/popenTest.py

This test works on 
Linux and Win2k.
It makes me think raw_input should flush 
stdout.
It's tricky getting this sort of thing to work.

Looks like 
test_popen2.py uses "more.exe" on Win98.
That might be a 
problem?
The client program must flush stdout after each write.


----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-10 12:27

Message:
Logged In: YES 
user_id=68151

I don't know about Win98*. But the example 
given did hang in Linux also.

The 
problem as posted here seems to be caused 
by fp.read() blocking until the spawned 
program exits. Using os.read() on Linux 
avoids this problem. I'll give it a try on 
Win2k and XP today. 




----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:19

Message:
Logged In: YES 
user_id=31435

If would help a lot if someone produced a small, self-
contained test case that reproduced the problem.  The usual 
outcome of *trying* to is the discovery that popen() on 
Windows hangs "for no identifiable reason at all".  
Example:  there's a test_popen2.py in the std Python test 
suite.  It hangs about 1 time in 200 when I run it on 
Win98SE.  There's no identifiable cause; it just hangs 
sometimes, and when it does it's always hung in the bowels 
of MS's code.  There are no races in the Python code 
driving it.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 18:54

Message:
Logged In: YES 
user_id=68151

os.read() doesn't block.
I'd expect you have to 
call os.read in a loop. 


i,o,e=os.popen3("../../python 
errXX.py")
print os.read(o.fileno(),10000), 
os.read(e.fileno(),10000)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 13:22

Message:
Logged In: YES 
user_id=31435

Chris, which version of Windows are you talking about?  You 
identified W2K for Thomas Guettler, but didn't say which 
version you were using.  The popen implementations are 
radically different across Windows flavors, so knowing 
which one you're using is important.

Alas, "important" doesn't necessarily imply helpful 
<wink>.  Historically, popen-on-Windows bugs don't get 
fixed, because they hit a brick wall after blame gets 
traced to MS internals.

----------------------------------------------------------------------

Comment By: Chris Withers (fresh)
Date: 2002-03-09 13:14

Message:
Logged In: YES 
user_id=24723

So what should I use instead of e.read() ad o.read()

In fact, any chance of a replacement line for:

result=o.read()+e.read() 

? ;-)

cheers,

Chris

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 13:11

Message:
Logged In: YES 
user_id=68151

Don't use e.read() 
This will try to read the entire file. Which doesn't 
make sense with a stream. Although I think this works with sockets? 


I'll look at a select solution.
Not sure how to know how many bytes to 
read after the select breaks out.

----------------------------------------------------------------------

Comment By: Darrell Gallion (dgallion)
Date: 2002-03-09 09:51

Message:
Logged In: YES 
user_id=68151

This cuased the problem on Linux.

import os, re
files="""
file 
errXX.py
<<<<<<<<<<<<<
import sys
while 1:
    print >>sys.stderr, 
'x'
<<<<<<<<<<<<<
file runXX.py
<<<<<<<<<<<<<
import 
os
(i,o,e)=os.popen3("python errXX.py")
print 
e.read()
<<<<<<<<<<<<<
cmd python 
runXX.py
<<<<<<<<<<<<<
"""
files=re.split("<<<<<+",files)
for 
x in range(0,len(files), 2):
    cmd=files[x].split()
    
body=files[x+1]
    if cmd[0]=='file':
        
open(cmd[1],'w').write(body)
    elif cmd[0]=='cmd':
        os.system(' 
'.join(cmd[1:])+body)
    else:
        assert(0)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=527783&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 23:32:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 15:32:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-532807 ] References to misspelt API function name
Message-ID: <E16npYo-0003PO-00@usw-sf-web2.sourceforge.net>

Bugs item #532807, was opened at 2002-03-20 15:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532807&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: References to misspelt API function name

Initial Comment:
On the web page at <http://www.python.org/doc/current/ext/parseTuple.html> there are a 
number of references to the API function named "PyMem_NEW()," which is incorrect. This 
function's name is spelled "PyMem_New()", from section 9.2 in the API documentation.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532807&group_id=5470


From noreply@sourceforge.net  Wed Mar 20 23:43:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 15:43:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-532807 ] References to misspelt API function name
Message-ID: <E16npjZ-00045H-00@usw-sf-web4.sourceforge.net>

Bugs item #532807, was opened at 2002-03-20 15:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532807&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Deleted
>Resolution: Invalid
Priority: 5
Submitted By: Martin Miller (mrmiller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: References to misspelt API function name

Initial Comment:
On the web page at <http://www.python.org/doc/current/ext/parseTuple.html> there are a 
number of references to the API function named "PyMem_NEW()," which is incorrect. This 
function's name is spelled "PyMem_New()", from section 9.2 in the API documentation.



----------------------------------------------------------------------

>Comment By: Martin Miller (mrmiller)
Date: 2002-03-20 15:43

Message:
Logged In: YES 
user_id=257085

Sorry, I see there is a macro named PyMem_NEW, which must be what the documentation is talking about.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532807&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 00:08:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 16:08:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nq80-0003pB-00@usw-sf-web2.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 10:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-20 16:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 11:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 10:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 01:06:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 17:06:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nr1t-0004y4-00@usw-sf-web4.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-20 19:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 14:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 13:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 01:19:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 17:19:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-532855 ] Corrupted .rsrc file
Message-ID: <E16nrEX-0002Lv-00@usw-sf-web3.sourceforge.net>

Bugs item #532855, was opened at 2002-03-21 01:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532855&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Jack Jansen (jackjansen)
Summary: Corrupted .rsrc file

Initial Comment:
The Mac/Resources/error.rsrc file is corrupted in the 
2.2.1c1 tarball.  The one in the HEAD of CVS is fine.

make install in Mac/OSX dies when applesingle.py 
raises an "Unknown AppleSingle magic number" error.

The Unix file command reports errors.rsrc is an .hqx 
file (should be data).

Replacing file with the one from CVS solves the 
problem.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532855&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 01:27:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 17:27:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16nrMS-0005CY-00@usw-sf-web4.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 12:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 01:51:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 17:51:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nrk0-0004wA-00@usw-sf-web2.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-20 19:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 14:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 13:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 01:59:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 17:59:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-517704 ] Installing Python 2.2 on Solaris 2.x
Message-ID: <E16nrrD-00051G-00@usw-sf-web2.sourceforge.net>

Bugs item #517704, was opened at 2002-02-14 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517704&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installing Python 2.2 on Solaris 2.x

Initial Comment:
I'm having problems installing Python 2.2 onto
my Solaris 2.6 workstation.

I am doing the boilerplate ...

  ./configure
  make
  make install

I checked for prior related bug reports and posted
on c.l.py.  Chris Wysocki reported similar problems
and Barry Warsaw mentioned on python-dev how
setup.py agressively deletes .so files when it
gets an import error after building the file.

Note:  No problems building Python 2.1 (2.1.2) on
this platform.

Log files attached.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:59

Message:
Logged In: YES 
user_id=33168

For a possible fix, see the patch in bug # 532618 :
http://sourceforge.net/tracker/index.php?func=detail&aid=532618&group_id=5470&atid=105470

The patch is against the latest in CVS.  Need to apply the
try/except around the for filename in self._built_objects
for this to work.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517704&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 02:30:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 18:30:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16nsLa-00037Q-00@usw-sf-web3.sourceforge.net>

Bugs item #512007, was opened at 2002-02-01 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 21:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 03:47:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 20 Mar 2002 19:47:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16ntXw-00038B-00@usw-sf-web1.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

>Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-20 22:47

Message:
Logged In: YES 
user_id=482117

Okay, The version of asyncore.py from 2.1.1 when put into
the 2.2 release solves the problem, so the bug seems to be
in asyncore.py. I have cobbled together a server that
displays the same error and am including it here. When run
in 2.1.1 it works fine, reloading the config (just a print)
with a kill -1 pid and terminating with a kill pid.
Carl

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-16 15:36

Message:
Logged In: YES 
user_id=11375

The asyncore.py in 2.1.1 seems to be revision 1.10 of 
the file; it's rev. 1.28 in 2.2 and is now at 1.30, so 
there have been a number of changes to asyncore, though 
none seem relevant.  Did you try your code on 2.2 with 
the 2.1.1
asyncore?  That would let us figure out if it's due to 
a change in asyncore or the underlying socket or select
module.

(Actually, another thing to check is whether the select 
or the poll module is being used; maybe that changed 
for you between 2.1.1 and 2.2.)



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-14 21:52

Message:
Logged In: YES 
user_id=482117

My question then is why didn't it do this when I ran my app
with python 2.1.1. Something has changed in 2.2 and I don't
think it was asyncore, I do know some work was done to the
low level socket and select modules so they could handle
IPV6. I understand why the None is being returned, but an
accept shouldn't even be called on a write event coming from
a select or poll.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
Logged In: YES 
user_id=11375

Looking at the implementation of accept() in asyncore.py, it will 
return 
None when the socket is in non-blocking mode and the accept() would block.  
There's really nothing else accept() could
return in this case, so you'll 
probably have to write your code to 
handle this case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 08:56:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 00:56:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-529104 ] broken error handling in unicode-escape
Message-ID: <E16nyN5-0006Nb-00@usw-sf-web1.sourceforge.net>

Bugs item #529104, was opened at 2002-03-12 21:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470

Category: Unicode
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Martin v. Löwis (loewis)
Summary: broken error handling in unicode-escape

Initial Comment:
Error handling for decoding unicode-escape encoded
string seems the be slightly broken:

Python 2.2 (#2, Mar  1 2002, 17:32:59) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on 
linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> "\N{foo}xx".decode("unicode-
escape", "ignore")      
u'\x08xx'
>>> "\".decode("unicode-escape")                    
u'\\U082a74f8'

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 09:56

Message:
Logged In: YES 
user_id=21627

Forwarded to HEAD as unicodeobject.c 2.131, test_unicode.py
1.50.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-18 13:56

Message:
Logged In: YES 
user_id=6656

Applied in Objects/unicodeobject.c revision 2.124.6.6, thanks!

I also added the cases from the report to test_unicode.py
revision 1.47.6.1.

These changes will need to go onto the trunk, at some future
point.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-18 11:10

Message:
Logged In: YES 
user_id=38388

Assigned to Martin. I don't have time for this the next two weeks.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 23:44

Message:
Logged In: YES 
user_id=21627

Attached is a patch that fixes the two bugs.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-17 23:08

Message:
Logged In: YES 
user_id=21627

This falls in the "doctor, it hurts when I do this"
category, and it is not a regression over 2.1.x, so I don't
think it is critical to fix for 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-16 18:43

Message:
Logged In: YES 
user_id=6656

Agree that looks nasty.  Any chance of a quick fix from Marc
or Martin?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529104&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 08:59:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 00:59:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16nyQI-0006Pv-00@usw-sf-web1.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 23:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 09:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 09:16:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 01:16:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] Build python fails after fpectl
Message-ID: <E16nygI-0006bF-00@usw-sf-web1.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 19:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Build python fails after fpectl

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 10:16

Message:
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 01:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 19:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 09:47:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 01:47:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E16nzA6-0001a6-00@usw-sf-web2.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 10:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 01:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 14:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 11:28:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 03:28:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o0jm-0003BR-00@usw-sf-web4.sourceforge.net>

Bugs item #512007, was opened at 2002-02-02 04:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 12:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 03:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 12:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 12:27:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 04:27:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o1eq-0003Ul-00@usw-sf-web2.sourceforge.net>

Bugs item #512007, was opened at 2002-02-02 03:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-21 12:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 11:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 11:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:08:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:08:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o2IT-0000pX-00@usw-sf-web1.sourceforge.net>

Bugs item #512007, was opened at 2002-02-01 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 08:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 07:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 06:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 21:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:16:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:16:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16o2QT-0004VN-00@usw-sf-web4.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 17:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 08:16

Message:
Logged In: YES 
user_id=6380

I give this a +1. To refute Martin's -1: The use case that
prompts this is passing a wrapper to wrapper-ignorant code.
This may be 3rd party code that you can't afford to make
wrapper-aware. If I pass you a wrapper to an X where you
expect an X, your isinstance(x, X) call should succeed.
Especially since x.__class__ already returns X. Also,
isinstance(x, X) succeeds if X is a classic class and x is a
wrapped X instance.

If you want to know if something is a wrapper, you have to
use type().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 03:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:17:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:17:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-532646 ] Recursive class instance "error"
Message-ID: <E16o2RA-0004Vq-00@usw-sf-web4.sourceforge.net>

Bugs item #532646, was opened at 2002-03-20 13:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: Gregor Mirai (gregmi)
Assigned to: Nobody/Anonymous (nobody)
>Summary: Recursive class instance "error"

Initial Comment:
If one writes the following code (tested on Python  
2.1, 2.2 on platforms MacOS X Server, MacOS X, Windows 
98, NT, 2000) one can easily produce several "errors".

MacOS X, MacOS X Server (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name,
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
Segmentation fault

Win98, NT, 2000 (Python 2.1, 2.2)
------------------------------------------
class A:
   def __getattr__(self, name):
     print name
     return A()
------------------------------------------

>>> a=A()
>>> a.foo
foo
__repr__ __call__ __call__ __call__ ... ad inf



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 04:47

Message:
Logged In: NO 

>>> a=A() 
>>> a.foo 
foo 
__repr__ __call__ __call__ __call__ ... ad inf

This is normal behavior. The code at the top is buggy. The 
correct one is:

class A:
  def __getattr__(self, name):
    if name == '__repr__':
      return self.__repr__()
    print name
    return A()

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-20 17:10

Message:
Logged In: YES 
user_id=6380

This is buggy user code.

But the segfault should be fixed if possible.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532646&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:40:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:40:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o2nf-0004Ob-00@usw-sf-web2.sourceforge.net>

Bugs item #512007, was opened at 2002-02-02 04:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 14:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 14:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 13:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 12:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 03:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 12:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:47:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:47:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16o2uk-0001v6-00@usw-sf-web3.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 23:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 14:47

Message:
Logged In: YES 
user_id=21627

There has been a long-standing guarantee that 'type(o) is X'
implies 'isinstance(o, X)', or, more compact,
'isinstance(o,type(o))' for all objects o. In fact, people
have been advised to change the explicit test for type() to
isinstance calls. With the proposed change, this property
will be given up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 14:16

Message:
Logged In: YES 
user_id=6380

I give this a +1. To refute Martin's -1: The use case that
prompts this is passing a wrapper to wrapper-ignorant code.
This may be 3rd party code that you can't afford to make
wrapper-aware. If I pass you a wrapper to an X where you
expect an X, your isinstance(x, X) call should succeed.
Especially since x.__class__ already returns X. Also,
isinstance(x, X) succeeds if X is a classic class and x is a
wrapped X instance.

If you want to know if something is a wrapper, you have to
use type().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 09:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:55:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:55:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16o32F-00021A-00@usw-sf-web3.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 22:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Steve Alexander (stevea_zope)
Date: 2002-03-21 13:55

Message:
Logged In: YES 
user_id=492001

A new isinstance can maintain and extend the semantic Martin
describes.

Let's say object wl is a wrapped list:

from Zope.ContextWrapper import Wrapper

wl = Wrapper([])
assert isinstance(wl, list) is 1
assert isinstance(wl, Wrapper) is 1

So, your semantics are maintained. With the proposed change,
the property you describe need not be given up.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 13:47

Message:
Logged In: YES 
user_id=21627

There has been a long-standing guarantee that 'type(o) is X'
implies 'isinstance(o, X)', or, more compact,
'isinstance(o,type(o))' for all objects o. In fact, people
have been advised to change the explicit test for type() to
isinstance calls. With the proposed change, this property
will be given up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 13:16

Message:
Logged In: YES 
user_id=6380

I give this a +1. To refute Martin's -1: The use case that
prompts this is passing a wrapper to wrapper-ignorant code.
This may be 3rd party code that you can't afford to make
wrapper-aware. If I pass you a wrapper to an X where you
expect an X, your isinstance(x, X) call should succeed.
Especially since x.__class__ already returns X. Also,
isinstance(x, X) succeeds if X is a classic class and x is a
wrapped X instance.

If you want to know if something is a wrapper, you have to
use type().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 13:57:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 05:57:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16o34N-00022c-00@usw-sf-web3.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 22:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Steve Alexander (stevea_zope)
Date: 2002-03-21 13:57

Message:
Logged In: YES 
user_id=492001

oops... please ignore my unsupported use of "is" to compare
small ints.

I meant:

from Zope.ContextWrapper import Wrapper

wl = Wrapper([])
assert isinstance(wl, list) == 1
assert isinstance(wl, Wrapper) == 1



----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-03-21 13:55

Message:
Logged In: YES 
user_id=492001

A new isinstance can maintain and extend the semantic Martin
describes.

Let's say object wl is a wrapped list:

from Zope.ContextWrapper import Wrapper

wl = Wrapper([])
assert isinstance(wl, list) is 1
assert isinstance(wl, Wrapper) is 1

So, your semantics are maintained. With the proposed change,
the property you describe need not be given up.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 13:47

Message:
Logged In: YES 
user_id=21627

There has been a long-standing guarantee that 'type(o) is X'
implies 'isinstance(o, X)', or, more compact,
'isinstance(o,type(o))' for all objects o. In fact, people
have been advised to change the explicit test for type() to
isinstance calls. With the proposed change, this property
will be given up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 13:16

Message:
Logged In: YES 
user_id=6380

I give this a +1. To refute Martin's -1: The use case that
prompts this is passing a wrapper to wrapper-ignorant code.
This may be 3rd party code that you can't afford to make
wrapper-aware. If I pass you a wrapper to an X where you
expect an X, your isinstance(x, X) call should succeed.
Especially since x.__class__ already returns X. Also,
isinstance(x, X) succeeds if X is a classic class and x is a
wrapped X instance.

If you want to know if something is a wrapper, you have to
use type().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 14:52:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 06:52:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-532767 ] isinstance() should respect __class__
Message-ID: <E16o3vQ-0005Gr-00@usw-sf-web2.sourceforge.net>

Bugs item #532767, was opened at 2002-03-20 17:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Steve Alexander (stevea_zope)
Assigned to: Guido van Rossum (gvanrossum)
Summary: isinstance() should respect __class__

Initial Comment:
isinstance(obj, class_or_type_or_tuple) should compare
using obj.__class__ when obj is an instance of a type
or a new-style class.

This is important for using weak references and other
kinds of proxy wrappers, where you want to pass a proxy
to some code, which might query its type using isinstance.

issubclass may need a similar treatment.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 09:52

Message:
Logged In: YES 
user_id=6380

I'm not sure I like SteveA's suggestion of making
isinstance() respond both to the wrapper type and to the
wrapped type. Although there's a precedent:

>>> class C: pass # classic class
... 
>>> c = C()
>>> isinstance(c, C)
1
>>> import types
>>> isinstance(c, types.InstanceType)
1
>>> 

I'm also not sure I agree with Martin's assertion that
type(o) is X and isinstance(o, X) should always be
equivalent. Especially with new-style user-defined classes,
we could also require that o.__class__ == X and
isinstance(o, X) should be equivalent (modulo subclassing),
and that would require isinstance() to prefer __class__.

I guess we'll have to look at actual use cases of
isinstance() and wrappers (both weakrefs and Zope3's
transparent wrappers). My expectation is that, since
wrappers try hard to pretend to be the wrapped object,
extending this to the isinstance() test is more useful than
the stricter interpretation.

----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-03-21 08:57

Message:
Logged In: YES 
user_id=492001

oops... please ignore my unsupported use of "is" to compare
small ints.

I meant:

from Zope.ContextWrapper import Wrapper

wl = Wrapper([])
assert isinstance(wl, list) == 1
assert isinstance(wl, Wrapper) == 1



----------------------------------------------------------------------

Comment By: Steve Alexander (stevea_zope)
Date: 2002-03-21 08:55

Message:
Logged In: YES 
user_id=492001

A new isinstance can maintain and extend the semantic Martin
describes.

Let's say object wl is a wrapped list:

from Zope.ContextWrapper import Wrapper

wl = Wrapper([])
assert isinstance(wl, list) is 1
assert isinstance(wl, Wrapper) is 1

So, your semantics are maintained. With the proposed change,
the property you describe need not be given up.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:47

Message:
Logged In: YES 
user_id=21627

There has been a long-standing guarantee that 'type(o) is X'
implies 'isinstance(o, X)', or, more compact,
'isinstance(o,type(o))' for all objects o. In fact, people
have been advised to change the explicit test for type() to
isinstance calls. With the proposed change, this property
will be given up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-21 08:16

Message:
Logged In: YES 
user_id=6380

I give this a +1. To refute Martin's -1: The use case that
prompts this is passing a wrapper to wrapper-ignorant code.
This may be 3rd party code that you can't afford to make
wrapper-aware. If I pass you a wrapper to an X where you
expect an X, your isinstance(x, X) call should succeed.
Especially since x.__class__ already returns X. Also,
isinstance(x, X) succeeds if X is a classic class and x is a
wrapped X instance.

If you want to know if something is a wrapper, you have to
use type().

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 03:59

Message:
Logged In: YES 
user_id=21627

-1. That means that you can't use isinstance anymore to
determine whether something is a weak reference, or other
kind of proxy wrapper.

If you need a function that unwraps wrappers, write one
yourself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532767&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 15:04:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 07:04:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o47H-0005Q0-00@usw-sf-web2.sourceforge.net>

Bugs item #512007, was opened at 2002-02-01 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 10:04

Message:
Logged In: YES 
user_id=12800

I think I was complaining about three things:

- 4 tests failed which I did not expect to fail.  If these
are fixed now (i.e. they don't fail for you), then great!

- Some of the 20 skipped tests probably should not have been
skipped, e.g. test___all__ and test_asynchat.  Why were
these skipped?

- The entire build process fails with an exit code 1 because
regrtest doesn't know which tests are expected to fail on
"sunos5".  That designation may be meaningless, but then I
claim Martin's original followup below is right on target:
the "skipped on platform x.y" approach is inherently broken.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 08:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 07:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 06:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 21:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 15:56:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 07:56:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o4vc-0006UJ-00@usw-sf-web4.sourceforge.net>

Bugs item #512007, was opened at 2002-02-02 03:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-21 15:56

Message:
Logged In: YES 
user_id=6656

On the sf compile farm, _socket fails to import.  This
causes all the various skips and failures Barry and I are
seeing.

AFAICT, _socket fails to import because the machines have
the openssl headers installed (so setup.py tries to build
ssl support in), but no ssl libraries (so you get "can't
find libssl.so.X.Y messages).  I don't think this is a
problem we should be trying to cope with, so I propose
*this* bug report be closed.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 15:04

Message:
Logged In: YES 
user_id=12800

I think I was complaining about three things:

- 4 tests failed which I did not expect to fail.  If these
are fixed now (i.e. they don't fail for you), then great!

- Some of the 20 skipped tests probably should not have been
skipped, e.g. test___all__ and test_asynchat.  Why were
these skipped?

- The entire build process fails with an exit code 1 because
regrtest doesn't know which tests are expected to fail on
"sunos5".  That designation may be meaningless, but then I
claim Martin's original followup below is right on target:
the "skipped on platform x.y" approach is inherently broken.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 13:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 13:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 12:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 11:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 11:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 15:58:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 07:58:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o4xd-00064Q-00@usw-sf-web2.sourceforge.net>

Bugs item #512007, was opened at 2002-02-01 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 10:58

Message:
Logged In: YES 
user_id=33168

Here is my skipped list for 2.2c1 (16):
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_gl test_imgfile test_linuxaudiodev test_nis
    test_ntpath test_openpty test_socket_ssl 
    test_socketserver test_winreg test_winsound

All are expected AFAIK.  I can teach regrtest to ignore these.

__all__ and asynchat pass for me.

I agree about sunos5, but I'm not sure what do to about it.

So shall we close this bug?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 10:56

Message:
Logged In: YES 
user_id=6656

On the sf compile farm, _socket fails to import.  This
causes all the various skips and failures Barry and I are
seeing.

AFAICT, _socket fails to import because the machines have
the openssl headers installed (so setup.py tries to build
ssl support in), but no ssl libraries (so you get "can't
find libssl.so.X.Y messages).  I don't think this is a
problem we should be trying to cope with, so I propose
*this* bug report be closed.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 10:04

Message:
Logged In: YES 
user_id=12800

I think I was complaining about three things:

- 4 tests failed which I did not expect to fail.  If these
are fixed now (i.e. they don't fail for you), then great!

- Some of the 20 skipped tests probably should not have been
skipped, e.g. test___all__ and test_asynchat.  Why were
these skipped?

- The entire build process fails with an exit code 1 because
regrtest doesn't know which tests are expected to fail on
"sunos5".  That designation may be meaningless, but then I
claim Martin's original followup below is right on target:
the "skipped on platform x.y" approach is inherently broken.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 08:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 07:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 06:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 21:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 16:23:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 08:23:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o5LG-0006qa-00@usw-sf-web4.sourceforge.net>

Bugs item #512007, was opened at 2002-02-02 04:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 16:58

Message:
Logged In: YES 
user_id=33168

Here is my skipped list for 2.2c1 (16):
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_gl test_imgfile test_linuxaudiodev test_nis
    test_ntpath test_openpty test_socket_ssl 
    test_socketserver test_winreg test_winsound

All are expected AFAIK.  I can teach regrtest to ignore these.

__all__ and asynchat pass for me.

I agree about sunos5, but I'm not sure what do to about it.

So shall we close this bug?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 16:56

Message:
Logged In: YES 
user_id=6656

On the sf compile farm, _socket fails to import.  This
causes all the various skips and failures Barry and I are
seeing.

AFAICT, _socket fails to import because the machines have
the openssl headers installed (so setup.py tries to build
ssl support in), but no ssl libraries (so you get "can't
find libssl.so.X.Y messages).  I don't think this is a
problem we should be trying to cope with, so I propose
*this* bug report be closed.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 16:04

Message:
Logged In: YES 
user_id=12800

I think I was complaining about three things:

- 4 tests failed which I did not expect to fail.  If these
are fixed now (i.e. they don't fail for you), then great!

- Some of the 20 skipped tests probably should not have been
skipped, e.g. test___all__ and test_asynchat.  Why were
these skipped?

- The entire build process fails with an exit code 1 because
regrtest doesn't know which tests are expected to fail on
"sunos5".  That designation may be meaningless, but then I
claim Martin's original followup below is right on target:
the "skipped on platform x.y" approach is inherently broken.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 14:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 14:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 13:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 12:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 03:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 12:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 17:12:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 09:12:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16o66s-0003or-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Nobody/Anonymous (nobody)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 17:13:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 09:13:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16o67d-0003pZ-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
>Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 17:26:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 09:26:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16o6KM-0003zD-00@usw-sf-web1.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 17:48:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 09:48:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-512007 ] make test failure on sunos5
Message-ID: <E16o6fv-0007PT-00@usw-sf-web2.sourceforge.net>

Bugs item #512007, was opened at 2002-02-01 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470

Category: Build
Group: Python 2.2
Status: Closed
Resolution: Invalid
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Nobody/Anonymous (nobody)
Summary: make test failure on sunos5

Initial Comment:
I don't have time to dig into this right now, but this
shouldn't get lost.  I just tried to build and test
current 2.2+ cvs on a SunOS 5.8 box on the SourceForge
compile farm.  This may be shallow, but here are the
results:

bash-2.03$ uname -a
SunOS usf-cf-sparc-solaris-2 5.8 Generic_108528-11
sun4u sparc SUNW,Ultra-60

[...]

163 tests OK.
4 tests failed:
    test_pwd test_socket test_sundry test_urllib2
20 tests skipped:
    test___all__ test_al test_asynchat test_bsddb
test_cd test_cl
    test_curses test_gdbm test_gl test_imgfile
test_linuxaudiodev
    test_minidom test_openpty test_pyexpat test_sax
test_socket_ssl
    test_socketserver test_sunaudiodev test_winreg
test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.
*** Error code 1
make: Fatal error: Command failed for target `test'


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 12:48

Message:
Logged In: YES 
user_id=12800

I'm fine with closing this.  We'll open another one later if
necessary.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 10:58

Message:
Logged In: YES 
user_id=33168

Here is my skipped list for 2.2c1 (16):
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_gl test_imgfile test_linuxaudiodev test_nis
    test_ntpath test_openpty test_socket_ssl 
    test_socketserver test_winreg test_winsound

All are expected AFAIK.  I can teach regrtest to ignore these.

__all__ and asynchat pass for me.

I agree about sunos5, but I'm not sure what do to about it.

So shall we close this bug?



----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 10:56

Message:
Logged In: YES 
user_id=6656

On the sf compile farm, _socket fails to import.  This
causes all the various skips and failures Barry and I are
seeing.

AFAICT, _socket fails to import because the machines have
the openssl headers installed (so setup.py tries to build
ssl support in), but no ssl libraries (so you get "can't
find libssl.so.X.Y messages).  I don't think this is a
problem we should be trying to cope with, so I propose
*this* bug report be closed.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-21 10:04

Message:
Logged In: YES 
user_id=12800

I think I was complaining about three things:

- 4 tests failed which I did not expect to fail.  If these
are fixed now (i.e. they don't fail for you), then great!

- Some of the 20 skipped tests probably should not have been
skipped, e.g. test___all__ and test_asynchat.  Why were
these skipped?

- The entire build process fails with an exit code 1 because
regrtest doesn't know which tests are expected to fail on
"sunos5".  That designation may be meaningless, but then I
claim Martin's original followup below is right on target:
the "skipped on platform x.y" approach is inherently broken.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 08:40

Message:
Logged In: YES 
user_id=21627

Perhaps Barry could clarify what he thinks the problem is:
that there are failed test cases, that there is no list of
expected-skips on sunos5, or that a specific test case
failed or was skipped (if so, which one)?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 08:08

Message:
Logged In: YES 
user_id=33168

No, I had 16 skipped tests for 2.2.1.  I think it was about
20 skipped tests for CVS version.  I only meant to point out
that there were no failures.

I used to have _socket failures (I think it was socket
failures) too.  But I thought the problem only occured with
purify.  I have several outstanding patches to get python to
work.  One is documented in #472642.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-21 07:27

Message:
Logged In: YES 
user_id=6656

I've seen this trying to build 2.2.1 on the compile farm
machines.

I was hoping to get away with claiming the compile-farm
machines are broken <wink>.

_socket doesn't get built, which is kind of serious.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 06:28

Message:
Logged In: YES 
user_id=21627

Are you saying you have no skipped tests? Not even winsound?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 21:30

Message:
Logged In: YES 
user_id=33168

Is this still a problem?  2.2.1c1 and 2.3 (CVS) work here 
(170/175 tests OK, no failures):
SunOS rest 5.8 Generic_108528-11 sun4u sparc SUNW,Sun-Blade-100

ie, Solaris 8

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:42

Message:
Logged In: YES 
user_id=21627

The "skipped on platform xy" approach is inherently broken.
minidom and pyexpat are not necessarily skipped; they are
only skipped if no expat library was found during build.
Likewise, the gdbm tests are skipped if no gdbm is installed.

Furthermore, "on sunos5" says nearly nothing; Solaris 2.3
classifies as sunos5 just as well as Solaris8, yet Solaris 8
has many more functions built-in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=512007&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 18:33:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 10:33:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16o7NQ-0008Pv-00@usw-sf-web4.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 18:34:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 10:34:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16o7OX-0008Qs-00@usw-sf-web4.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 3
Submitted By: Ralph Corderoy (ralph)
>Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 18:51:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 10:51:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16o7f9-0005ci-00@usw-sf-web3.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 3
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 12:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 19:20:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 11:20:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16o86t-0005yc-00@usw-sf-web3.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-21 14:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 20:17:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 12:17:18 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-533281 ] bsddb module needs iterators
Message-ID: <E16o8zu-0001Bu-00@usw-sf-web4.sourceforge.net>

Feature Requests item #533281, was opened at 2002-03-21 15:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael McFarland (sidlon)
Assigned to: Nobody/Anonymous (nobody)
Summary: bsddb module needs iterators

Initial Comment:
  The hash, btree and record classes should have an iterator defined.  
The current first() and next() functions should make this a fairly 
simple change to bsddbmmodule.c.  This would allow:

  dbh = 
dbhash.open('mydb.db', 'r')
  for key in dbh:
    process(key, 
dbh[key])

and eliminate the temptation to use the following, 
which would be inadvisable for large databases:

  for key in 
dbh.keys():



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=533281&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 20:47:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 12:47:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E16o9Sj-0006Js-00@usw-sf-web1.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 21:04:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 13:04:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-533306 ] not building on AIX
Message-ID: <E16o9jj-0001eh-00@usw-sf-web4.sourceforge.net>

Bugs item #533306, was opened at 2002-03-21 22:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Toneby (toneby)
Assigned to: Nobody/Anonymous (nobody)
Summary: not building on AIX

Initial Comment:
Simply due to configure not beeing up to date, running
autoconf solves this. Please run autoconf when making a
distribution.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 21:12:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 13:12:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-532855 ] Corrupted .rsrc file
Message-ID: <E16o9rC-0001Ki-00@usw-sf-web2.sourceforge.net>

Bugs item #532855, was opened at 2002-03-21 02:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532855&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Brian Lenihan (brianl)
Assigned to: Jack Jansen (jackjansen)
Summary: Corrupted .rsrc file

Initial Comment:
The Mac/Resources/error.rsrc file is corrupted in the 
2.2.1c1 tarball.  The one in the HEAD of CVS is fine.

make install in Mac/OSX dies when applesingle.py 
raises an "Unknown AppleSingle magic number" error.

The Unix file command reports errors.rsrc is an .hqx 
file (should be data).

Replacing file with the one from CVS solves the 
problem.


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-21 22:12

Message:
Logged In: YES 
user_id=45365

Fixed in 1.4.20.1. bundle.rsrc was also checked in in BinHex form in stead of as AppleSingle, this has also been fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532855&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 21:13:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 13:13:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-531398 ] 221 still doesn't work on OS 8.1
Message-ID: <E16o9sf-0001La-00@usw-sf-web2.sourceforge.net>

Bugs item #531398, was opened at 2002-03-18 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: 221 still doesn't work on OS 8.1

Initial Comment:
The current problem is that InterfaceLib--FSRenameUnicode is undefined. Let's try and weak-link InterfaceLib and hope that doesn't cause a string of new problems.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-21 22:13

Message:
Logged In: YES 
user_id=45365

This problem has been fixed, but a new (related?) one has turned up: ConfigurePythonClassic doesn't run. This also shows up on MacOS 8.6, which should make it easier to debug (as I have access to 8.6).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 23:06:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 15:06:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-510186 ] clean doesn't
Message-ID: <E16oBdA-0002fE-00@usw-sf-web2.sourceforge.net>

Bugs item #510186, was opened at 2002-01-29 10:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: clean doesn't

Initial Comment:
rRnning "python setup.py clean" says:

% python setup.py 
clean
running clean
removing 'build/temp.linux-i686-2.2' 
(and everything under it)

However, following that with an 
immediate "python
setup.py build" reports:

% python 
setup.py build
running build
running build_py
not copying 
RSWM/__init__.py (output up-to-date)
running 
build_ext
skipping 'rswm' extension (up-to-date)

Shouldn't 
the "clean" command simply delete the build
directory?


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 18:06

Message:
Logged In: YES 
user_id=11375

"make clean" usually deletes intermediate files such as 
.o files, leaving executables such as the 'python' 
binary 
in place.  This means you can run it to save disk space 
after building something, and the Distutils 'clean' 
command probably leaves the .so files alone to match 
this behaviour.  Also, note that Modules/Makefile only 
deletes .so files on a "make clobber" (but "make clean" 
deletes the Python executable).


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-01-29 10:31

Message:
Logged In: YES 
user_id=6656

Hmm.  Does "python setup.py clean --all" do what you
want/expect?

Agree this should possibly be the default, by analogy with
"make clean".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510186&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 23:09:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 15:09:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-517451 ] Option processing in setup.cfg
Message-ID: <E16oBgu-0002hm-00@usw-sf-web2.sourceforge.net>

Bugs item #517451, was opened at 2002-02-14 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Option processing in setup.cfg

Initial Comment:
When building RPM files with distutils, I noticed that adding "use_rpm_opt_flags=0" to the file setup.cfg had no effect, although the equivalent command-line option --no-rpm-opt-flags works as advertised.

Some debugging showed the reason: in the first case, the variable self.use_rpm_opt_flags in commands/bdist_rpm.py has the value '0' (string), whereas in the second case it is 0 (integer). The test "if self.use_rpm_opt_flags" does not work as expected if the variable is a string, of course.

I suppose that individual commands should not have to worry about the data type of binary options, so I suspect this is a general bug in distutils option processing.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 23:27:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 15:27:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-517451 ] Option processing in setup.cfg
Message-ID: <E16oBxa-0003PV-00@usw-sf-web4.sourceforge.net>

Bugs item #517451, was opened at 2002-02-14 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: A.M. Kuchling (akuchling)
Summary: Option processing in setup.cfg

Initial Comment:
When building RPM files with distutils, I noticed that adding "use_rpm_opt_flags=0" to the file setup.cfg had no effect, although the equivalent command-line option --no-rpm-opt-flags works as advertised.

Some debugging showed the reason: in the first case, the variable self.use_rpm_opt_flags in commands/bdist_rpm.py has the value '0' (string), whereas in the second case it is 0 (integer). The test "if self.use_rpm_opt_flags" does not work as expected if the variable is a string, of course.

I suppose that individual commands should not have to worry about the data type of binary options, so I suspect this is a general bug in distutils option processing.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 18:27

Message:
Logged In: YES 
user_id=11375

Actually the Distutils has machinery to handle this; 
however, no one told it that the use_rpm_opt_flags option 
is a Boolean.  Try the attached patch, and let me know if 
it fixes this.  (I'll check it into CVS anyway, since
it's obviously needed, whether or not it fixes your 
problem.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470


From noreply@sourceforge.net  Thu Mar 21 23:53:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 15:53:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-532136 ] README seems wrong.
Message-ID: <E16oCMe-0000hC-00@usw-sf-web3.sourceforge.net>

Bugs item #532136, was opened at 2002-03-19 16:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Ralph Corderoy (ralph)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: README seems wrong.

Initial Comment:
Hi,

README says:

    IMPORTANT: If the tests fail and you decide to mail
a bug report,
    *don't* include the output of "make test".  It is
useless.  Run the
    failing test manually, as follows:

            python ../Lib/test/test_whatever.py

    (substituting the top of the source tree for .. if
you built in a
    different directory).  This runs the test in
verbose mode.

I suggest it would be better to write `./python'
otherwise the old,
installed, version is found by users that don't have
the current
directory in their path.

Also, at this point we're in the top level source
directory, so the 
newly built python is ./python.  So Lib isn't ../Lib
but ./Lib, i.e. 
it's in the current directory.  Consequently, the text
about 
substituting the top of the source tree for .. is right
if you built it 
in a different directory.  However, even if you built
it in the current 
directory you still need to substitute the .. AFAICS.

Cheers,


Ralph.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 18:53

Message:
Logged In: YES 
user_id=11375

Good suggestion.  Checked in as rev.1.142 of the README 
file.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532136&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 02:38:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 18:38:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16oEx5-0001kx-00@usw-sf-web1.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
>Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 14:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 02:47:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 18:47:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-532115 ] netrc module broken:not parsing macdefs
Message-ID: <E16oF5n-00052g-00@usw-sf-web2.sourceforge.net>

Bugs item #532115, was opened at 2002-03-19 16:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532115&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Winston Collier (wacollier)
>Assigned to: A.M. Kuchling (akuchling)
Summary: netrc module broken:not parsing macdefs

Initial Comment:
The netrc module on linux and Solaris (and probably all
other platforms, possibly on higher versions as well)
is not properly parsing the .netrc module for macro
definitions (macdef).  Its is supposed to return a
dictionary of strings with the macdef name being the
key, but instead it only parses the first macdef entry,
and returns everything else as the string list,
including the macdefs that follow the first on in the
file.  Its ignoring the extra '\n' that delimits the
end of a macdef and the new 'macdef' statement for
subsequent macros.

example:

in .netrc
............
machine ftpme.foo.com
        login luserhaxor
        password im3733t

macdef downloadfoo
cd test
bin
get foo.test
quit

macdef uploadfoo
cd test
bin
put foo.test
quit

............
python:
............
>>> import netrc
>>> foo=netrc.netrc()
>>> foo.macros
{'downloadfoo': ['cd test\n', 'bin\n', 'get
foo.test\n', 'quit\n', '\n', 'macdef uploadfoo\n', 'cd
test\n', 'bin\n', 'put foo.test\n', 'quit\n', '\n']}
>>> foo.macros['downloadfoo']
['cd test\n', 'bin\n', 'get foo.test\n', 'quit\n',
'\n', 'macdef uploadfoo\n', 'cd test\n', 'bin\n', 'put
foo.test\n', 'quit\n', '\n']
>>> foo.macros['uploadfoo']
Traceback (most recent call last):
  File "<pyshell#45>", line 1, in ?
    foo.macros['uploadfoo']
KeyError: uploadfoo
>>> 

As you can see, its broken as far as parsing macdefs
into a dictionary goes.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 21:47

Message:
Logged In: YES 
user_id=11375

I've checked in a fixed version as revision 1.14 in CVS; 
please try it out and let me know if it fixes the problem 
for you.  (I've already tried it on your example, and it 
parses it correctly.)

Thanks for your bug report!


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532115&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 02:51:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 18:51:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16oF9a-0001ua-00@usw-sf-web1.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 14:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 03:33:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 19:33:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-508100 ] telnetlib in debug mode
Message-ID: <E16oFng-0005VS-00@usw-sf-web2.sourceforge.net>

Bugs item #508100, was opened at 2002-01-24 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Cedric Moreau (c_moe)
>Assigned to: A.M. Kuchling (akuchling)
Summary: telnetlib in debug mode

Initial Comment:
In telnetlib.py, in function process_rawq() the display
of IAC mode options in debug mode isn't right:
Actually:
...
self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c))
...
self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT',
ord(c))

Should be:
...
self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(opt))
...
self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT',
ord(opt))
...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 03:34:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 21 Mar 2002 19:34:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-531262 ] Wrong result for Canvas.tag_bind(t, s)
Message-ID: <E16oFoY-0005W3-00@usw-sf-web2.sourceforge.net>

Bugs item #531262, was opened at 2002-03-18 04:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Brunel (ebrunel)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Wrong result for Canvas.tag_bind(t, s)

Initial Comment:
When a binding is defined for a tag in a Tkinter 
Canvas, trying to get the callback using the 
"tag_bind" method with 2 parameters returns a useless 
value:

----------------------------
from Tkinter import *

root = Tk()

## Create the canvas
c = Canvas(root)
c.pack()

## Create the item
tId = c.create_text(100, 100, text='spam')

## Create the binding
def foo(event): print 'bar'
c.tag_bind(tId, '<Button-1>', foo)

## Get and print the binding
print c.tag_bind(tId, '<Button-1>')

root.mainloop()
---------------------------

The programs prints something looking like: 'if 
{"[136128196foo %# %b %f %h %k %s %t %w %x %y %A %E 
%K %N %W %T %X %Y %D]" == "break"} break'. Trying to 
pass this value as the third parameter of tag_unbind 
for example results in a TclError:

Traceback (most recent call last):
  File "tkCanvasBindings2.py", line 16, in ?
    c.tag_unbind(tId, '<Button-1>', f)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 1904, in 
tag_unbind
    self.deletecommand(funcid)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 297, in 
deletecommand
    self.tk.deletecommand(name)
TclError: can't delete Tcl command

This happens apparently on all platforms (tried 
Win2K, Linux Mandrake 8.0 and Solaris 2.7).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 10:06:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 02:06:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oLwJ-0001FB-00@usw-sf-web2.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 11:25:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 03:25:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-533306 ] not building on AIX
Message-ID: <E16oNAL-0002cT-00@usw-sf-web4.sourceforge.net>

Bugs item #533306, was opened at 2002-03-21 21:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Peter Toneby (toneby)
>Assigned to: Michael Hudson (mwh)
Summary: not building on AIX

Initial Comment:
Simply due to configure not beeing up to date, running
autoconf solves this. Please run autoconf when making a
distribution.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-22 11:25

Message:
Logged In: YES 
user_id=6656

Oops, you're right.  Fixed in revision 1.279.6.4 of configure.

(usually the practice is to run autoconf whenever a change
is made to configure.in.  it looks like I forgot to do that
this time).

Does everything more-or-less work when you run autoconf?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 11:57:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 03:57:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16oNfc-0002S9-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 12:04:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 04:04:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16oNmq-0002cP-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 12:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 12:14:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 04:14:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-533306 ] not building on AIX
Message-ID: <E16oNw9-0002is-00@usw-sf-web2.sourceforge.net>

Bugs item #533306, was opened at 2002-03-21 22:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Peter Toneby (toneby)
Assigned to: Michael Hudson (mwh)
Summary: not building on AIX

Initial Comment:
Simply due to configure not beeing up to date, running
autoconf solves this. Please run autoconf when making a
distribution.

----------------------------------------------------------------------

>Comment By: Peter Toneby (toneby)
Date: 2002-03-22 13:14

Message:
Logged In: YES 
user_id=219420

Yes, it does, but I have some other issues that stem from
setup.py, I'm not sure (haven't looked) if it uses the info
configure figured out, But I suppose those should be filed
as another bug (and I have to do a little bit of research
into it), but I've got a mostly working installation now :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 12:25

Message:
Logged In: YES 
user_id=6656

Oops, you're right.  Fixed in revision 1.279.6.4 of configure.

(usually the practice is to run autoconf whenever a change
is made to configure.in.  it looks like I forgot to do that
this time).

Does everything more-or-less work when you run autoconf?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 13:53:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 05:53:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16oPU5-0001Nd-00@usw-sf-web3.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-22 13:53

Message:
Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 19:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 14:05:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 06:05:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-525705 ] [2.2] underflow raise OverflowException
Message-ID: <E16oPfE-00041q-00@usw-sf-web2.sourceforge.net>

Bugs item #525705, was opened at 2002-03-04 15:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Huaiyu Zhu (hzhu)
Assigned to: Tim Peters (tim_one)
Summary: [2.2] underflow raise OverflowException

Initial Comment:
Python 2.2 (#1, Mar  4 2002, 15:25:20) 
[GCC 2.95.2 19991024 (release)] on linux2
>>> 1e-200**2
OverflowError: (34, 'Numerical result out of range')

The machine runs SuSE 7.1. $ rpm -q gcc glibc
gcc-2.95.2-149
glibc-2.2-7

On this machine, the following test C program produces
1e+200   inf 34 Numerical result out of range 34
1e-200     0 34 Numerical result out of range 34
without -lieee, and 

1e+200   inf 0 Success 34
1e-200     0 0 Success 34
with -lieee.

However, editing pyconfig.h.in to add line
#define HAVE_LIBIEEE 1
does not change Python's behavior.

This problem does not occur on another machine, running
Red Hat 6.1 upgraded to 7.1.  It exhibits exactly the
same behavior regarding C, but Python underflows to 0.0
properly. 


The test C program is

#include <math.h>
#include <stdlib.h>
#include <errno.h>
extern int errno;

main() {
  double x;
  x = 1e200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
  x = 1e-200;
  printf("%g %5g %d %s %d\n", x, pow(x, 2), errno,
strerror(errno), ERANGE);
}


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-22 06:05

Message:
Logged In: NO 

-I believe the C program above is not well suited to
 test libm behaviour: The evaluation order of the printf()
 arguments is undefined, so the errno is not necessarily
 taken after the pow() call.
-On NetBSD, ERANGE is set on pow() underflow. So this gives
 a test platform.
-The change in CVS should help (from code inspection).
-There are 2 different implementations to solve the same
 problem: is_error() in mathmodule.c and the new
 ADJUST_ERANGE in floatobject.c. In stock Python-2.2,
 pow(1e-200,2) and math.pow(1e-200,2) behave differently
 on NetBSD (the former does raise the exception).
 I suggest to share some code here.

----------------------------------------------------------------------

Comment By: Huaiyu Zhu (hzhu)
Date: 2002-03-11 13:19

Message:
Logged In: YES 
user_id=36871

Tim's patch works as advertized on the original box (SuSE
7.1) where the problem was found.  That is,
./configure;make;python gives zero for underflow and
OverflowError for overflow.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 17:20

Message:
Logged In: YES 
user_id=31435

Thanks, all!   That confirmed success on each kind of box 
originally complained about, and others I didn't know 
about.  Closing this now.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-09 11:18

Message:
Logged In: NO 

This problem was fixed in Python-20020309 for my box.  I am
running Debian Gnu Linux 2.2.19 ppc on a New World iMac.
The default configure did not add -lieee to LIBS and that
python did not give the underflow errors that python2.2
did.

----------------------------------------------------------------------

Comment By: Christopher Lee (clee)
Date: 2002-03-09 09:31

Message:
Logged In: YES 
user_id=1426

Tim Peter's fix in CVS looks good on my machine:

redhat 7.2, linux kernel 2.4.17, glibc 2.2.4-19.3, gcc 2.96-98

Python 2.3a0 (check out from cvs Sat Mar  9 11:26:31 CST 2002)

 ./python test_ieee.py 
x = 1e200
y = 1/x
check math.pow(x, 2): got math range error -OK
check math.pow(y, 2): got zero-OK
check pow(x, 2) got (34, 'Numerical result out of range') -OK
check pow(y, 2) got zero-OK
check x**2 got (34, 'Numerical result out of range') -OK
check y**2 got zero-OK

when running the following code
import math
x = 1e200
y = 1/x
print "x = 1e200"
print "y = 1/x"

try:
    print "check math.pow(x, 2):", 
    math.pow(x, 2)  # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"


print "check math.pow(y, 2):", 
a=math.pow(y, 2)  # expect 0.
if a == 0.0:
    print "got zero-OK"
else:
    print "didn't get zero-FAIL"

try:
    print "check pow(x, 2)", 
    pow(x, 2)       # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check pow(y, 2)", 
a=pow(y, 2)       # expect 0.
if a == 0.0: print "got zero-OK"

try:
    print "check x**2",
    x**2            # expect OverflowError
except  OverflowError, msg:
    print "got", msg, "-OK"

print "check y**2",
a=y**2            # expect 0.
if a==0.0:
    print "got zero-OK"





----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-09 07:24

Message:
Logged In: YES 
user_id=33168

RedHat 7.2, glibc-2.2.4-13

Before patch:
   w/o -lieee    w/-lieee
   FAILED        Passed

After patch:
   w/o -lieee    w/-lieee
   Passed        Passed

Works for me.
I also attached a modified script to what Tim posted on
python-dev which prints out if there is a problem.  Silence
is golden.

----------------------------------------------------------------------

Comment By: Andrew Dalke (dalke)
Date: 2002-03-08 23:52

Message:
Logged In: YES 
user_id=190903

Red Hat Linux release 6.2, with some updates.
Running on an Alpha box.  No changes to -ieee flag
(both compiled without -ieee)

Compared stock Python 2.2 vs. most recent CVS.

Using Python 2.2:
pow(1e-200, 2) and 1e-200**2 give OverflowError

Current CVS:
pow(1e-200, 2) and 1e-200**2 give 0.0


----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-08 22:18

Message:
Logged In: YES 
user_id=76089

Python 2.2 on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give OverflowError
Current CVS Python on OpenBSD 2.7:
pow(1e-200, 2) and 1e-200**2 give 0.0

I did not do anything with -lieee, just ./configure && make


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-08 21:45

Message:
Logged In: YES 
user_id=31392

Tests work as expected on my Linux box (originally a RedHat 
6.2 system, with a bunch of upgrades, including glibc 
2.1).  The tests show the same results regardless of 
whether I link with -lieee.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 21:00

Message:
Logged In: YES 
user_id=31435

I'm hoping this is fixed in CVS now.  Since we're never 
going to sort out the Linux config mess, it tries to worm 
around it via more macros.

Include/pyport.h; new revision: 2.45
Modules/cmathmodule.c; new revision: 2.28
Objects/floatobject.c; new revision: 2.111

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 19:43

Message:
Logged In: YES 
user_id=31435

Python used to link with -lieee.  Rev 1.139 of configure.in 
changed that.  The checkin comment is:

"""
Gregor Hoffleit: Don't link with the libieee library if 
it's not necessary
"""

Thanks, Gregor <wink/sigh>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-08 19:40

Message:
Logged In: YES 
user_id=31435

Assigned to me, because the Linux weenies are apparently 
too frightened of radix points to get near this <wink>.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-05 16:01

Message:
Logged In: YES 
user_id=31435

Changed Group to "Platform specific" and added "[2.2]" to 
the Summary line instead.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-04 16:48

Message:
Logged In: YES 
user_id=31435

Boosted priority.  I'd assign to me, except I don't know 
anything about Linux config.

Paul Rubin reported success (no more bogus OverflowError) 
after

"""
I manually put "-lieee" into the LIBS=... line in the 
makefile and rebuilt.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525705&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 15:10:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 07:10:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E16oQgZ-0005HT-00@usw-sf-web4.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 15:29:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 07:29:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16oQyT-00050m-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 09:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 05:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 12:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 15:29:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 07:29:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16oQyY-0005Uf-00@usw-sf-web4.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 15:43:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 07:43:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16oRCn-0002dt-00@usw-sf-web3.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 15:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:15:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:15:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-531398 ] 221 still doesn't work on OS 8.1
Message-ID: <E16oRhS-0002wv-00@usw-sf-web3.sourceforge.net>

Bugs item #531398, was opened at 2002-03-18 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: 221 still doesn't work on OS 8.1

Initial Comment:
The current problem is that InterfaceLib--FSRenameUnicode is undefined. Let's try and weak-link InterfaceLib and hope that doesn't cause a string of new problems.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-22 17:15

Message:
Logged In: YES 
user_id=45365

It is not fair. Fixed the Res problem and another one shows up in QuickDraw. The fix (forthcoming) is that all toolbox modules will be weak linked and all interface methods protected against non-existing underlying API routines.

Oh well, this is something that was on my to-do list anyway.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-21 22:13

Message:
Logged In: YES 
user_id=45365

This problem has been fixed, but a new (related?) one has turned up: ConfigurePythonClassic doesn't run. This also shows up on MacOS 8.6, which should make it easier to debug (as I have access to 8.6).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:31:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:31:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-531966 ] email: problems generating multipart msg
Message-ID: <E16oRx8-00038A-00@usw-sf-web3.sourceforge.net>

Bugs item #531966, was opened at 2002-03-19 13:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
>Status: Closed
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Barry Warsaw (bwarsaw)
Summary: email: problems generating multipart msg

Initial Comment:
As reported in comp.lang.python, the example program 
given in Doc/lib/email.tex to wrap up a whole 
directory as a MIME message doesn't work if the 
directory is empty or contains only a single file.

As that script is fairly long, I've attached a 
shorter example script which also demonstrates the 
bug; coincidentally, I hit it yesterday at work.
The script crashes with:

  File 
"/data/python2/dist/src/Lib/email/Generator.py", line 
236, in _handle_multipart
    for part in msg.get_payload():
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 152, in __getitem__
    return self.get(name)
  File "/data/python2/dist/src/Lib/email/Message.py", 
line 215, in get
    name = name.lower()
AttributeError: 'int' object has no attribute 'lower'



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-22 11:31

Message:
Logged In: YES 
user_id=12800

Fixed in Python 2.2.1c1+, Lib/email/Generator.py 1.6.10.1

I changed the group to 2.2.1c1 because I will be merging
this fix into the standalone email package and Python 2.3
separately.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531966&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:44:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:44:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-531262 ] Wrong result for Canvas.tag_bind(t, s)
Message-ID: <E16oS92-0006Ix-00@usw-sf-web4.sourceforge.net>

Bugs item #531262, was opened at 2002-03-18 04:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Brunel (ebrunel)
>Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong result for Canvas.tag_bind(t, s)

Initial Comment:
When a binding is defined for a tag in a Tkinter 
Canvas, trying to get the callback using the 
"tag_bind" method with 2 parameters returns a useless 
value:

----------------------------
from Tkinter import *

root = Tk()

## Create the canvas
c = Canvas(root)
c.pack()

## Create the item
tId = c.create_text(100, 100, text='spam')

## Create the binding
def foo(event): print 'bar'
c.tag_bind(tId, '<Button-1>', foo)

## Get and print the binding
print c.tag_bind(tId, '<Button-1>')

root.mainloop()
---------------------------

The programs prints something looking like: 'if 
{"[136128196foo %# %b %f %h %k %s %t %w %x %y %A %E 
%K %N %W %T %X %Y %D]" == "break"} break'. Trying to 
pass this value as the third parameter of tag_unbind 
for example results in a TclError:

Traceback (most recent call last):
  File "tkCanvasBindings2.py", line 16, in ?
    c.tag_unbind(tId, '<Button-1>', f)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 1904, in 
tag_unbind
    self.deletecommand(funcid)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 297, in 
deletecommand
    self.tk.deletecommand(name)
TclError: can't delete Tcl command

This happens apparently on all platforms (tried 
Win2K, Linux Mandrake 8.0 and Solaris 2.7).



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 11:44

Message:
Logged In: YES 
user_id=11375

I don't think this is actually a bug, and the return 
value of tag_bind really is useless.  tag_bind(t,s) 
returns the command bound to that sequence.  
Tkinter.py supports a feature where a binding can 
return the string "break" if no further bound function 
should be invoked, so when adding a binding, Python has 
to synthesize the 'if {123456foo ...}' Tcl command, and 
that's what tag_bind returns.

I think your example code should be written as:

bind_id = c.tag_bind(tId, '<Button-1>', foo)

And then refer to bind_id when you need to delete the 
binding.  

Was your example usage of tag_bind() described in some 
documentation, or in a demo script somewhere?  
Maybe that script or documentation needs to be fixed.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:53:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:53:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] README Warns of strftime, Add calendar.
Message-ID: <E16oSIY-0002rz-00@usw-sf-web1.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: README Warns of strftime, Add calendar.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 16:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 15:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 12:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:56:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:56:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oSKw-0002uf-00@usw-sf-web1.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
>Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 16:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 15:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 12:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:56:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:56:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-487703 ] Replace strcat, strcpy
Message-ID: <E16oSL7-0005zG-00@usw-sf-web2.sourceforge.net>

Bugs item #487703, was opened at 2001-11-30 22:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&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: Replace strcat, strcpy

Initial Comment:
Alex Martelli sent this URL for a paper describing the 
safer strlcat and strlcpy functions:

>http://www.usenix.org/events/usenix99/full_papers/mill
ert/millert_html/>

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 16:56

Message:
Logged In: YES 
user_id=35752


If they want people to use their code why do they put that
stupid clause in the license?  How annoying.  Attached is
a strlcpy function that I wrote based on the man page:

http://www.tac.eu.org/cgi-bin/man-cgi?strlcpy+3

Do whatever you like with it. :-)  I would appreciate it if
someone would review the code however.  There are a number
of corner cases that are easy to screw up.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 22:51

Message:
Logged In: YES 
user_id=6380

Strictly speaking, binary Python distributions would be
required to contain a copy of the entire license for that
file. I don't like that.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-03 18:59

Message:
Logged In: YES 
user_id=31435

I'm attaching a patch from Alex Martelli; haven't reviewed 
it, and don't expect to before 2.2 final is released.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-03 10:47

Message:
Logged In: YES 
user_id=38388

Time for PyOS_strlcat() and PyOS_strlcpy() ? Looking at the web-site it seems that we could simply copy the 
code into the Python distro. I'd then suggest to bundle all the string helpers into a new file: e.g. mystrapis.c.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487703&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 16:59:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 08:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E16oSNh-00061G-00@usw-sf-web2.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:08:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:08:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oSX8-00033y-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:09:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:09:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E16oSXl-00068y-00@usw-sf-web2.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
Assigned to: Guido van Rossum (gvanrossum)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:10:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:10:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oSZ5-00035h-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:12:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:12:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-531262 ] Wrong result for Canvas.tag_bind(t, s)
Message-ID: <E16oSak-0006eZ-00@usw-sf-web4.sourceforge.net>

Bugs item #531262, was opened at 2002-03-18 09:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470

Category: Tkinter
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Eric Brunel (ebrunel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong result for Canvas.tag_bind(t, s)

Initial Comment:
When a binding is defined for a tag in a Tkinter 
Canvas, trying to get the callback using the 
"tag_bind" method with 2 parameters returns a useless 
value:

----------------------------
from Tkinter import *

root = Tk()

## Create the canvas
c = Canvas(root)
c.pack()

## Create the item
tId = c.create_text(100, 100, text='spam')

## Create the binding
def foo(event): print 'bar'
c.tag_bind(tId, '<Button-1>', foo)

## Get and print the binding
print c.tag_bind(tId, '<Button-1>')

root.mainloop()
---------------------------

The programs prints something looking like: 'if 
{"[136128196foo %# %b %f %h %k %s %t %w %x %y %A %E 
%K %N %W %T %X %Y %D]" == "break"} break'. Trying to 
pass this value as the third parameter of tag_unbind 
for example results in a TclError:

Traceback (most recent call last):
  File "tkCanvasBindings2.py", line 16, in ?
    c.tag_unbind(tId, '<Button-1>', f)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 1904, in 
tag_unbind
    self.deletecommand(funcid)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 297, in 
deletecommand
    self.tk.deletecommand(name)
TclError: can't delete Tcl command

This happens apparently on all platforms (tried 
Win2K, Linux Mandrake 8.0 and Solaris 2.7).



----------------------------------------------------------------------

>Comment By: Eric Brunel (ebrunel)
Date: 2002-03-22 17:12

Message:
Logged In: YES 
user_id=489050

In fact, I saw this problem when trying to delete the 
bindings made for a Canvas: I noticed that when refreshing 
several times a canvas by deleting, then recreating all 
the items (including the bindings), the occupied memory 
increased with no apparent reason. So I dived into 
Tkinter.py, and found out that Tcl commands were created 
for each binding, but were only deleted either when 
deleting the Canvas (which I couldn't do), or when calling 
the tag_unbind method with the tagOrId, the sequence *and* 
the Tcl command name. So I tried to get this command name 
by calling tag_bind, and saw that the result was not what 
I expected.
The solution to remember the result of the call to 
tag_bind creating the binding provides a solution to this 
problem. It may just be a bit strange to explicitely 
remember the bindings in the application, since Tk/Tkinter 
already remembers them. It may also seem strange to get 
via tag_bind something that is completely useless at the 
Python level...

Anyway, thanks a lot.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 16:44

Message:
Logged In: YES 
user_id=11375

I don't think this is actually a bug, and the return 
value of tag_bind really is useless.  tag_bind(t,s) 
returns the command bound to that sequence.  
Tkinter.py supports a feature where a binding can 
return the string "break" if no further bound function 
should be invoked, so when adding a binding, Python has 
to synthesize the 'if {123456foo ...}' Tcl command, and 
that's what tag_bind returns.

I think your example code should be written as:

bind_id = c.tag_bind(tId, '<Button-1>', foo)

And then refer to bind_id when you need to delete the 
binding.  

Was your example usage of tag_bind() described in some 
documentation, or in a demo script somewhere?  
Maybe that script or documentation needs to be fixed.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:24:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:24:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-528295 ] asyncore unhandled write event
Message-ID: <E16oSmG-0003G9-00@usw-sf-web1.sourceforge.net>

Bugs item #528295, was opened at 2002-03-10 19:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Carl J. Nobile (cnobile)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore unhandled write event

Initial Comment:
I'm getting an unhandled write event on a handle_accept
callback in asyncore.dispatch. This worked fine in
python-2.1.1, but now seems to be broken in python-2.2.

This happens when I send a SIGHUP to reread my config
file. The signal lets me break out of the
asyncore.loop() to reread the configuration and restart
the server. The self.accept() method returns a TypeNone
instead of the expected tuple when it is called in
handle_accept.

I've written a database key server which is a fairly
large package and is dependent on a few other packages,
so sending the code would not be too easy. If I can
duplicate the problem in a few lines of code I will
send it along at a later date.

Thanks for your attention.

Carl

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 12:24

Message:
Logged In: YES 
user_id=11375

Revision 1.25 of asyncore.py is responsible.  It 
catches EINTR and silently swallows the error, so 
sending signals to the process now doesn't cause it to 
exit asyncore's loop() at all.  I don't see any 
unhandled write event at all.

I'm not sure what to do here, and will take it up on 
python-dev.



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-20 22:47

Message:
Logged In: YES 
user_id=482117

Okay, The version of asyncore.py from 2.1.1 when put into
the 2.2 release solves the problem, so the bug seems to be
in asyncore.py. I have cobbled together a server that
displays the same error and am including it here. When run
in 2.1.1 it works fine, reloading the config (just a print)
with a kill -1 pid and terminating with a kill pid.
Carl

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-16 15:36

Message:
Logged In: YES 
user_id=11375

The asyncore.py in 2.1.1 seems to be revision 1.10 of 
the file; it's rev. 1.28 in 2.2 and is now at 1.30, so 
there have been a number of changes to asyncore, though 
none seem relevant.  Did you try your code on 2.2 with 
the 2.1.1
asyncore?  That would let us figure out if it's due to 
a change in asyncore or the underlying socket or select
module.

(Actually, another thing to check is whether the select 
or the poll module is being used; maybe that changed 
for you between 2.1.1 and 2.2.)



----------------------------------------------------------------------

Comment By: Carl J. Nobile (cnobile)
Date: 2002-03-14 21:52

Message:
Logged In: YES 
user_id=482117

My question then is why didn't it do this when I ran my app
with python 2.1.1. Something has changed in 2.2 and I don't
think it was asyncore, I do know some work was done to the
low level socket and select modules so they could handle
IPV6. I understand why the None is being returned, but an
accept shouldn't even be called on a write event coming from
a select or poll.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-14 18:24

Message:
Logged In: YES 
user_id=11375

Looking at the implementation of accept() in asyncore.py, it will 
return 
None when the socket is in non-blocking mode and the accept() would block.  
There's really nothing else accept() could
return in this case, so you'll 
probably have to write your code to 
handle this case.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528295&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:29:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:29:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16oSqv-0006O7-00@usw-sf-web2.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:29

Message:
Logged In: YES 
user_id=21627

Can you use a debugger to find out and report where it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:29:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:29:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16oSrW-0006OL-00@usw-sf-web2.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:29

Message:
Logged In: YES 
user_id=21627

Can you please also report which compiler you have been using?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:29

Message:
Logged In: YES 
user_id=21627

Can you use a debugger to find out and report where it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:35:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:35:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16oSwW-0006Se-00@usw-sf-web2.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 16:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:35:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:35:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16oSx8-0006vS-00@usw-sf-web4.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=31435

It would help if you simply tried your example under 2.1 -- 
I don't have your system, and can't try it for you.  It's 
extraordinarily risky making any last-second change to a 
bugfix release, and whether it's an old bug feeds into the 
tradeoff calculation.

Enabling -lieee at the last second isn't something I'll do 
without lots of people swearing it doesn't hurt anything on 
their boxes.  Not all systems act the same way in the 
presence of -lieee.  The change I did make is in our C 
code, where I have a good chance of guessing what various C 
compilers will do; -lieee does whatever a platform feels 
like doing, and there's no standard to constrain it.

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-22 08:53

Message:
Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 14:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:36:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:36:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-533291 ] __reduce__ does not work as documented
Message-ID: <E16oSxl-0003sd-00@usw-sf-web3.sourceforge.net>

Bugs item #533291, was opened at 2002-03-21 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470

>Category: Documentation
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Schemenauer (nascheme)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __reduce__ does not work as documented

Initial Comment:
The documentation for __reduce__ says that the second
element of the returned tuple can either be a tuple
of arguments or None.  The copy module does not handle
the None case:

  class C(object):
    def __reduce__(self):
        return (C, None)

  import copy
  copy.copy(C())



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=6380

So be it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 12:09

Message:
Logged In: YES 
user_id=35752

I would prefer that the None version be deprecated.  The
documentation for __reduce__ is confusing enough as it is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 11:59

Message:
Logged In: YES 
user_id=6380

I'm not sure it's that simple. While pickling a C instance
indeed succeed, unpickling it raises a strange exception:

>>> pickle.loads(pickle.dumps(C()))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/home/guido/trunk/Lib/pickle.py", line 982, in loads
    return Unpickler(file).load()
  File "/home/guido/trunk/Lib/pickle.py", line 593, in load
    dispatch[key](self)
  File "/home/guido/trunk/Lib/pickle.py", line 842, in
load_reduce
    value = callable.__basicnew__()
AttributeError: type object 'C' has no attribute
'__basicnew__'
>>>

It appears that an argument tuple of None signals some
special Jim-Fulton-only behavior. __basicnew__ is a feature
of ExtensionClasses (similar to __new__ in Python 2.2), and
while ExtensionClasses work in 2.2, they're being
deprecated: Zope 2.x will continue to use Python 2.1.x, and
Zope 3 will require Python 2.2 or higher.

The copy module has never worked for ExtensionClass
instances (unless maybe the class defines a __copy__
method).

Maybe the right thing to do is to document 'None' as a
special case that one shouldn't use, and deprecate
__basicnew__?

(Hm, OTOH why don't I just approve your fix so we can stop
thinking about this. :-)

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 10:10

Message:
Logged In: YES 
user_id=35752

Added trivial patch to fix copy.py module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533291&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:50:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:50:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16oTBe-0006g4-00@usw-sf-web2.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:53:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:53:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16oTDp-0006iA-00@usw-sf-web2.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:53:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:53:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-531262 ] Wrong result for Canvas.tag_bind(t, s)
Message-ID: <E16oTEU-0006iJ-00@usw-sf-web2.sourceforge.net>

Bugs item #531262, was opened at 2002-03-18 04:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470

Category: Tkinter
>Group: Not a Bug
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Eric Brunel (ebrunel)
>Assigned to: A.M. Kuchling (akuchling)
Summary: Wrong result for Canvas.tag_bind(t, s)

Initial Comment:
When a binding is defined for a tag in a Tkinter 
Canvas, trying to get the callback using the 
"tag_bind" method with 2 parameters returns a useless 
value:

----------------------------
from Tkinter import *

root = Tk()

## Create the canvas
c = Canvas(root)
c.pack()

## Create the item
tId = c.create_text(100, 100, text='spam')

## Create the binding
def foo(event): print 'bar'
c.tag_bind(tId, '<Button-1>', foo)

## Get and print the binding
print c.tag_bind(tId, '<Button-1>')

root.mainloop()
---------------------------

The programs prints something looking like: 'if 
{"[136128196foo %# %b %f %h %k %s %t %w %x %y %A %E 
%K %N %W %T %X %Y %D]" == "break"} break'. Trying to 
pass this value as the third parameter of tag_unbind 
for example results in a TclError:

Traceback (most recent call last):
  File "tkCanvasBindings2.py", line 16, in ?
    c.tag_unbind(tId, '<Button-1>', f)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 1904, in 
tag_unbind
    self.deletecommand(funcid)
  File "/usr/local/lib/python2.1/lib-tk/Tkinter.py", 
line 297, in 
deletecommand
    self.tk.deletecommand(name)
TclError: can't delete Tcl command

This happens apparently on all platforms (tried 
Win2K, Linux Mandrake 8.0 and Solaris 2.7).



----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=11375

You're welcome.  Closing this bug report...

----------------------------------------------------------------------

Comment By: Eric Brunel (ebrunel)
Date: 2002-03-22 12:12

Message:
Logged In: YES 
user_id=489050

In fact, I saw this problem when trying to delete the 
bindings made for a Canvas: I noticed that when refreshing 
several times a canvas by deleting, then recreating all 
the items (including the bindings), the occupied memory 
increased with no apparent reason. So I dived into 
Tkinter.py, and found out that Tcl commands were created 
for each binding, but were only deleted either when 
deleting the Canvas (which I couldn't do), or when calling 
the tag_unbind method with the tagOrId, the sequence *and* 
the Tcl command name. So I tried to get this command name 
by calling tag_bind, and saw that the result was not what 
I expected.
The solution to remember the result of the call to 
tag_bind creating the binding provides a solution to this 
problem. It may just be a bit strange to explicitely 
remember the bindings in the application, since Tk/Tkinter 
already remembers them. It may also seem strange to get 
via tag_bind something that is completely useless at the 
Python level...

Anyway, thanks a lot.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 11:44

Message:
Logged In: YES 
user_id=11375

I don't think this is actually a bug, and the return 
value of tag_bind really is useless.  tag_bind(t,s) 
returns the command bound to that sequence.  
Tkinter.py supports a feature where a binding can 
return the string "break" if no further bound function 
should be invoked, so when adding a binding, Python has 
to synthesize the 'if {123456foo ...}' Tcl command, and 
that's what tag_bind returns.

I think your example code should be written as:

bind_id = c.tag_bind(tId, '<Button-1>', foo)

And then refer to bind_id when you need to delete the 
binding.  

Was your example usage of tag_bind() described in some 
documentation, or in a demo script somewhere?  
Maybe that script or documentation needs to be fixed.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531262&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:54:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:54:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oTFC-00079t-00@usw-sf-web4.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 18:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 11:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 17:58:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 09:58:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16oTJ0-0006m3-00@usw-sf-web2.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 10:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 12:58

Message:
Logged In: YES 
user_id=31435

Peter, no, there have been no other reports of this on 64-
bit platforms.  If possible, try recompiling longobject.c 
with optimization disabled.  Its internal long_format() 
routine is complicated so has a better-than-usual chance of 
provoking bad code generation. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:29

Message:
Logged In: YES 
user_id=21627

Can you please also report which compiler you have been using?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:29

Message:
Logged In: YES 
user_id=21627

Can you use a debugger to find out and report where it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:00:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:00:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oTKm-0007EE-00@usw-sf-web4.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 18:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 19:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 11:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:08:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:08:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oTSr-0003mJ-00@usw-sf-web1.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 12:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 10:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 09:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 05:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 12:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:23:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:23:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oTgq-00074I-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 13:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 13:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 13:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 10:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 07:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 13:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:29:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:29:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16oTn6-000423-00@usw-sf-web1.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:34:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:34:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oTsQ-0007DD-00@usw-sf-web2.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 18:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:35:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:35:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E16oTsZ-00048T-00@usw-sf-web1.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 21:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-16 01:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 21:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:36:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:36:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oTuA-0007Et-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 12:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 12:36

Message:
Logged In: YES 
user_id=44345

reclosing - thanks for the better fix (v. 1.26)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 12:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 12:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 10:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 09:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 05:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 12:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:37:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:37:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
Message-ID: <E16oTuV-00049j-00@usw-sf-web1.sourceforge.net>

Bugs item #526382, was opened at 2002-03-06 13:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout

Initial Comment:
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)






----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:37

Message:
Logged In: YES 
user_id=35752

This doesn't look like a bug to me.  Can we close it?

----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 15:47

Message:
Logged In: YES 
user_id=126343

The reason why they don't use raw_input in non-human interactive programs 
is because it doesn't work like they expect. They usually end up doing 
something like this:

print "Your next command > ",
sys.stdout.flush()
command = sys.stdin.readline() (or something)

Take a look at http://www.freenetpages.co.uk/hp/alan.gauld/tutinput.htm (in 
the yellow box in the middle of the page) for a common idiom with a good 
explanation of why. He is reading interactive input from a non-human user.

PS. I apologize for playing with the priority. I was under the impression that 
bugs/patches just weren't watched. It was more an experiment to see if there 
really was anyone out there paying attention.



----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 15:39

Message:
Logged In: YES 
user_id=126343

Here's some more info on the subject for those who are interested.

First off, C behaves the way Python does in this regard. So it is consistent with 
the way most programs work in Unix.

Second off, what I really should be doing is using a pseudo-tty, not plain old 
pipes. Tk has something called "expect" that does what you would expect. 
There is a project for expect for python at expectpy - 
http://sf.net/projects/expectpy

Third off, the reason why I got so excited was because I had been screwing 
around with this for a very long time. I knew it was something that was done 
elsewhere in the Unix world, I just didn't know how to do it properly. The 
behavior is totally unexpected for a newbie like me. And when I finally 
climbed through the hole at the top and understood what was happening, I 
was really upset that things were the way they were.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 13:47

Message:
Logged In: YES 
user_id=6380

No reason to get so upset about this. Nobody that I know
uses raw_input() in non-interactive programs. You can help
yourself by using sys.stdin.readline() instead of
raw_input(), and using an explicit sys.stdout.flush() in
your program. If you're not reading interactive input from a
real human user, that's what you should do.

PS. Don't play games with the priority.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:44:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:44:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-529750 ] Circular reference makes Py_Init crash
Message-ID: <E16oU1P-0004Eb-00@usw-sf-web1.sourceforge.net>

Bugs item #529750, was opened at 2002-03-14 04:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam M. Fass (afass)
Assigned to: Nobody/Anonymous (nobody)
Summary: Circular reference makes Py_Init crash

Initial Comment:
Call Py_Initialize(), create two objects that 
reference each other, then call Py_Finalize() and 
then Py_Intialize() again.  This crashes Python with 
the following error message:

Fatal Python error: UNREF invalid object

The documentation on Py_Finalize() mentions that 
circular references will cause memory leaks, but it 
does not mention this behavior.

Platform info:
* Windows XP
* Visual C++ 6.0
* Python 2.2

------------------------------

#include "Python.h"

int main(int argc, char* argv[])
{
	char *code1 = "class TestClass:\n\ti = 3\nt1 
= TestClass()\nt2 = TestClass()\nt1.t = t2\nt2.t = 
t1";
	Py_Initialize();

	PyRun_SimpleString(code1);

	Py_Finalize();

	Py_Initialize();
	Py_Finalize();
}

------------------------------

The string "code1" contains this python code:

class TestClass:
   i = 3
t1 = TestClass()
t2 = TestClass()
t1.t = t2
t2.t = t1

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:44

Message:
Logged In: YES 
user_id=35752

I can't reproduce this on Linux with the latest CVS code.
I tried with and without Py_DEBUG defined.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529750&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 18:50:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 10:50:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-410993 ] linuxaudiodev fails during "make test".
Message-ID: <E16oU7H-0007o5-00@usw-sf-web4.sourceforge.net>

Bugs item #410993, was opened at 2001-03-24 10:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
Resolution: Accepted
Priority: 4
Submitted By: Sean Reifschneider (jafo)
Assigned to: Nobody/Anonymous (nobody)
>Summary: linuxaudiodev fails during "make test".

Initial Comment:
Picked up 2.1b2 and did "./configure" and "make test"
on a RedHat 7.0-based system:

test test_linuxaudiodev crashed -- linuxaudiodev.error:
(11, 'Resource temporarily unavailable')

Was running build as root, and "mpg123" runs
successfully before and after.  This is on a ThinkPad
240 with esssolo1 driver with 2.2.18 kernel.

Sean

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:50

Message:
Logged In: YES 
user_id=35752

Patch 489989 has already been checked in and should
have fixed this bug.  I'm going to close it.

----------------------------------------------------------------------

Comment By: Charles G Waldman (cgw)
Date: 2001-12-06 20:43

Message:
Logged In: YES 
user_id=7151

Please see patch #489989 and the comments attached there.

I have submitted a patch with the minimal fix.  

The reason this took so long was that I started working 
on a complete replacement for the audio output modules,
which would detect ALSA/OSS/esd/etc, then I discovered the
"libao" audio output library which does this.  I think that
any future work on an audio module for Python should just
wrap libao.  

Patch 489989 can't do any harm, and it might help.


----------------------------------------------------------------------

Comment By: Charles G Waldman (cgw)
Date: 2001-09-05 18:36

Message:
Logged In: YES 
user_id=7151

I've been out of town and somewhat out of the loop.
But I'm back now.  I will look into this over the
weekend.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 17:56

Message:
Logged In: YES 
user_id=6380

Charles, are you still interested in tackling this bug? If
not, let us know!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-11 04:27

Message:
Logged In: YES 
user_id=6380

We've gone back and forth over this one.

It seems to happen for certain drivers for certain audio
cards -- the problem has disappeared for most folks, but
still works for some hardware (e.g. some Dell laptops
running Mandrake).

I've assigned this to Charles Waldman since he seems to know
this area; he commented in python-dev that the
initialization order is invalid.

Charles if you still feel you won't touch this module
(because you'd rather give us a new module that does the
right thing), please close it as Won't Fix -- that's what I
almost did until I remembered your interest.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 16:36

Message:
Logged In: YES 
user_id=6380

I think you misread his comment. He wasn't mpg123 *during*
the test, he ran it before and after the test to verify that
in fact his audio was in good working order.

But, I do suggest to him to try the CVS version, which is
one (relevant) fix ahead of 2.1b2.

That version passes the test for me, but I don't hear a
thing, so I'm not sure what's going on...

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-11 14:19

Message:
Logged In: YES 
user_id=31392

I think we should report this failure as "test skipped."  I
think it
would be essentially correct: The test was skipped because
the 
device was in use.  It's not a crash.

Not sure how this test is affected by the recent changes to
the module to handle EAGAIN.
 
Sean or Guido-- can you try it with the updated module?  My
Linux audio config is screwed up.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410993&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:02:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:02:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16oUJJ-0004SG-00@usw-sf-web1.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:02

Message:
Logged In: YES 
user_id=31435

Yes, the installer hasn't changed, and won't for 2.2.1 
unless somebody other than me can make time to do it.  That 
seems unlikely to the point of fantasy, alas.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:12:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:12:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-474992 ] python version benchmark
Message-ID: <E16oUSQ-0007dl-00@usw-sf-web2.sourceforge.net>

Bugs item #474992, was opened at 2001-10-25 18:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474992&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: python version benchmark

Initial Comment:

This is not a bug per se, but following instructions by
Tim Peters the One :), I'm submitting here the
benchmark script.

I'm getting currently the following final output
(bench.txt):

version   bench1    nogc  bench2
1.5.2        0 %
2.0         48 %    33 %    21 %
2.1.1       53 %    35 %    25 %
2.2         51 %    35 %    23 %

where:

bench1 = original python 1.5.2 script 
nogc = bench1 when disabling gc
bench2 = bench1 script 'rewritten' for python 2.0 and
latter (string methods, sre -> pre...)

These numbers are high...

Frederic Giacometti

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 19:12

Message:
Logged In: YES 
user_id=35752

The number are lower for 2.3a0.  I'm closing this silly
"bug" report fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474992&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:12:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:12:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E16oUSx-0004a1-00@usw-sf-web1.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 16:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:12

Message:
Logged In: YES 
user_id=31435

I haven't tried the patch, but yes, it looks sane to me.  A 
deprecated module is definitely a poor place to add a new 
feature <wink>; it makes as much sense as a string method 
as, say, .upper(), right?  That is, why not?  String in, 
string out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 13:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-15 20:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 16:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:25:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:25:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-526382 ] raw_input does not flush stdout
Message-ID: <E16oUf5-0004u5-00@usw-sf-web1.sourceforge.net>

Bugs item #526382, was opened at 2002-03-06 08:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Nobody/Anonymous (nobody)
Summary: raw_input does not flush stdout

Initial Comment:
I know this has been talked about before. I am curious as to why it has 
not been fixed.

raw_input does not flush stdout before reading from stdin. This is a 
problem because if stdin and stdout are not terminals, then stdout will 
not be flushed, and the "user" will not know when he is being prompted.

Of course, I can use -u at the command line for python, but I don't want 
everything flushed every time stdout is written to. I only want it flushed 
when it is waiting for input. There is the potential for a large amount of 
data to be transmitted, and flushing everything can slow it way down. 
(Imagine 1000's of print statements, all flushing after they are done. 
Silly, isn't it?)






----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:25

Message:
Logged In: YES 
user_id=31435

Closing as WontFix.  Until Python implements its own I/O 
(probably never), it inherits C's I/O model, and that's "a 
feature".  All I/O models are subtle, even before Guido was 
born <wink>.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 13:37

Message:
Logged In: YES 
user_id=35752

This doesn't look like a bug to me.  Can we close it?

----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 10:47

Message:
Logged In: YES 
user_id=126343

The reason why they don't use raw_input in non-human interactive programs 
is because it doesn't work like they expect. They usually end up doing 
something like this:

print "Your next command > ",
sys.stdout.flush()
command = sys.stdin.readline() (or something)

Take a look at http://www.freenetpages.co.uk/hp/alan.gauld/tutinput.htm (in 
the yellow box in the middle of the page) for a common idiom with a good 
explanation of why. He is reading interactive input from a non-human user.

PS. I apologize for playing with the priority. I was under the impression that 
bugs/patches just weren't watched. It was more an experiment to see if there 
really was anyone out there paying attention.



----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 10:39

Message:
Logged In: YES 
user_id=126343

Here's some more info on the subject for those who are interested.

First off, C behaves the way Python does in this regard. So it is consistent with 
the way most programs work in Unix.

Second off, what I really should be doing is using a pseudo-tty, not plain old 
pipes. Tk has something called "expect" that does what you would expect. 
There is a project for expect for python at expectpy - 
http://sf.net/projects/expectpy

Third off, the reason why I got so excited was because I had been screwing 
around with this for a very long time. I knew it was something that was done 
elsewhere in the Unix world, I just didn't know how to do it properly. The 
behavior is totally unexpected for a newbie like me. And when I finally 
climbed through the hole at the top and understood what was happening, I 
was really upset that things were the way they were.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 08:47

Message:
Logged In: YES 
user_id=6380

No reason to get so upset about this. Nobody that I know
uses raw_input() in non-interactive programs. You can help
yourself by using sys.stdin.readline() instead of
raw_input(), and using an explicit sys.stdout.flush() in
your program. If you're not reading interactive input from a
real human user, that's what you should do.

PS. Don't play games with the priority.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526382&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:27:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:27:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-474992 ] python version benchmark
Message-ID: <E16oUhg-0008MQ-00@usw-sf-web4.sourceforge.net>

Bugs item #474992, was opened at 2001-10-25 14:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474992&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Frederic Giacometti (giacometti)
Assigned to: Nobody/Anonymous (nobody)
Summary: python version benchmark

Initial Comment:

This is not a bug per se, but following instructions by
Tim Peters the One :), I'm submitting here the
benchmark script.

I'm getting currently the following final output
(bench.txt):

version   bench1    nogc  bench2
1.5.2        0 %
2.0         48 %    33 %    21 %
2.1.1       53 %    35 %    25 %
2.2         51 %    35 %    23 %

where:

bench1 = original python 1.5.2 script 
nogc = bench1 when disabling gc
bench2 = bench1 script 'rewritten' for python 2.0 and
latter (string methods, sre -> pre...)

These numbers are high...

Frederic Giacometti

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:27

Message:
Logged In: YES 
user_id=31435

I wouldn't call it "silly", and if it had been possible to 
make time for it, I think it would have been valuable to 
figure out why these simple operations suffered so much 
across releases.  I agree with closing it, though, as it's 
become apparent nobody will ever have time to dig into it.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 14:12

Message:
Logged In: YES 
user_id=35752

The number are lower for 2.3a0.  I'm closing this silly
"bug" report fixed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474992&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 19:38:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 11:38:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-533735 ] cut-o/paste-o in Marshalling doc: 2.2.1
Message-ID: <E16oUsB-0008Tf-00@usw-sf-web4.sourceforge.net>

Bugs item #533735, was opened at 2002-03-22 19:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533735&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Scott David Daniels (scott_daniels)
Assigned to: Nobody/Anonymous (nobody)
Summary: cut-o/paste-o in Marshalling doc: 2.2.1

Initial Comment:
Not very hard to figure out, but easy enough to fix:

5.4 Data marshalling support

>>> (A)
void PyMarshal_WriteObjectToFile(PyObject *value, FILE 
*file) 
Marshal a Python object, value, to file. This will 
only write the least-significant 16 bits of value; 
regardless of the size of the native short type.

>>> The final sentence should be dropped (or moved to 
spot XYZ)

>>> (B)
int PyMarshal_ReadShortFromFile(FILE *file) 
Return a C short from the data stream in a FILE* 
opened for reading. Only a 16-bit value can be read in 
using this function, regardless of the native size of 
long. 

>>> perhaps "... native size of short."  (this is XYZ)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533735&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:04:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:04:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oVGc-0008IJ-00@usw-sf-web2.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 22:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:27:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:27:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E16oVdP-0000bV-00@usw-sf-web4.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 21:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:27

Message:
Logged In: YES 
user_id=35752

Okay, I moved unquote to a method of str.  I also fixed
pickle.py and the tests (no need to test for insecure
strings).

Fred, do you have to time to write documentation for 
_PyString_Unquote and str.unquote?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 19:12

Message:
Logged In: YES 
user_id=31435

I haven't tried the patch, but yes, it looks sane to me.  A 
deprecated module is definitely a poor place to add a new 
feature <wink>; it makes as much sense as a string method 
as, say, .upper(), right?  That is, why not?  String in, 
string out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-16 01:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 21:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:34:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:34:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oVkZ-00060F-00@usw-sf-web3.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:39:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:39:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-487277 ] Different behavior of readline()
Message-ID: <E16oVp5-0000kj-00@usw-sf-web4.sourceforge.net>

Bugs item #487277, was opened at 2001-11-29 22:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Different behavior of readline()

Initial Comment:
The behavior of readline() has changed on 2.2. This 
should be documented.

Example:

Python 2.1 (#1, Jun 22 2001, 17:13:13)
[GCC 2.95.3 20010315 (release) (conectiva)] on 
linux-i386
Type "copyright", "credits" or "license" for more 
information.
>>> open("/etc").readline()
''

Python 2.2b2+ (#1, Nov 27 2001, 21:39:35)
[GCC 2.95.3 20010315 (release) (conectiva)] on 
linux-ppc
Type "help", "copyright", "credits" or "license" for 
more information.
>>> open("/etc").readline()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 21] Is a directory



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:39

Message:
Logged In: YES 
user_id=35752

Commited as fileobject.c 2.148.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-12 12:46

Message:
Logged In: YES 
user_id=6380

OK,. I buy that argument. I'll take a patch after 2.2. We
really need a "2.3" group here -- for now I've set the group
to feathre request.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-12 08:06

Message:
Logged In: YES 
user_id=21627

Tim was arguing that open("/") fails on some systems,
anyway, since the C library will refuse to open a directory.
So it would be for uniformity's sake that makes it fail on
Posix, as well. I think that fopen() allows to open a
directory is by a similar rationale: if open(2) allows to
open it, fopen(3) should do so as well. That rationale is
already broken: open(2) is needed to read a directory, but
you cannot read a directory if you have a FILE*.

The "used for existence test" argument isn't very
convincing; use access or stat for that (specifically,
os.exists). Of course, changing it might break existing
code, just as changing .readline did.
It is clear that posix.open should forward directly to the
system call, instead of performing checks. It is not so
clear that file() should do the same thing.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 22:50

Message:
Logged In: YES 
user_id=6380

Are we even sure that open("/") should be disallowed? What
if it is used as an existence test? What is allowed by
open() should be the realm of the stdio fopen() function,
and we shouldn't second-guess it. If fopen() allows us to
open directories, why shouldn't we?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 14:22

Message:
Logged In: YES 
user_id=21627

Yes, changing it later is fine.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-03 13:03

Message:
Logged In: YES 
user_id=6380

I take it that this needn't be included in 2.2?  Who knows
what it would break.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-03 09:02

Message:
Logged In: YES 
user_id=21627

I agree that Python should not allow to open a directory.
Attached is a patch that implements this check; it is
somewhat more involved since it must also check file object
that are created through PyFile_FromFile etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-02 20:18

Message:
Logged In: YES 
user_id=31435

Well, my question isn't really about libc but about 
Python:  since Python doesn't expose getdents(2) or readdir
(2), how could it be anything but a mistake for a Python 
user on Linux to try to __builtin__.open() a directory?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-02 13:16

Message:
Logged In: YES 
user_id=21627

Opening a directory is the only way, on Unix, to get its
contents. The file descriptor returned is then passed to
getdents(2) or readdir(2) (depending on the OS version).

__builtins__.open doesn't fail because it calls fopen right
away, which doesn't fail because it calls open(2) with just
O_RDONLY and O_LARGEFILE, not with O_DIRECTORY. open(2) will
then only return EISDIR if the directory is opened for
writing. Since this is the behaviour documented in Posix, it
is unlikely that Linux glibc will change.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-30 22:44

Message:
Logged In: YES 
user_id=38388

For the record, this is what I get with Python 2.2b2 on Linux:
>>> f = open('/home/lemburg/')
>>> f.read()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 21] Is a directory
>>> f.readline()
''
>>> f.readlines()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 21] Is a directory
>>>

Reading the man-page for open(), it seems that directories play some role (though it's not clear which...):

open() options:
...
       O_DIRECTORY
              If pathname is not a directory, cause the  open  to
              fail.   This  flag is Linux-specific, and was added
              in kernel version 2.1.126, to avoid  denial-of-ser­
              vice  problems if opendir(3) is called on a FIFO or
              tape device, but should not be used outside of  the
              implementation of opendir.

errno values:
...
       EISDIR pathname refers  to  a  directory  and  the  access
              requested involved writing.
       EACCES The requested access to the file is not allowed, or
              one of the directories in pathname  did  not  allow
              search  (execute)  permission,  or the file did not
              exist yet and write access to the parent  directory
              is not allowed.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-30 22:26

Message:
Logged In: YES 
user_id=31435

Does anyone know why opening a directory for reading 
doesn't complain on Linux?  It has always complained on 
Windows.  If readline() is doomed to fail, why do we allow 
opening a directory for reading at all?  OTOH, if it's not 
insane to open a directory for reading on Linux, why does 
readline() complain on Linux?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-30 16:07

Message:
Logged In: YES 
user_id=21627

No. I think very few of the changes will ever cause problems
in real software - including this one. I wouldn't be
surprised if this remains the only reported incidence of
that change.

I *am* saying that for every change that has been made, one
could construct an application that breaks under this
change. This theoretical potential for breakage shouldn't
cause prominent appearance in documentation; everybody who
really wants to see documentation for all changes should
consult the CVS logs.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-11-30 14:15

Message:
Logged In: YES 
user_id=7887

I beg your pardon. Are you saying that there are many 
changes in Python 2.2 that will blow up code written in 
Python 2.1!? Why do we have __future__ than!? Why are we
concerned about being careful with division upgrade when
we have lots of small stuff breaking up *valid* code
written one release ago? And, if this was not enough, 
these changes won't even be documented!?!



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-30 12:21

Message:
Logged In: YES 
user_id=21627

Well, I wouldn't object to anybody documenting this
particular change (even though I won't do that myself, either).

I'm just pointing out that there are many more changes of
this kind, and that it would be an illusion that you could
ever produce a complete list.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-11-30 09:36

Message:
Logged In: YES 
user_id=38388

I disagree: any change which could potentially blow up existing programs should at least be mentioned somewhere 
in the docs, be it the NEWS file, the release page on python.org or (thanks to the great work of Andrew Kuchling) 
the "What's new in Python x.x" docs.

This is simply needed due to the very dynamic way Python works: there's no way to test all paths through a 
program if you want to port it from one Python version to the next, so we'll have to be very careful about these 
changes even if they are clearly bug fixes.

In the mentioned case, I'd say that the programmer was at fault, though: it's so much easier to test a path for being 
a directory than to rely on some obscure method return value and also much safer !

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-30 09:19

Message:
Logged In: YES 
user_id=21627

Any change is user-visible: for any change, I can construct
a program that behaves differently with the change.
Otherwise, the change would be useless (except that it may
add commentary or some such).

In fact, the change *is* documented, namely in the CVS log.
Extracting all those fragments into a single document would
be  time-consuming and pointless: nobody can read through
hundreds of changes.

Your program would have blown up even if there was such a
document. If a change has severe effects on many existing
programs, it should be implemented differently.

----------------------------------------------------------------------

Comment By: Gustavo Niemeyer (niemeyer)
Date: 2001-11-30 00:10

Message:
Logged In: YES 
user_id=7887

I think *any* change visible at user space should be 
documented. I discovered this change because a program I 
have never read in my life (in fact, I didn't even know it
was written in python) has blown up in my hands. It was
reading files and safely ignoring directories by testing
readline()'s output.



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-29 23:53

Message:
Logged In: YES 
user_id=21627

I don't think this needs to be documented. The change is a
bug fix, reading from a directory was never supposed to work
(whether in lines or not).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=487277&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:44:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:44:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-499708 ] Int(long) causes Integer Overflow
Message-ID: <E16oVtw-0000oP-00@usw-sf-web4.sourceforge.net>

Bugs item #499708, was opened at 2002-01-05 03:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Later
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Int(long) causes Integer Overflow

Initial Comment:
In the spirit of unifying longs and ints,
should int() be the sole way of truncating
floats or should the programmer be responsible
for categorizing and handling ints and longs
separately?

>>> int( 12341234123.4 )
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
OverflowError: float too large to convert
>>> def myint(f):
... 	try:
... 		return int(f)
... 	except OverflowError:
... 		return long(f)
... 	
>>> myint( 12341234123.4 )
12341234123L
>>> myint(123.4)
123

I have one misgiving about fixing this one.
assert type(int(x)) == int, 'should always succeed'
would fail for when x=12341234123.4
The only way around this is to make longs return
a IntType.  Who knows what this would break.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:44

Message:
Logged In: YES 
user_id=35752

Closing and setting resolution to "Later" as suggested.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-05 11:42

Message:
Logged In: YES 
user_id=21627

See PEP 237. Python 2.2 finished phase A, where only
operations are changed. Phase B.1 will address further
semantic differences, such as the builtin int function
(which will issue a warning if it returns a long where it
previously behaved differently). So I'd conclude that, for
Python 2.2, the behaviour you see is by design, and that
this report should be closed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=499708&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:52:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:52:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-500705 ] os.listdir("") bug on Windows
Message-ID: <E16oW1h-0000PE-00@usw-sf-web2.sourceforge.net>

Bugs item #500705, was opened at 2002-01-08 03:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500705&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neil Hodgson (nyamatongwe)
Assigned to: Nobody/Anonymous (nobody)
>Summary: os.listdir("") bug on Windows

Initial Comment:
   There is an out-of-bounds error on Windows when 
using os.listdir("") which could result in 
indeterminate behaviour. After parsing the args, it
does
 ch = namebuf[len-1];
   which indexes before the array as len = 0.
   Possibly change this to
 ch = (len > 0) ? namebuf[len-1] : '\0';


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:52

Message:
Logged In: YES 
user_id=35752

Fixed in posixmodule.c 2.226.  Untested but I'm sure
Tim will scream if the Windows build breaks.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=500705&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 20:55:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 12:55:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16oW4t-0000wU-00@usw-sf-web4.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

Category: Installation
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. Löwis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 15:55

Message:
Logged In: YES 
user_id=6380

Then at least let's remember to fix this in 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:02

Message:
Logged In: YES 
user_id=31435

Yes, the installer hasn't changed, and won't for 2.2.1 
unless somebody other than me can make time to do it.  That 
seems unlikely to the point of fantasy, alas.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

----------------------------------------------------------------------

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 21:13:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 13:13:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oWLr-0000dS-00@usw-sf-web2.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 21:22:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 13:22:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oWUb-0001Ey-00@usw-sf-web4.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 21:34:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 13:34:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oWft-0006N2-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 21:34

Message:
Logged In: YES 
user_id=911

Replying to a few comments at once...  The C compiler
on AIX comes in many guises.  They are normally all
hard links to the same executable.  /etc/xlc.cfg
defines these identities, so cc_r, if it exists, just
causes a certain set of options to be used.

* extended c compiler aliased as cc_r
cc_r: use        = DEFLT
    crt        = /lib/crt0_r.o
    mcrt       = /lib/mcrt0.o
    gcrt       = /lib/gcrt0.o
    libraries  = -L/usr/lib/dce,-lc_r,-lpthreads
    proflibs   = -L/lib/profiled,-L/usr/lib/profiled
    options    = -H512,-T512,-qlanglvl=extended,
        -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_,
        -qnoroconst

So
http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html
is wrong when it says that you can't use cc with an
appropriate set of options since that's all that cc_r,
cckern, c89, xlc_r, or any of the other hard links
are.

However, not all AIX installations have all bits of
the C compiler available to support all its guises.
So I think it's preferable to use cc_r if it is
available, else fall-back on cc.  And if using cc
hopefully configure's testing for whether threads is
available will determine it isn't.

This is all based on AIX 3, AIX 4 expanded on this in
a few ways.

In summary, I'd agree with donnc `Without cc_r, just
don't enable threads'.  Hopefully, that'll happen
automatically.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 18:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 21:39:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 13:39:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oWkm-0006kV-00@usw-sf-web3.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39

Message:
Logged In: YES 
user_id=6380

Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.

The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.

But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 21:59:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 13:59:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oX4A-0001g1-00@usw-sf-web4.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:59

Message:
Logged In: YES 
user_id=31435

Na, you should read me as saying I don't know how to write 
the kinds of docs you want.  I didn't do the parser changes 
here, so if you think there's something predictable and 
useful to be said here, you're the one to say it.

Keeping at least one example around under an "#if 0" sounds 
like an excellent idea.  The last time I implemented a 
future gimmick, it was spread around in so many places that 
the only sane way to proceed was to search for "the other" 
future gimmick that happened to be implemented already.

But doing that kind of search again is the only sane way I 
know to get rid of the future-generator business now too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39

Message:
Logged In: YES 
user_id=6380

Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.

The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.

But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:07:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:07:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oXCD-00074p-00@usw-sf-web3.sourceforge.net>

Bugs item #501622, was opened at 2002-01-10 04:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:07:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:07:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oXCQ-00075B-00@usw-sf-web3.sourceforge.net>

Bugs item #501622, was opened at 2002-01-10 04:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:18:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:18:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-504723 ] Bad exceptions from pickle
Message-ID: <E16oXMU-0001tC-00@usw-sf-web4.sourceforge.net>

Bugs item #504723, was opened at 2002-01-17 03:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Bob Alexander (bobalex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bad exceptions from pickle

Initial Comment:
Here is an annotated session that shows some incorrect
exceptions raised with bad input. I'm assuming that it
is intended that when attempting to load a pickle file,
we should only have to check for UnpicklingError, not
for several other possible exceptions.

>>> import sys
>>> sys.version
'2.2 (#1, Dec 26 2001, 16:14:13) \n[GCC 2.96 20000731
(Mandrake Linux 8.1 2.96-0.62mdk)]'


Problem 1: Attempting to load an empty file produces an
EOFError exception, but should probably produce an
UnpicklingError exception. This happens with both
pickle and cPickle.

>>> import cPickle as pickle
>>> import pickle as pk

>>> f=open("/dev/null")     # Empty file
>>> ff=StringIO("asdfasdfasdfasdfasdfasdf")   # Garbage
file

>>> pickle.load(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
EOFError

>>> pk.load(f)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/pickle.py", line 977, in
load
    return Unpickler(file).load()
  File "/usr/lib/python2.2/pickle.py", line 592, in
load
    dispatch[key](self)
  File "/usr/lib/python2.2/pickle.py", line 606, in
load_eof
    raise EOFError
EOFError


Problem 2: With cPickle, loading a garbage file
produced and IndexError, not an Unpickling error.

>>> pk.load(ff)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/pickle.py", line 977, in
load
    return Unpickler(file).load()
  File "/usr/lib/python2.2/pickle.py", line 592, in
load
    dispatch[key](self)
  File "/usr/lib/python2.2/pickle.py", line 746, in
load_dict
    k = self.marker()
  File "/usr/lib/python2.2/pickle.py", line 600, in
marker
    while stack[k] is not mark: k = k-1
IndexError: list index out of range


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=35752

I added IndexError and EOFError to the list of example
exceptions that unpickle can raise.  Closing this bug.

----------------------------------------------------------------------

Comment By: Thomas W. Christopger (tchristopher)
Date: 2002-02-26 15:59

Message:
Logged In: YES 
user_id=64169

Actually, I want EOFError on the file-like object 
returning ''; the empty string IS an end of file 
indication. That's what I'm looking for when there are a 
varying number of objects, and yes, I use it a lot.

So please DO NOT make end of file return an UnpicklingError.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-17 07:41

Message:
Logged In: YES 
user_id=21627

The documentation of UnpicklingError says

Note that other exceptions may also be raised during
unpickling, including (but not necessarily limited to)
\exception{AttributeError} and \exception{ImportError}.

So I'm not so sure that there is a bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504723&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:18:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:18:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-495978 ] It's the future for generators
Message-ID: <E16oXMf-0001NB-00@usw-sf-web2.sourceforge.net>

Bugs item #495978, was opened at 2001-12-21 17:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: It's the future for generators

Initial Comment:
"from __future__ import generators" should no longer 
be required in 2.3a1.  Such stmts should also be 
removed from the Python library (there's a script 
under Tools to automate this).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:18

Message:
Logged In: YES 
user_id=6380

It's not too late!  Neil hasn't checked it in yet.

Neil, would you be willing to change your patch so that it
disables the yield keyword using #ifdef rather than by
erasing all of the code?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:59

Message:
Logged In: YES 
user_id=31435

Na, you should read me as saying I don't know how to write 
the kinds of docs you want.  I didn't do the parser changes 
here, so if you think there's something predictable and 
useful to be said here, you're the one to say it.

Keeping at least one example around under an "#if 0" sounds 
like an excellent idea.  The last time I implemented a 
future gimmick, it was spread around in so many places that 
the only sane way to proceed was to search for "the other" 
future gimmick that happened to be implemented already.

But doing that kind of search again is the only sane way I 
know to get rid of the future-generator business now too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:39

Message:
Logged In: YES 
user_id=6380

Actually, each time a future feature introduces a new
keyword that has to remain an identifier when the feature is
not enabled, almost *exactly* the same hacks have to be
applied to the parser. That's just how the parser works. I
would almost recommend keeping those changes around at all
times, just #ifdef'ed out or something.

The other stuff that feels like it's very similar each time
is the handling of the flags passed around between the
various passes of the code generator.

But I know it's hopeless to argue with you, so I'll let you
rediscover all that when you decide to finally implement the
braces feature. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 16:22

Message:
Logged In: YES 
user_id=31435

The internal future machinery has changed every time we've 
added a new future gimmick.  So there's really nothing to 
be said other than to scour the source code looking for now-
obsolete "stuff".  For example, it's possible that the 
kinds of parser changes made for "yield" will never happen 
again, and, even if they do, I think it's impossible to 
predict where and how the parser will need to be unchanged.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 16:13

Message:
Logged In: YES 
user_id=6380

There ought to be documentation on what to do when an
optional feature becomes mandatory. Maybe a block comment or
docstring in __future__.py?


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 15:34

Message:
Logged In: YES 
user_id=31435

Neil, if you don't enjoy using the patch system for 
straightforward stuff like this, don't feel compelled to 
use it.  That is, just check it in.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 15:04

Message:
Logged In: YES 
user_id=35752

The attached patch removes the "yield is an optional keyword"
hacks from the parser.  It's not a complete fix for this
bug though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495978&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:20:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:20:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oXOj-0006uG-00@usw-sf-web1.sourceforge.net>

Bugs item #501622, was opened at 2002-01-09 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:27:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:27:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-505028 ] Super method search quirk
Message-ID: <E16oXVR-0007Io-00@usw-sf-web3.sourceforge.net>

Bugs item #505028, was opened at 2002-01-17 19:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Super method search quirk

Initial Comment:
I think the following qualifies as a bug; I think the 
call to super(C, self).m() should cause an exception 
(the super_getattro search should not find the m in A 
if an m is defined in B):

>>> class A(object):
...     def m(self):
...         print 'A'
...
>>> class B(A):
...     m = property(lambda self: 'B')
...
>>> class C(B):
...     def m(self):
...         super(C, self).m()
...         print 'C'
...
>>> c = C()
>>> c.meth()
A
C



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:27

Message:
Logged In: YES 
user_id=35752

I agree.  This looks like a bug with super().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:34:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:34:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-505028 ] Super method search quirk
Message-ID: <E16oXc9-00074h-00@usw-sf-web1.sourceforge.net>

Bugs item #505028, was opened at 2002-01-17 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Super method search quirk

Initial Comment:
I think the following qualifies as a bug; I think the 
call to super(C, self).m() should cause an exception 
(the super_getattro search should not find the m in A 
if an m is defined in B):

>>> class A(object):
...     def m(self):
...         print 'A'
...
>>> class B(A):
...     m = property(lambda self: 'B')
...
>>> class C(B):
...     def m(self):
...         super(C, self).m()
...         print 'C'
...
>>> c = C()
>>> c.meth()
A
C



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:34

Message:
Logged In: YES 
user_id=6380

It would seem a bug, but according to the CVS log it's
intentional. typeobject.c 2.120 introduces an explicit check
that skips data descriptors (such as properties). The
motivation:

- super(C, C()).__class__ would return the __class__
attribute of C()
  rather than the __class__ attribute of the super object. 
This is
  confusing.  To fix this, I decided to change the semantics
of super
  so that it only applies to code attributes, not to data
attributes.
  After all, overriding data attributes is not supported
anyway.

So I think this is a feature after all.


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:27

Message:
Logged In: YES 
user_id=35752

I agree.  This looks like a bug with super().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:35:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:35:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-510910 ] File inheritance across exec/spawn
Message-ID: <E16oXd5-0007PG-00@usw-sf-web3.sourceforge.net>

Bugs item #510910, was opened at 2002-01-30 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: File inheritance across exec/spawn

Initial Comment:
For 2.3, I added a new tempfile.TemporaryFile 
implementation for Windows that (among other good 
things) arranges that spawned processes will no longer 
inherit the temp files' underlying open file 
descriptors.  There are multiple reasons for doing so 
on Windows, and one that's "an issue" across all 
platforms is security.

Temp files may (will, AFAICT) still get inherited on 
other platforms.  And inheriting open files of other 
kinds may still be an issue on all platforms.

Guido sez (from email):

"""
This is exactly what happens on Unix, I'm afraid.  Is
there a way around that?  Across fork(), I think it's 
fair (might be intentional).  Across exec(), I think 
there's no point.  We should use fcntl() with F_SETFD 
to set the FD_CLOEXEC bit.
"""

There is no fork on Windows, so life is simpler there; 
OTOH, there's no FD_CLOEXEC bit on Windows either, so 
life is harder there if we want to extend this to 
other files.  I'm inclined to think we should stick to 
setting policy only for temp files;  *we* create them, 
and the user has no control over how we create them.  
For files the user opens themself, they can get at 
FD_CLOEXEC (on platforms supporting it) from Python.  
They can also get at O_NOINHERIT on Windows in 2.3 
(when using os.open()).

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:35

Message:
Logged In: YES 
user_id=35752

What's the bug here?  I'm guessing that Guido is suggesting
that TemporaryFile set the FD_CLOEXEC.  Is that right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:41:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:41:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oXia-0001ef-00@usw-sf-web2.sourceforge.net>

Bugs item #501622, was opened at 2002-01-09 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:44:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:44:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-522699 ] Segfault evaluating '%.100f' % 2.0**100
Message-ID: <E16oXlW-0002E9-00@usw-sf-web4.sourceforge.net>

Bugs item #522699, was opened at 2002-02-25 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522699&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Erwin S. Andreasen (drylock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault evaluating '%.100f' % 2.0**100

Initial Comment:
Evaluating this code:

'%.100f' % 2.0**100

will crash python2.1.2. gdb on the core file shows

#0  0x30303030 in ?? ()
Error accessing memory address 0x30303030: No such process.

which suggests overflow of some stack variable (0x30 is ASCII character '0')

The same problem also happens on Python 2.0

The problem does NOT occur on Python 2.2 nor 1.5


Program versions used:
Python 2.0b1 (#18, Sep 23 2001, 21:06:34) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2

Python 2.1.2 (#1, Jan 18 2002, 18:05:45) 
[GCC 2.95.4  (Debian prerelease)] on linux2

Python 2.2 (#1, Jan  8 2002, 01:13:32) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2

Python 1.5.2 (#0, Dec 27 2000, 13:59:38)  
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:44

Message:
Logged In: YES 
user_id=35752

This has already been fixed.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-02-25 23:52

Message:
Logged In: YES 
user_id=35752

I think this was fixed in floatobject.c 2.108.  The patch is
attached if anyone wants to backport it.  2.1 doesn't seem
to have snprintf though so the port could be tricky.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522699&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:46:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:46:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oXny-0001is-00@usw-sf-web2.sourceforge.net>

Bugs item #501622, was opened at 2002-01-09 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:46

Message:
Logged In: YES 
user_id=6380

Probably, unless the start symbol is "expr" (which doesn't
need a newline).

But it would mean copying a potentially huge string -- we
can't append the \n in place.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:49:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:49:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-510910 ] File inheritance across exec/spawn
Message-ID: <E16oXrA-0002Hj-00@usw-sf-web4.sourceforge.net>

Bugs item #510910, was opened at 2002-01-30 16:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: File inheritance across exec/spawn

Initial Comment:
For 2.3, I added a new tempfile.TemporaryFile 
implementation for Windows that (among other good 
things) arranges that spawned processes will no longer 
inherit the temp files' underlying open file 
descriptors.  There are multiple reasons for doing so 
on Windows, and one that's "an issue" across all 
platforms is security.

Temp files may (will, AFAICT) still get inherited on 
other platforms.  And inheriting open files of other 
kinds may still be an issue on all platforms.

Guido sez (from email):

"""
This is exactly what happens on Unix, I'm afraid.  Is
there a way around that?  Across fork(), I think it's 
fair (might be intentional).  Across exec(), I think 
there's no point.  We should use fcntl() with F_SETFD 
to set the FD_CLOEXEC bit.
"""

There is no fork on Windows, so life is simpler there; 
OTOH, there's no FD_CLOEXEC bit on Windows either, so 
life is harder there if we want to extend this to 
other files.  I'm inclined to think we should stick to 
setting policy only for temp files;  *we* create them, 
and the user has no control over how we create them.  
For files the user opens themself, they can get at 
FD_CLOEXEC (on platforms supporting it) from Python.  
They can also get at O_NOINHERIT on Windows in 2.3 
(when using os.open()).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:49

Message:
Logged In: YES 
user_id=31435

I expect Guido is suggesting at least that, and since it's 
my bug report <wink> I'd be happy to close it if that much 
is done.  Security Geeks may or may not wish to argue that 
all files opened by Python do likewise, but, if so, they 
can open their bug report.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=35752

What's the bug here?  I'm guessing that Guido is suggesting
that TemporaryFile set the FD_CLOEXEC.  Is that right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 22:55:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 14:55:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-522699 ] Segfault evaluating '%.100f' % 2.0**100
Message-ID: <E16oXwq-0002MN-00@usw-sf-web4.sourceforge.net>

Bugs item #522699, was opened at 2002-02-25 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522699&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Erwin S. Andreasen (drylock)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segfault evaluating '%.100f' % 2.0**100

Initial Comment:
Evaluating this code:

'%.100f' % 2.0**100

will crash python2.1.2. gdb on the core file shows

#0  0x30303030 in ?? ()
Error accessing memory address 0x30303030: No such process.

which suggests overflow of some stack variable (0x30 is ASCII character '0')

The same problem also happens on Python 2.0

The problem does NOT occur on Python 2.2 nor 1.5


Program versions used:
Python 2.0b1 (#18, Sep 23 2001, 21:06:34) 
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2

Python 2.1.2 (#1, Jan 18 2002, 18:05:45) 
[GCC 2.95.4  (Debian prerelease)] on linux2

Python 2.2 (#1, Jan  8 2002, 01:13:32) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2

Python 1.5.2 (#0, Dec 27 2000, 13:59:38)  
[GCC 2.95.2 20000220 (Debian GNU/Linux)] on linux2



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:55

Message:
Logged In: YES 
user_id=31435

Note that formatfloat's "worst case length" calculation is 
plain wrong in this case.  I happened to open a bug report 
about that a day or two ago.  This shouldn't rely on 
snprintf to avoid blowing up, but it so happens that it 
does now.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:44

Message:
Logged In: YES 
user_id=35752

This has already been fixed.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-02-25 18:52

Message:
Logged In: YES 
user_id=35752

I think this was fixed in floatobject.c 2.108.  The patch is
attached if anyone wants to backport it.  2.1 doesn't seem
to have snprintf though so the port could be tricky.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522699&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 23:01:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 15:01:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oY28-0001tf-00@usw-sf-web2.sourceforge.net>

Bugs item #501622, was opened at 2002-01-09 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 18:01

Message:
Logged In: YES 
user_id=31435

Well, the user can't append an '\n' inplace either.  The 
question is whether we do that for them, or let it blow 
up.  OTOH, codeop.py has a lot of fun <wink> now trying to 
compile as-is, tben with one '\n' tacked on, then with two 
of 'em.  It would take me a long time to figure out exactly 
why it's doing all that, and to guess exactly how it would 
break.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:46

Message:
Logged In: YES 
user_id=6380

Probably, unless the start symbol is "expr" (which doesn't
need a newline).

But it would mean copying a potentially huge string -- we
can't append the \n in place.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 23:03:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 15:03:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-523020 ] pickle/cPickle Inconsistent EOF handling
Message-ID: <E16oY4I-0007PY-00@usw-sf-web1.sourceforge.net>

Bugs item #523020, was opened at 2002-02-26 16:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523020&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Thomas W. Christopger (tchristopher)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle/cPickle Inconsistent EOF handling

Initial Comment:
cPickle.Unpickler(f).load() and cPickle.load() do not 
handle EOF the way pickle.Unpickler(f).load(f), 
cPickle.loads(s) and pickle.loads(s) do. The first two 
give
  cPickle.UnpicklingError: invalid load key, ' '.
on EOF. The actual message text is 
"invalid load key, '\000'."
The remaining give
  EOFError

(The EOFError from all of them is what I need.)

Observe:

>>> pickle.loads('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python22\lib\pickle.py", line 981, in loads
    return Unpickler(file).load()
  File "C:\Python22\lib\pickle.py", line 592, in load
    dispatch[key](self)
  File "C:\Python22\lib\pickle.py", line 606, in 
load_eof
    raise EOFError
EOFError
>>> cPickle.loads('')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
EOFError

>>> class C:
...     def read(self,n): return ''
...     def readline(self): return ''
...
>>> p=pickle.Unpickler(C())
>>> p.load()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python22\lib\pickle.py", line 592, in load
    dispatch[key](self)
  File "C:\Python22\lib\pickle.py", line 606, in 
load_eof
    raise EOFError
EOFError
>>> pickle.load(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python22\lib\pickle.py", line 977, in load
    return Unpickler(file).load()
  File "C:\Python22\lib\pickle.py", line 592, in load
    dispatch[key](self)
  File "C:\Python22\lib\pickle.py", line 606, in 
load_eof
    raise EOFError
EOFError

>>> p=cPickle.Unpickler(C())
>>> p.load()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, ' '.
>>> cPickle.load(C())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
cPickle.UnpicklingError: invalid load key, ' '.



----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 23:03

Message:
Logged In: YES 
user_id=35752

Fixed in cPickle.c 2.75.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523020&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 23:06:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 15:06:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oY79-0007lm-00@usw-sf-web3.sourceforge.net>

Bugs item #501622, was opened at 2002-01-10 04:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Nobody/Anonymous (nobody)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: David Bolen (db3l)
Date: 2002-03-22 23:06

Message:
Logged In: YES 
user_id=53196

If compile() is being used in exec mode with a non-
terminated multi-line string, it's not going to work unless 
the application generates that copy itself in any event.  
So without an interpreter fix, I'd think the string copy is 
inevitable, and it might simplify things to have the 
builtin function take care of it.  It's something easy to 
overlook at the application level and could thus be fixed 
in one place rather than at each point of use.

On the other hand, I also noticed something I overlooked 
when first encountering the problem - the 2.2 docs added 
some text to compile() talking about this need for 
termination.  So it could be argued that it's now a 
documented restriction, and should the newline append (with 
any requisite string duplication) be needed, it leaves it 
to the individual applications rather than forcing it in 
the builtin.

Not to mention a documentation solution could thus be 
declared already done.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 23:01

Message:
Logged In: YES 
user_id=31435

Well, the user can't append an '\n' inplace either.  The 
question is whether we do that for them, or let it blow 
up.  OTOH, codeop.py has a lot of fun <wink> now trying to 
compile as-is, tben with one '\n' tacked on, then with two 
of 'em.  It would take me a long time to figure out exactly 
why it's doing all that, and to guess exactly how it would 
break.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:46

Message:
Logged In: YES 
user_id=6380

Probably, unless the start symbol is "expr" (which doesn't
need a newline).

But it would mean copying a potentially huge string -- we
can't append the \n in place.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 23:14:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 15:14:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oYEX-0007rF-00@usw-sf-web3.sourceforge.net>

Bugs item #501622, was opened at 2002-01-10 04:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 23:14

Message:
Logged In: YES 
user_id=35752

I'm +1 on builtin_compile adding the newline.  It's the
lazy way out and it's better than every person hacking
with the parser stumbling into it and coming up with their
own work around.

Guido?

----------------------------------------------------------------------

Comment By: David Bolen (db3l)
Date: 2002-03-22 23:06

Message:
Logged In: YES 
user_id=53196

If compile() is being used in exec mode with a non-
terminated multi-line string, it's not going to work unless 
the application generates that copy itself in any event.  
So without an interpreter fix, I'd think the string copy is 
inevitable, and it might simplify things to have the 
builtin function take care of it.  It's something easy to 
overlook at the application level and could thus be fixed 
in one place rather than at each point of use.

On the other hand, I also noticed something I overlooked 
when first encountering the problem - the 2.2 docs added 
some text to compile() talking about this need for 
termination.  So it could be argued that it's now a 
documented restriction, and should the newline append (with 
any requisite string duplication) be needed, it leaves it 
to the individual applications rather than forcing it in 
the builtin.

Not to mention a documentation solution could thus be 
declared already done.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 23:01

Message:
Logged In: YES 
user_id=31435

Well, the user can't append an '\n' inplace either.  The 
question is whether we do that for them, or let it blow 
up.  OTOH, codeop.py has a lot of fun <wink> now trying to 
compile as-is, tben with one '\n' tacked on, then with two 
of 'em.  It would take me a long time to figure out exactly 
why it's doing all that, and to guess exactly how it would 
break.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:46

Message:
Logged In: YES 
user_id=6380

Probably, unless the start symbol is "expr" (which doesn't
need a newline).

But it would mean copying a potentially huge string -- we
can't append the \n in place.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Fri Mar 22 23:16:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 15:16:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-510910 ] File inheritance across exec/spawn
Message-ID: <E16oYGR-0002an-00@usw-sf-web4.sourceforge.net>

Bugs item #510910, was opened at 2002-01-30 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Neil Schemenauer (nascheme)
Summary: File inheritance across exec/spawn

Initial Comment:
For 2.3, I added a new tempfile.TemporaryFile 
implementation for Windows that (among other good 
things) arranges that spawned processes will no longer 
inherit the temp files' underlying open file 
descriptors.  There are multiple reasons for doing so 
on Windows, and one that's "an issue" across all 
platforms is security.

Temp files may (will, AFAICT) still get inherited on 
other platforms.  And inheriting open files of other 
kinds may still be an issue on all platforms.

Guido sez (from email):

"""
This is exactly what happens on Unix, I'm afraid.  Is
there a way around that?  Across fork(), I think it's 
fair (might be intentional).  Across exec(), I think 
there's no point.  We should use fcntl() with F_SETFD 
to set the FD_CLOEXEC bit.
"""

There is no fork on Windows, so life is simpler there; 
OTOH, there's no FD_CLOEXEC bit on Windows either, so 
life is harder there if we want to extend this to 
other files.  I'm inclined to think we should stick to 
setting policy only for temp files;  *we* create them, 
and the user has no control over how we create them.  
For files the user opens themself, they can get at 
FD_CLOEXEC (on platforms supporting it) from Python.  
They can also get at O_NOINHERIT on Windows in 2.3 
(when using os.open()).

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 23:16

Message:
Logged In: YES 
user_id=35752

Okay.  I'll take it since I'm a wannabe security geek.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:49

Message:
Logged In: YES 
user_id=31435

I expect Guido is suggesting at least that, and since it's 
my bug report <wink> I'd be happy to close it if that much 
is done.  Security Geeks may or may not wish to argue that 
all files opened by Python do likewise, but, if so, they 
can open their bug report.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:35

Message:
Logged In: YES 
user_id=35752

What's the bug here?  I'm guessing that Guido is suggesting
that TemporaryFile set the FD_CLOEXEC.  Is that right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 00:01:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 16:01:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oYyF-00082T-00@usw-sf-web1.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

>Category: Python Library
Group: Python 2.2.1 candidate
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 00:01

Message:
Logged In: YES 
user_id=911

Although I agree passing a tuple stuff full of
co-incidental numbers isn't great, unfortunately, the
suggestion of (2001, 1, i+1, 12, 0, 0, i, i+1, 0) is
definitely wrong.

I think it should be (2001, item, 1, 12, 0, 0, item,
1, 0) and have attached calendar.patch which is
against latest CVS.

I'd guess that it was originally (item,) * 9 so
_localized_name could be used for anything.  It only
ended up being used for week and month names so item
should only appear twice in the tuple.

Also, Tim's suggestion made every month name the same,
e.g. `January'.  Plus it added one to item for the
month, yet the original just used plain item.

I've altered test_calendar.py to check that one week
day name doesn't match another, and the same for month
names.  But I've not written Python before so please
check carefully.

Lastly, _localized_name looks well dodgy to me.  It
only takes a len yet week day names are zero-based and
month names one-based!  Observe.

>>> ','.join(day_name[:])
'Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday'
>>> ','.join(day_abbr[:])
'Mon,Tue,Wed,Thu,Fri,Sat,Sun'

They seem fine.

>>> ','.join(month_name[:])
'Dec,January,February,March,April,May,June,July,August,
    September,October,November,December'
>>> ','.join(month_abbr[:])
'Saturday,Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec'

But accessing an invalid index 0 happens to give a
random string on this system, but could easily core
dump on another.

It seems _localized_name needs knowledge of the
minimum legal index too.  How well that maps onto the
Pythonic `negative index is relative to end' I don't
know.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 18:36

Message:
Logged In: YES 
user_id=44345

reclosing - thanks for the better fix (v. 1.26)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 18:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 18:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 16:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 15:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 12:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 00:35:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 16:35:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-501622 ] compile() 'exec' mode SyntaxError
Message-ID: <E16oZVL-0002uF-00@usw-sf-web2.sourceforge.net>

Bugs item #501622, was opened at 2002-01-09 23:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David Bolen (db3l)
Assigned to: Guido van Rossum (gvanrossum)
Summary: compile() 'exec' mode SyntaxError

Initial Comment:
If you have a module that you wish to compile using 
the builtin compile() function (in 'exec' mode), it 
will fail with a SyntaxError if that module does not 
have a newline as its final token.

The same module can be executed directly by the 
interpreter, or imported by another module, and Python 
can properly compile and save a pyc for the module.

I believe the difference is rooted in the fact that 
the tokenizer (tokenizer.c, in tok_nextc()) 
will "fake" a newline at the end of a file if it 
doesn't find one, but it will not do so when 
tokenizing a string buffer.

What I'm not certain of is whether faking such a token 
for strings as well won't break something else (such 
as when parsing a string for an expression rather than 
a full module).  But without such a change, you have a 
state where a module that works (and compiles) in 
other circumstances cannot be read into memory and 
compiled with the compile() builtin.

This came up while tracking down a problem with 
failures using Gordan McMillan's Installer package 
which compiles modules using compile() before 
including them in the archive.

I believe this is true for all releases since at least 
1.5.2.

-- David

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 19:35

Message:
Logged In: YES 
user_id=6380

Hm, adding it to builtin_compile isn't enough. We'd have to
add it to exec as well.

I think the lexer and/or parser should take care of this --
just as it should take care of accepting \r as well as \n as
well as \r\n.

Yes, it's hard to find. But there's got to be a way.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:14

Message:
Logged In: YES 
user_id=35752

I'm +1 on builtin_compile adding the newline.  It's the
lazy way out and it's better than every person hacking
with the parser stumbling into it and coming up with their
own work around.

Guido?

----------------------------------------------------------------------

Comment By: David Bolen (db3l)
Date: 2002-03-22 18:06

Message:
Logged In: YES 
user_id=53196

If compile() is being used in exec mode with a non-
terminated multi-line string, it's not going to work unless 
the application generates that copy itself in any event.  
So without an interpreter fix, I'd think the string copy is 
inevitable, and it might simplify things to have the 
builtin function take care of it.  It's something easy to 
overlook at the application level and could thus be fixed 
in one place rather than at each point of use.

On the other hand, I also noticed something I overlooked 
when first encountering the problem - the 2.2 docs added 
some text to compile() talking about this need for 
termination.  So it could be argued that it's now a 
documented restriction, and should the newline append (with 
any requisite string duplication) be needed, it leaves it 
to the individual applications rather than forcing it in 
the builtin.

Not to mention a documentation solution could thus be 
declared already done.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 18:01

Message:
Logged In: YES 
user_id=31435

Well, the user can't append an '\n' inplace either.  The 
question is whether we do that for them, or let it blow 
up.  OTOH, codeop.py has a lot of fun <wink> now trying to 
compile as-is, tben with one '\n' tacked on, then with two 
of 'em.  It would take me a long time to figure out exactly 
why it's doing all that, and to guess exactly how it would 
break.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:46

Message:
Logged In: YES 
user_id=6380

Probably, unless the start symbol is "expr" (which doesn't
need a newline).

But it would mean copying a potentially huge string -- we
can't append the \n in place.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:41

Message:
Logged In: YES 
user_id=31435

Would it make sense for builtin_compile() to append a 
newline itself (say, if one weren't already present)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:20

Message:
Logged In: YES 
user_id=6380

> the tok_nextc code is hairy and whatever
> I tried broke something else.

That's exactly what happened to me when I tried to fix this
myself long ago. :-(

The workaround is simple enough: whoever calls compile()
should append a newline to the string just to be sure.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:07

Message:
Logged In: YES 
user_id=35752

I ran into this bug myself when writing the PTL compiler.
Here's a test case:

code = "def foo():\n  pass"
open("bug.py", "w").write(code)
import bug # works
compile(code, "<string>", "exec") # doesn't work

I traced this bug to tok_nextc.  If the input is coming from
a file and the last bit of input doesn't end with a newline
then one is faked.  This doesn't happen if the input is
coming from a string.  I spent time trying to figure out
how to fix it but the tok_nextc code is hairy and whatever
I tried broke something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501622&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 00:43:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 16:43:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16oZce-0003VR-00@usw-sf-web4.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 00:43

Message:
Logged In: YES 
user_id=911

BTW, the build then halts because 1.295 of configure.in
isn't in the release candidate so LINKCC's definition
in Makefile contains LINKCC and the recursion isn't welcome.
SF bug #477487 apparently.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 21:34

Message:
Logged In: YES 
user_id=911

Replying to a few comments at once...  The C compiler
on AIX comes in many guises.  They are normally all
hard links to the same executable.  /etc/xlc.cfg
defines these identities, so cc_r, if it exists, just
causes a certain set of options to be used.

* extended c compiler aliased as cc_r
cc_r: use        = DEFLT
    crt        = /lib/crt0_r.o
    mcrt       = /lib/mcrt0.o
    gcrt       = /lib/gcrt0.o
    libraries  = -L/usr/lib/dce,-lc_r,-lpthreads
    proflibs   = -L/lib/profiled,-L/usr/lib/profiled
    options    = -H512,-T512,-qlanglvl=extended,
        -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_,
        -qnoroconst

So
http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html
is wrong when it says that you can't use cc with an
appropriate set of options since that's all that cc_r,
cckern, c89, xlc_r, or any of the other hard links
are.

However, not all AIX installations have all bits of
the C compiler available to support all its guises.
So I think it's preferable to use cc_r if it is
available, else fall-back on cc.  And if using cc
hopefully configure's testing for whether threads is
available will determine it isn't.

This is all based on AIX 3, AIX 4 expanded on this in
a few ways.

In summary, I'd agree with donnc `Without cc_r, just
don't enable threads'.  Hopefully, that'll happen
automatically.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 18:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 01:52:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 17:52:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-410878 ] Distutils should have a Setup parser
Message-ID: <E16oahd-00013A-00@usw-sf-web3.sourceforge.net>

Bugs item #410878, was opened at 2001-03-23 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470

Category: Distutils
Group: Feature Request
>Status: Closed
>Resolution: Rejected
Priority: 1
Submitted By: A.M. Kuchling (akuchling)
Assigned to: A.M. Kuchling (akuchling)
Summary: Distutils should have a Setup parser

Initial Comment:
Setup files are handy for allowing user overrides.
I do a minimal parse in Python 2.1's setup.py, and Pete
Shinners wrote a more complete one for pygame's
config.py.  Support for
parsing Setup files should be added to the Distutils
API, so packagers can easily make overrides for 
C extension compile flags.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-22 20:52

Message:
Logged In: YES 
user_id=11375

Closing this bug.  extension.py has a parser of sorts, and 
we probably don't care if it's not accessible from other 
modules very easily.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-10 11:21

Message:
Logged In: YES 
user_id=6380

ROTFL.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-12-10 11:16

Message:
Logged In: YES 
user_id=11375

Because I thought priority 9 was lowest priority, not 
highest, of course!



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-10 10:53

Message:
Logged In: YES 
user_id=6380

Andrew, what's the point of setting the priority to 9 if it
won't get done before 2.2?

We can't release with outstanding bugs of priority 7 or
higher, but we're just going to lower the priority of this
item...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410878&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 02:08:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 18:08:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-526357 ] cmd.py does not flush stdout
Message-ID: <E16oaxe-0001Dj-00@usw-sf-web3.sourceforge.net>

Bugs item #526357, was opened at 2002-03-06 12:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526357&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
>Assigned to: Neil Schemenauer (nascheme)
Summary: cmd.py does not flush stdout

Initial Comment:
The module cmd (located in cmd.py in the library) does not flush stdout 
before it waits for input.

What does that mean? That means that unless you are running cmd 
from the terminal, or unless stdout happens to magically flush before it 
waits for new input, that there will be no data written to stdout before it 
waits for input.

This is a problem if you want to fork() a module that uses cmd, or set it 
up to work with sockets as stdout and stdin.

When running in no_rawinput=1 mode (should that be renamed to 
no_raw_input?) , it executes the following code:

79                    sys.stdout.write(self.prompt)
80                    line = sys.stdin.readline()

It should read:

79                    sys.stdout.write(self.prompt)
80                    sys.stdout.flush()
81                    line = sys.stdin.readline(79

There may also be a problem with raw_input(). raw_input should flush 
stdout before asking for input. I'll submit a seperate bug report for that.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 13:49

Message:
Logged In: YES 
user_id=6380

Might it have occurred to you that you're the first person
ever who's using cmd in a situation where it's not talking
directly to a real human user? I agree that this should
probably be fixed, but it's got low priority compared to
many other bugs.

PS. The convention is that if you have a fix for a bug, you
submit a patch, not a bug report. And please use context
diffs in attachments, never out the patch in the initial bug
description.

----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 12:51

Message:
Logged In: YES 
user_id=126343

no_rawinput should be use_rawinput.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526357&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 02:41:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 18:41:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16obTR-0001Bt-00@usw-sf-web1.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 21:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 02:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 12:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 12:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:18:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:18:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16oc2x-00050G-00@usw-sf-web4.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

>Category: Documentation
>Group: Python 2.3
Status: Open
Resolution: None
>Priority: 1
Submitted By: Arthur Siegel (aj_siegel)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=6380

It seems that * is the exception -- all other operators (+,
-, /, **) return the type of the left operand.  It gets even
weirder if we change the left operand from 7 to 7.0 -- then
* is no longer an exception and returns a complex like all
other operators!

The weirdness is in int_mul. If the right argument is not an
int but a sequence that implements the sq_repeat slot, it
invokes that. But if you create a class that defines
__mul__, that implements the sequence repeat slot! (Python
doesn't know if you intend to implement a seqence or a
number, when you define a __mul__ method, so it maps both
the nb_multiply and the sq_repeat slots to the __mul__
method).

So 7 + Complex() takes the path through int_mul that calls
the Complex.__mul__ , and that's why you get a Complex value
back. Floats can't be used in the sequence repeat operator,
so its multiply is "normal".

But wait...! There's another mystery. Ints don't know how to
add themselves to complex numbers! So why wouldn't
7+Complex() use the normal pattern of (a) try the left
operand, (b) if that returns NotImplemented, try the right
operand? The answer is that complex numbers implement
coercion! And in that case, step (b) is modified to (b) ask
either operand to perform a coercion, and if it succeeds,
ask the left operand of the resulting coerced pair to
perform the operation. So complex coerces the int to a plain
complex, and then invokes the plain complex's add/mul/etc.
operation.

Solution: add the following to your Complex class:

    def __coerce__(self, other):
        x = complex.__coerce__(self, other)
        if x is NotImplemented:
            return x
        a, b = x
        return Complex(a), Complex(b)

I don't think I want to do anything to fix this, although I
think I'll pass it on to Fred for documentation (not that I
expect him to be in a hurry to fix it either, given the
subtlety of the issues).

In the long run, I think complex should stop using coercion
and start behaving like a "new-style" number like all the
other numeric types. That should fix the second mystery.

Also, in the long run, the sq_repeat and sq_concat slots
should be deprecated and instead sequences should implement
multiply and add operations. Then the funny business in
int_mul could be taken out and the first mystery would
disappear.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:27:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:27:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16ocBt-0004fO-00@usw-sf-web2.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 13:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:27

Message:
Logged In: YES 
user_id=31435

Fixed again, by being duller instead of cleverer, in

Lib/calendar.py; new revision: 1.27
Lib/test/test_calendar.py; new revision: 1.3

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 19:01

Message:
Logged In: YES 
user_id=911

Although I agree passing a tuple stuff full of
co-incidental numbers isn't great, unfortunately, the
suggestion of (2001, 1, i+1, 12, 0, 0, i, i+1, 0) is
definitely wrong.

I think it should be (2001, item, 1, 12, 0, 0, item,
1, 0) and have attached calendar.patch which is
against latest CVS.

I'd guess that it was originally (item,) * 9 so
_localized_name could be used for anything.  It only
ended up being used for week and month names so item
should only appear twice in the tuple.

Also, Tim's suggestion made every month name the same,
e.g. `January'.  Plus it added one to item for the
month, yet the original just used plain item.

I've altered test_calendar.py to check that one week
day name doesn't match another, and the same for month
names.  But I've not written Python before so please
check carefully.

Lastly, _localized_name looks well dodgy to me.  It
only takes a len yet week day names are zero-based and
month names one-based!  Observe.

>>> ','.join(day_name[:])
'Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday'
>>> ','.join(day_abbr[:])
'Mon,Tue,Wed,Thu,Fri,Sat,Sun'

They seem fine.

>>> ','.join(month_name[:])
'Dec,January,February,March,April,May,June,July,August,
    September,October,November,December'
>>> ','.join(month_abbr[:])
'Saturday,Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec'

But accessing an invalid index 0 happens to give a
random string on this system, but could easily core
dump on another.

It seems _localized_name needs knowledge of the
minimum legal index too.  How well that maps onto the
Pythonic `negative index is relative to end' I don't
know.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 13:36

Message:
Logged In: YES 
user_id=44345

reclosing - thanks for the better fix (v. 1.26)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 13:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 13:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 10:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 07:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 13:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:33:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:33:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-503837 ] type.__module__ problems (again?)
Message-ID: <E16ocHi-00059F-00@usw-sf-web4.sourceforge.net>

Bugs item #503837, was opened at 2002-01-15 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Roeland Rengelink (rengelink)
Assigned to: Guido van Rossum (gvanrossum)
Summary: type.__module__ problems (again?)

Initial Comment:
Gelukkig nieuwjaar,

This is probably related to previous bug reports on
type.__module__.

Given

--- A.py ---
class meta1(type):
    def __new__(tp, name, bases, attr):
        return type.__new__(tp, name, bases, attr)

class meta2(type):
    pass

--- B.py ---
import A
class B1(object):
    __metaclass__ = A.meta1

class B2(object):
    __metaclass__ = A.meta2

------------

I get the following session.

Python 2.2 (#4, Jan  7 2002, 11:59:25) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import B
>>> B.B1.__module__
'A'
>>> B.B2.__module__
'B'

Among others, this problem causes pydoc to only display
documentation for B2 as part of the docs for module B.

Presumably, the behaviour for B2 is correct.

Regards,

Roeland Rengelink


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:33

Message:
Logged In: YES 
user_id=6380

Closing this, as it's fixed.

----------------------------------------------------------------------

Comment By: Roeland Rengelink (rengelink)
Date: 2002-03-08 23:58

Message:
Logged In: YES 
user_id=302601

This bug is now also reported under #516532

----------------------------------------------------------------------

Comment By: Roeland Rengelink (rengelink)
Date: 2002-01-16 03:16

Message:
Logged In: YES 
user_id=302601

I came upon the other bug reports by browsing the bug
database, but I didn't write the numbers down. The only ones
I did find again when I looked this morning are:

#442501
#487390

Neither are really related to the problem reported here
though,

Thanks for the fix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 16:07

Message:
Logged In: YES 
user_id=6380

Fixed in compile.c 2.235, by initializing __module__ to the
contents of the global variable __name__ at the start of the
class statement. Not 100% satisfied with that, but can't
come up with something better right now.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:33

Message:
Logged In: YES 
user_id=6380

You're right. This is because __module__ is taken from the
globals of the currently executing Python code.

This is clearly a bug. I'll have to think about how to fix
it -- maybe the class statement will have to set it.

I can't find the other bug reports related to __module__;
the SF search box apparently searches for "module" when I
type that in the search box, and that hits about every other
bug report ever submitted, including closed ones. :-(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503837&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:34:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:34:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E16ocIJ-00059p-00@usw-sf-web4.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 07:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 08:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 07:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-25 07:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 06:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 14:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:36:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:36:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-216289 ] Programs using Tkinter sometimes can't shut down (Windows)
Message-ID: <E16ocKl-0004kz-00@usw-sf-web2.sourceforge.net>

Bugs item #216289, was opened at 2000-10-06 22:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470

Category: Windows
>Group: Python 2.3
Status: Open
>Resolution: Later
Priority: 3
Submitted By: Tim Peters (tim_one)
>Assigned to: Tim Peters (tim_one)
Summary: Programs using Tkinter sometimes can't shut down (Windows)

Initial Comment:
The following msg from the Tutor list is about 1.6, but I noticed the same thing several times today using 2.0b2+CVS.  In my case, I was running IDLE via

python ../tool/idle/idle.pyw

from a DOS box in my PCbuild directory.  Win98SE.  *Most* of the time, shutting down IDLE via Ctrl+Q left the DOS box hanging.  As with the poster, the only way to regain control was to use the Task Manager to kill off Winoldap.

-----Original Message-----
From: Joseph Stubenrauch <nothingisgoingtochangemyworld@yahoo.com>
Sent: Friday, October 06, 2000 9:23 PM
To: tutor@python.org
Subject: Re: [Tutor] Python 1.6 BUG


Strange, I have been experiencing the same bug myself.
Here's the low down for me:

Python 1.6 with win95
I am running a little Tkinter program
The command line I use is simply: "python foo.py"
About 25-35% of the time, when I close the Tkinter
window, DOS seems to "freeze" and never returns to the
c:\ command prompt.  I have to ctrl-alt-delete
repeatedly and shut down "winoldapp" to get rid of the
window and then shell back into DOS and keep working.
It's a bit of a pain, since I have the habit of
testing EVERYTHING in tiny little stages, so I change
one little thing, test it ... freeze ... ARGH!  Change
one more tiny thing, test it ... freeze ... ARGH! 
However, sometimes it seems to behave and doesn't
bother me for an entire several hour session of python
work.

That's my report on the problem.

Cheers,

Joe


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:36

Message:
Logged In: YES 
user_id=6380

The proper action is to wait until Tcl 8.3.5 is released,
and then shaming someone else in providing you with a set of
Windowsbinaries for Tcl. You may also ask Hobbs if there's a
Windows project file to build Tcl/Tk for Windows.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-03-11 21:31

Message:
Logged In: YES 
user_id=72656

I did end up back-porting this to the 8.3.4+ Tcl CVS on 
2002-02-25, which means it will be in an eventual 8.3.5.  
It is already in the release 8.4 alpha series.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-09 20:50

Message:
Logged In: YES 
user_id=31435

Back to Guido:  Do you think you know what the proper 
action is?  (You said that's why you reopened it, and 
there's been no new info here since then.)

----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 19:55

Message:
Logged In: YES 
user_id=143340

I knew I wasn't getting to the heart of it ....

Almost a one-liner!

It has been seriously spoiling my (otherwise crash free) 
Python experience on Win9x - hope it gets fixed soon.

cheers,
John.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-25 18:39

Message:
Logged In: YES 
user_id=6380

Reopened until we know what the proper action is.

----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-02-25 18:32

Message:
Logged In: YES 
user_id=72656

This is mostly correct, and is fixed in the 8.4 Tcl sources 
already (I guess we can backport this).  This was mentioned 
in SF Tcl bug (account for chopped URL):

https://sourceforge.net/tracker/?
func=detail&aid=217982&group_id=10894&atid=110894

and the code comment is:

    /*
     * Only finalize the notifier if a notifier was 
installed in the
     * current thread; there is a route in which this is not
     * guaranteed to be true (when tclWin32Dll.c:DllMain() 
is called
     * with the flag DLL_PROCESS_DETACH by the OS, which 
could be
     * doing so from a thread that's never previously been 
involved
     * with Tcl, e.g. the task manager) so this check is 
important.
     *
     * Fixes Bug #217982 reported by Hugh Vu and Gene 
Leache.
     */
    if (tsdPtr == NULL) {
	return;
    }


----------------------------------------------------------------------

Comment By: John Popplewell (johnnypops)
Date: 2002-02-25 17:41

Message:
Logged In: YES 
user_id=143340

This one has been torturing me for a while.

Managed to track it down to a problem inside Tcl.
For the Tcl8.3.4 source distribution the problem is in
the file win/tclWinNotify.c 

void Tcl_FinalizeNotifier(ClientData clientData)
{
    ThreadSpecificData *tsdPtr = 
                         (ThreadSpecificData *) clientData;

    /* sometimes called with tsdPtr == NULL */
    if ( tsdPtr != NULL )
    {
        DeleteCriticalSection(&tsdPtr->crit);
        CloseHandle(tsdPtr->event);

        /*
         * Clean up the timer and messaging 
         * window for this thread.
         */

        if (tsdPtr->hwnd) {
	    KillTimer(tsdPtr->hwnd, INTERVAL_TIMER);
            DestroyWindow(tsdPtr->hwnd);
        }
    }

    /*
     * If this is the last thread to use the notifier, 
     * unregister the notifier window class.
     */

    Tcl_MutexLock(&notifierMutex);
    if ( notifierCount && !--notifierCount ) {
	UnregisterClassA( "TclNotifier", 
                          TclWinGetTclInstance());
    }
    Tcl_MutexUnlock(&notifierMutex);
}

This bodge doesn't address the underlying problem but has 
stopped me from tearing all my hair out,

cheers,
John Popplewell.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-24 18:27

Message:
Logged In: YES 
user_id=31435

FYI, you don't need an IDE to do this -- in Win9x, hit 
Ctrl+Alt+Del and kill the process directly.

A saner <wink> solution is to develop under Win2K, which 
doesn't appear to suffer this problem (the only reports 
I've seen, and experienced myself, came from Win9x boxes).

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-24 04:52

Message:
Logged In: NO 

For those who are still trapped in this bug's hell, I will 
gladly share the one thing that saved my sanity:  
WingIDE's 'Kill' command will shut down the program with 
apparent 100% certainty and no fear of lockups.  WingIDE 
has its own issues, so its not a perfect solution, but if 
you are like me and Joe (above) who test in small 
iterations, then using 'Kill' to quit out of your app while 
testing is a workaround that may preserve your sanity.

Perhaps the python gods and the Wing guys can get together 
and tell us how to replicate 'kill' into our code.  For 
now, I'll use WingIDE to edit, and pythonw.exe for my final 
client's delivery.

----------------------------------------------------------------------

Comment By: Howard Lightstone (hlightstone)
Date: 2001-09-05 13:43

Message:
Logged In: YES 
user_id=66570

I sometimes get bunches of these....

A tool I use (Taskinfo2000) reports that (after killing 
winoldap):

python.exe is blocked on a mutex named OLESCELOCKMUTEX.
The reported state is "Console Terminating".  There appears 
to be only one (os) thread running.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-02 16:06

Message:
Logged In: YES 
user_id=31435

No sign of progress on this presumed Tk/Tcl Windows bug in 
over 3 months, so closing it for lack of hope.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-06 00:13

Message:
This was a symptom I saw while tracking down the essence of the problem reported in #131207.  Using Win98SE, I would get an error dialog (GPF?) in the Kernel, and sometimes the dos prompt would not come back.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-12-12 21:00

Message:
Just reproduced w/ current CVS, but didn't hang until the 8th try.

http://dev.scriptics.com/software/tcltk/ says 8.3 is still the latest released version; don't know whether that URL still makes sense, though.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 15:58

Message:
Tim, can you still reproduce this with the current CVS version?

There's been one critical patch to _tkinter since the 2.0 release.

An alternative would be to try with a newer version of Tcl (isn't 8.4 out already?).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-15 12:47

Message:
Same as I've reported earlier; it hangs in the call to
Tcl_Finalize (which is called by the DLL finalization
code).  It's less likely to hang if I call Tcl_Finalize
from the _tkinter DLL (from user code).

Note that the problem isn't really Python-related -- I
have stand-alone samples (based on wish) that hangs in
the same way.

More later.

</F>

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-13 10:40

Message:
Back to Tim since I have no clue what to do here.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-10-12 13:25

Message:
The recent fix to _tkinter (Tcl_GetStringResult(interp) instead of interp->result) didn't fix this either.

As Tim has remarked in private but not yet recorded here, a workaround is to use pythonw instead of python, so I'm lowering thepriority again.

Also note that the hanging process that Tim writes about apparently prevents Win98 from shutting down properly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2000-10-07 03:37

Message:
More info (none good, but some worse so boosted priority):

+ Happens under release and debug builds.

+ Have not been able to provoke when starting in the debugger.

+ Ctrl+Alt+Del and killing Winoldap is not enough to clean everything up.  There's still a Python (or Python_d) process hanging around that Ctrl+Alt+Del doesn't show.

+ This process makes it impossible to delete the associated Python .dll, and in particular makes it impossible to rebuild Python successfully without a reboot.

+ These processes cannot be killed!  Wintop and Process Viewer both fail to get the job done.  PrcView (a freeware process viewer) itself locks up if I try to kill them using it.  Process Viewer freezes for several seconds before giving up.

+ Attempting to attach to the process with the MSVC debugger (in order to find out what the heck it's doing) finds the process OK, but then yields the cryptic and undocumented error msg "Cannot execute program".

+ The processes are not accumulating cycles.

+ Smells like deadlock.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216289&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:39:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:39:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-514676 ] multifile different in 2.2 from 2.1.1
Message-ID: <E16ocNb-0005Cx-00@usw-sf-web4.sourceforge.net>

Bugs item #514676, was opened at 2002-02-08 01:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514676&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
>Assigned to: Martin v. Löwis (loewis)
Summary: multifile different in 2.2 from 2.1.1

Initial Comment:
Reported to python-help. When the test program I'll
attach is run on the test mail I'll attach separately,
it produces this under Python 2.1.1:

TYPE: multipart/mixed
BOUNDARY: =====================_590453667==_
TYPE: multipart/alternative
BOUNDARY: =====================_590453677==_.ALT
TYPE: text/plain
LINES: ['test A\n']
TYPE: text/html
LINES: ['<html>\n', '<b>test B</font></b></html>\n',
'\n']
TYPE: text/plain
LINES: ['Attached Content.\n', 'Attached Content.\n',
'Attached 
Content.\n', 'Attached Content.\n','\n']

But under Python 2.2, it produces:

TYPE: multipart/mixed
BOUNDARY: =====================_590453667==_
TYPE: text/plain
LINES: ['Attached Content.\n', 'Attached Content.\n',
'Attached 
Content.\n', 'Attached Content.\n']

The first output appears to me to be correct.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:39

Message:
Logged In: YES 
user_id=6380

Fine with me to roll back the patch. I think that should be
a bugfix candidate, maybe for 2.2.2.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-12 14:22

Message:
Logged In: YES 
user_id=198518

It turns out that the problem is more intractable than I thought at first. Here's what seems to happen: the readahead function can consume the separator before the user calls push() with it. Since the readahead function decides whether or not a line matches a separator, the push() comes too late and the line is returned as ordinary data.

Of course Martijn Pieters is right about conformance to RFC 2046 but it's not obvious to me how to strip the last line-end before a separator and also avoid consuming separators that shouldn't be consumed and retain the public interface of the module.

I think that the simplest thing to do would be to resotre the functionality that was in revision 1.18 and tell people who need strict conformance to RFC 2046 that they should use the email module instead since it does strip the last line end before a separator.

The person who posed the original question would be happy to have his files used as part of a test suite.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 23:49

Message:
Logged In: YES 
user_id=198518

It seems that SourceForge won't let me delete the patch.
Please ignore it.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 23:47

Message:
Logged In: YES 
user_id=198518

Sorry, I think my analysis is right but the patch is flawed and I've deleted it. I'll try to have another look at it tomorrow.

----------------------------------------------------------------------

Comment By: Matthew Cowles (mdcowles)
Date: 2002-02-10 23:20

Message:
Logged In: YES 
user_id=198518

The problem is in _readline(). Since it changes self.level and self.last, they apply to the next line, not the current one. I'll upload a patch that seems to work.

The test program and test mail aren't mine. They belong to the person who reported the bug to python-help. I'm sure that he'd be glad to have them used as part of the test suite but I'll mail him to make absolutely certain.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 16:43

Message:
Logged In: YES 
user_id=6380

You're absolutely right -- this is a bug.

Can you suggest a fix?

We also need a test suite!  Your test program is a beginning
for that...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514676&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:40:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:40:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-524804 ] breaking file iter loop leaves file in stale state
Message-ID: <E16ocOH-0001jW-00@usw-sf-web1.sourceforge.net>

Bugs item #524804, was opened at 2002-03-02 10:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Guido van Rossum (gvanrossum)
Summary: breaking file iter loop leaves file in stale state

Initial Comment:
Given a file created with this snippet:

  >>> f = open("tmp.txt", "w")
  >>> for i in range(10000):
  ...     f.write("%s\n" % i)
  ... 
  >>> f.close()

Iterating over a file multiple times has unexpected 
behavior:

  >>> f = open("tmp.txt")
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  0
  >>> for line in f:
  ...     print line.strip()
  ...     break
  ... 
  1861
  >>> 

I expected the last output line to be 1 instead of 
1861.

While I understand the cause (xreadlines being 
used by the
file iterator, it reads a big chunk ahead, causing 
the actual
filepos to be out of sync), this seems to be an 
undocumented
gotcha. The docs say this:

  [ ... ] Each iteration returns the same result as
  file.readline(), and iteration ends when the 
readline()
  method returns an empty string. 

That is true within one for loop, but not when you 
break out
of the loop and start another one, which I think is a 
valid
idiom.

Another example of breakage:

  f = open(...)
  for line in f:
      if somecondition(line):
	  break
      ...
  
  data = f.read()  # read rest in one slurp

The fundamental problem IMO is that the file 
iterator stacks
*another* state on top of an already stateful object. 
In a
sense a file object is already an iterator. The two 
states get
out of sync, causing confusing semantics, to say 
the least.
The current behavior exposes an implementation 
detail that
should be hidden.

I understand that speed is a major issue here, so 
a solution
might not be simple.

Here's a report from an actual user:
http://groups.google.com/groups?hl=en&selm=
owen-
0B3ECB.10234615022002%40nntp2.u.washingto
n.edu
The rest of the thread suggests possible 
solutions.

Here's what I *think* should happen (but: I'm 
hardly aware
of both the fileobject and xreadline innards) is this:
xreadlines should be merged with the file object. 
The buffer
that xreadlines implements should be *the* buffer 
for the
file object, and *all* read methods should use *
that* buffer
and the according filepos.

Maybe files should grow a .next() method, so iter(f) 
can return
f itself. .next() and .readline() are then 100% 
equivalent.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:40

Message:
Logged In: YES 
user_id=6380

Closing as won't fix.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-19 22:43

Message:
Logged In: YES 
user_id=6380

There are two forces at work here.

You want the most common case (a single "for line in file"
that consumes the whole file) to run blindingly fast.

And you want full generality, basically equating next() with
readline() (except raising StopIteration on EOF).

Unfortunately, the only way to go blindingly fast is to do
aggressive buffering, and that's what xreadlines does. Until
we rewrite the entire I/O system so we have total control
over buffering ourselves, it's not easy to mix xreadlines
with other operations (readline, seek, tell).

We could make the default file iterator use readline, but
then it would become much slower, and we'd have to teach
people about xreadlines if they want speed. Or we could use
the current solution, where speed is the default, and you
have to be more careful when you use an unusual coding
style, like breaking out of the for loop and continuing in a
second for loop.

I'm not sure which requirement is more common (speed, or
generality), but since looping over all the lines of a (big)
file is such a common pattern, I would bet the speed is the
more important of the two.

In the past we've had a lot of flak about the slowness of
the general solution of looping over all lines in a file;
the xreadlines-based iterator is much faster, and I am
reluctant to change this back in Python 2.3; I'd rather
document it carefully (after all, "for line in lines" is a
new construct in Python 2.2, and people have to be told
about it; we might as well tell them about the limitations
and how to work around them).

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-03-19 12:37

Message:
Logged In: YES 
user_id=10327

I'm in favor for the "let files be their own iterator and set .next equal to .readline" solution. The above example can _really_ bite you.

The current xreadlinesmodule.c could be converted to a standalone module, if it really is necessary to optimize.

The trivial solution for this problem is to change CHUNKSIZE (in Modules/xreadlinesmodule) to 1. Or, even better, to convert it into an instance variable, so you can do this:

f=open(...)
fi=f.iter(chunk=2000)
for line in fi:
    ...

if you want speed, or just write

for line in f:

(which internally converts to f.iter(chunk=1))

if you want safety.

I'm not too firm with Python C interfacing, otherwise I'd write a patch... any takers?

----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-08 04:35

Message:
Logged In: YES 
user_id=18139

Tim wrote: "I'm sure Guido was aware of this."

    ...Wow, really?  That kind of puts a damper on
       my theory.  I guess it can't be a bug after
       all.  :)

Tim wrote: "Making the simplest-to-spell idiom as fast as 
possible was a deliberate decision at the time."

    ...*That* I believe.


----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-08 04:08

Message:
Logged In: YES 
user_id=92689

At the cost of, what, sensible, predictable semantics?
- fast is better than slow
- but slow is better than unpredictable
Or something...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-07 20:16

Message:
Logged In: YES 
user_id=31435

I'm sure Guido was aware of this.  Making the simplest-to-
spell idiom as fast as possible was a deliberate decision 
at the time.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-07 20:06

Message:
Logged In: YES 
user_id=31392

If I understand the checkin message Guido wrote for 2.113, 
he didn't intend the current behavior.

> file_getiter(): make iter(file) be equivalent to 
>file.xreadlines().
> This should be faster.
>
> This means:
>
> (1) "for line in file:" won't work if the xreadlines 
module can't be
>    imported.
>
> (2) The body of "for line in file:" shouldn't use the 
file directly;
>     the effects (e.g. of file.readline(), file.seek() or 
even
>     file.tell()) would be undefined because of the 
buffering that goes
>     on in the xreadlines module.


----------------------------------------------------------------------

Comment By: Jason Orendorff (jorend)
Date: 2002-03-04 01:47

Message:
Logged In: YES 
user_id=18139

Agreed on all points of fact.  Also +1 on fixing it
by making iter(f).next() and f.readline() equivalent,
one way or another.

...The easy way: make f.__iter__() call readline()
instead of being so aggressive.  (Better than nothing,
in my view.)

...The hard way (JvR's proposal): add a level of input
buffering on top of what the C runtime provides.
xreadlines() breaks user expectations precisely
because it does this *halfway*.  Doing it right would
not be such a maintenance burden, I think.  I'm willing
to write the patch, although others wiser in the ways
of diverse stdio implementations (<wink>) might want
to supervise.

...As it stands, iter(f) seems like a broken
optimization.  Which is to say: it's not "undocumented
surprising behavior"; it's a bug.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524804&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:41:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:41:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-421973 ] Coercion rules incomplete
Message-ID: <E16ocPd-0004oQ-00@usw-sf-web2.sourceforge.net>

Bugs item #421973, was opened at 2001-05-07 05: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: 1
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 14: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  Sat Mar 23 03:45:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:45:03 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-501831 ] Bit support in "array" module
Message-ID: <E16ocSl-00029t-00@usw-sf-web3.sourceforge.net>

Feature Requests item #501831, was opened at 2002-01-10 09:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jesús Cea Avión (jcea)
Assigned to: Guido van Rossum (gvanrossum)
>Summary: Bit support in "array" module

Initial Comment:
I think the standard "array" module should support 
single bit arrays.

In fact, would be very nice a supplementary addition 
to support arbitrary bit size arrays (for example, 5 
bit elements). Of course, single bit should be 
optimiced, since bitmaps management is a frequent task.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

While bit arrays would indeed be nice, the array module's
internal design makes it impractical to add it there. For
small-to-medium size bitmasks, I recommend using long ints
(x<<i is a bitmask for bit i, use & and | and ~ to set and
clear bits). If someone wants to implement a fast bitmap
type in C, let them submit an extension to the patch
manager. Closing this request as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=501831&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:45:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:45:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-473985 ] str, __getitem__ and slices
Message-ID: <E16ocTR-0004qr-00@usw-sf-web2.sourceforge.net>

Bugs item #473985, was opened at 2001-10-23 06:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470

Category: Type/class unification
>Group: Python 2.3
Status: Open
Resolution: Remind
>Priority: 6
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Guido van Rossum (gvanrossum)
Summary: str, __getitem__ and slices

Initial Comment:
Using slices with __getitem__ doesn't work with 
classes derived from str:
---
class S(str):
   def __getitem__(self, index):
      print "getitem", index
      return str.__getitem__(self, index)
   def __setitem__(self, index, value):
      print "setitem", index, value

s = S("foo")
print s[0]
print s[0:2]
s[0] = "b"
s[0:2] = "bar"
---
This prints:
---
getitem 0
f
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
instead of
---
getitem 0
f
getitem slice(0, 2, None)
fo
setitem 0 b
setitem slice(0, 2, None) bar
---
i.e. when no __getslice__ is defined s[0:2] will not 
be forwarded to __getitem__, but it seems to work for 
__setitem__.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:45

Message:
Logged In: YES 
user_id=6380

Raising the priority slightly and marking as a 2.3 issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 10:50

Message:
Logged In: YES 
user_id=6380

I've thought about this some more.

It should be fixed, but the fix is complex, and think I'd
rather not make this change in 2.2 -- (1) I have little
time, and (2) we've already issued a beta release and a
declared a feature freeze. So I'd like to put this on hold
until I can start working on 2.3. This is what would have to
be done:

- Change all built-in sequence types to get rid of the
sq_slice and sq_ass_slice dispatch functions; instead, add a
mapping extension to these types and add mp_subscript and
mp_ass_subscript dispatch functions that recognize slice
objects.

- We'd probably also have to get rid of the sq_item and
sq_ass_item dispatch functions, to roll them into
mp_subscript and mp_ass_subscript.

- Possibly, the whole "PySequenceMethods" structure should
be deprecated; all the operations there are overloading
either numerical or mapping operations.

Extension types that define a sequence methods structure
should continue to work, but the recommendation would be to
migrate these out.

I wish I could do this in 2.2, but it's really too much work
to start now, *and* it would be a serious incompatibility
between 2.2b1 and 2.2b2.

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-10-23 10:05

Message:
Logged In: YES 
user_id=89016

Oops, this wasn't meant to be a patch. Should have gone 
into the bugs category.

The problems is that http://python.sourceforge.net/devel-
docs/ref/sequence-methods.html says, that __getslice__ 
is "Deprecated since release 2.0", so the user will want to 
implement __getslice__ via __getitem__.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-10-23 09:48

Message:
Logged In: YES 
user_id=6380

I don't think this is a bug. S inherits __getslice__ from
the str base class, but since str is immutable, it doesn't
define a __setslice__ to inherit for S.

BTW I'm reclassifying this as a bug, not a patch. This will
unfortunately invalidate the old URL you had for this entry
(SF doesn't really like reclassification that much.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473985&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:47:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:47:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-210682 ] pdb can only step when at botframe (PR#4)
Message-ID: <E16ocV8-0002BH-00@usw-sf-web3.sourceforge.net>

Bugs item #210682, was opened at 2000-07-31 17:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: Later
>Priority: 1
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pdb can only step when at botframe (PR#4)

Initial Comment:
Jitterbug-Id: 4
Submitted-By: MHammond@skippinet.com.au
Date: Mon, 12 Jul 1999 15:38:43 -0400 (EDT)
Version: 1.5.2
OS: Windows


[Resubmitted by GvR]

It is a problem that bugged me for _ages_.  Since the years I first wrote
the Pythonwin debugger Ive learnt alot about how it works :-)

The problem is simply:  when the frame being debugged is self.botframe, it
is impossible to continue - only "step" works.  A "continue" command
functions as a step until you start debugging a frame below self.botframe.

It is less of a problem with pdb, but makes a GUI debugger clunky - if you
start a debug session by stepping into a module, the "go" command seems
broken.

The simplest way to demonstrate the problem is to create a module, and add
a "pdb.set_trace()" statement at the top_level (ie, at indent level 0).
You will not be able to "continue" until you enter a function.

My solution was this:  instead of run() calling "exec" directly, it calls
another internal function.  This internal function contains a single line -
the "exec", and therefore never needs to be debugged directly.  Then
stop_here is modified accordingly.

The end result is that "self.botframe" becomes an "intermediate" frame, and
is never actually stopped at - ie, self.botframe effectivly becomes one
frame _below_ the bottom frame the user is interested in.

Im not yet trying to propose a patch, just to discuss this and see if the
"right thing" can be determined and put into pdb.

Thanks,

Mark.




====================================================================
Audit trail:
Mon Jul 12 15:39:35 1999	guido	moved from incoming to open

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-01 17:55

Message:
Logged In: YES 
user_id=6380

Yes, it's really a bug -- it's an annoyance, you have to hit
contine twice.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:30

Message:
Logged In: YES 
user_id=31392

Is this really a bug?  Or just a feature request?  Perhaps 
we should move it to 42 and close the report.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:19

Message:
Sorry I forgot to sigh the comment for 2000-Oct-17 07:18
David Hurt
davehurt@flash.net

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2000-10-17 10:18

Message:
My common workaround is to always create a function called debug(): that calls the function in the module I am debugging.  Instead of doing a runcall for my function I do a runcall on debug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210682&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:49:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:49:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-505028 ] Super method search quirk
Message-ID: <E16ocX6-0002CW-00@usw-sf-web3.sourceforge.net>

Bugs item #505028, was opened at 2002-01-17 14:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Super method search quirk

Initial Comment:
I think the following qualifies as a bug; I think the 
call to super(C, self).m() should cause an exception 
(the super_getattro search should not find the m in A 
if an m is defined in B):

>>> class A(object):
...     def m(self):
...         print 'A'
...
>>> class B(A):
...     m = property(lambda self: 'B')
...
>>> class C(B):
...     def m(self):
...         super(C, self).m()
...         print 'C'
...
>>> c = C()
>>> c.meth()
A
C



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:49

Message:
Logged In: YES 
user_id=6380

Closing as Rejected.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:34

Message:
Logged In: YES 
user_id=6380

It would seem a bug, but according to the CVS log it's
intentional. typeobject.c 2.120 introduces an explicit check
that skips data descriptors (such as properties). The
motivation:

- super(C, C()).__class__ would return the __class__
attribute of C()
  rather than the __class__ attribute of the super object. 
This is
  confusing.  To fix this, I decided to change the semantics
of super
  so that it only applies to code attributes, not to data
attributes.
  After all, overriding data attributes is not supported
anyway.

So I think this is a feature after all.


----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 17:27

Message:
Logged In: YES 
user_id=35752

I agree.  This looks like a bug with super().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505028&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 03:48:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 19:48:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-481985 ] Uncaught MI order conflict
Message-ID: <E16ocWW-0005IM-00@usw-sf-web4.sourceforge.net>

Bugs item #481985, was opened at 2001-11-15 01:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481985&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Uncaught MI order conflict

Initial Comment:
Dubious MRO from mixing classic and new-style classes 
in multiple inheritance:

> def mrolist(k):
>     return ' '.join([c.__name__ for c in k.__mro__])
> 
> def f():
>     # No question here.
>     class C: pass
>     class M1(C, object): pass
>     print mrolist(M1) # "M1 C object"
> 
>     # And no question here.
>     class D(C): pass
>     class M2(object, D): pass
>     print mrolist(M2) # "M2 object D C"
> 
>     # Here I expected
>     #     "M3 M1 M2 object D C"
>     # but got
>     #     "M3 M1 M2 D C object"
>     class M3(M1, M2): pass
>     print mrolist(M3)
> 
> f()

"""
If I add

    class M4(M2, M1): pass
    print mrolist(M4)

this prints what you may have expected:

    M4 M2 M1 object D C

My conclusion is that it's an artefact of how 
conservative_merge() resolves the conflict between M1 
and M2: in M1, C preceeds object, while in M2, object 
preceeds C.  This order conflict is supposed to be
outlawed, but I didn't feel like testing for it -- the 
function serious_order_disagreements() always returns 
false.

In the light of conflicts, the algorithm in 
conservative() apparently favors the order of the 
first base class encountered.
"""

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:48

Message:
Logged In: YES 
user_id=6380

Closing as Won't Fix. In the light of conflicts, the MRO
algorithm can yield surprises, yes. Then don't do that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481985&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 05:34:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 21:34:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-450225 ] urljoin fails RFC tests
Message-ID: <E16oeAa-0003GJ-00@usw-sf-web3.sourceforge.net>

Bugs item #450225, was opened at 2001-08-12 00:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron Swartz (aaronsw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urljoin fails RFC tests

Initial Comment:
I've put together a test suite for Python's URLparse 
module, based on the tests in Appendix C of 
RFC2396 (the URI RFC). They're available at:

http://lists.w3.org/Archives/Public/uri/2001Aug/
0013.html

The major problem seems to be that it treats 
queries and parameters as special components 
(not just normal parts of the path), making this 
related to:

http://sourceforge.net/tracker/?group_id=5470&
atid=105470&func=detail&aid=210834

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 23:34

Message:
Logged In: YES 
user_id=44345

added Aaron's RFC 2396 tests to test_urlparse.py
version 1.4 - the two failing tests are commented out



----------------------------------------------------------------------

Comment By: Jon Ribbens (jribbens)
Date: 2002-03-18 08:22

Message:
Logged In: YES 
user_id=76089

I think it would be better btw if '..' components taking 
you 'off the top' were stripped. RFC 2396 says this is 
valid behaviour, and it's what 'real' browsers do.

i.e.
  http://a/b/ + ../../../d == http://a/d


----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 12:34

Message:
Logged In: YES 
user_id=122141

Oops, meant to attach it...

----------------------------------------------------------------------

Comment By: Aaron Swartz (aaronsw)
Date: 2001-11-05 12:30

Message:
Logged In: YES 
user_id=122141

Sure, here they are:



import urlparse

base = 'http://a/b/c/d;p?q'

assert urlparse.urljoin(base, 'g:h') == 'g:h'
assert urlparse.urljoin(base, 'g') ==   'http://a/b/c/g'
assert urlparse.urljoin(base, './g') == 'http://a/b/c/g'
assert urlparse.urljoin(base, 'g/') ==  'http://a/b/c/g/'
assert urlparse.urljoin(base, '/g') ==  'http://a/g'
assert urlparse.urljoin(base, '//g') == 'http://g'
assert urlparse.urljoin(base, '?y') ==  'http://a/b/c/?y'
assert urlparse.urljoin(base, 'g?y') == 'http://a/b/c/g?y'
assert urlparse.urljoin(base, '#s') ==  'http://a/b/c/
d;p?q#s'
assert urlparse.urljoin(base, 'g#s') == 'http://a/b/c/g#s'
assert urlparse.urljoin(base, 'g?y#s') == 'http://a/b/c/
g?y#s'
assert urlparse.urljoin(base, ';x') == 'http://a/b/c/;x'
assert urlparse.urljoin(base, 'g;x') ==  'http://a/b/c/g;x'
assert urlparse.urljoin(base, 'g;x?y#s') == 'http://a/b/c/
g;x?y#s'
assert urlparse.urljoin(base, '.') ==  'http://a/b/c/'
assert urlparse.urljoin(base, './') ==  'http://a/b/c/'
assert urlparse.urljoin(base, '..') ==  'http://a/b/'
assert urlparse.urljoin(base, '../') ==  'http://a/b/'
assert urlparse.urljoin(base, '../g') ==  'http://a/b/g'
assert urlparse.urljoin(base, '../..') ==  'http://a/'
assert urlparse.urljoin(base, '../../') ==  'http://a/'
assert urlparse.urljoin(base, '../../g') ==  'http://a/g'

assert urlparse.urljoin(base, '') == base

assert urlparse.urljoin(base, '../../../g')    ==  'http://a/../g'
assert urlparse.urljoin(base, '../../../../g') ==  'http://a/../../g'

assert urlparse.urljoin(base, '/./g') ==  'http://a/./g'
assert urlparse.urljoin(base, '/../g')         ==  'http://a/../g'
assert urlparse.urljoin(base, 'g.')            ==  'http://a/b/c/
g.'
assert urlparse.urljoin(base, '.g')            ==  'http://a/b/c/
.g'
assert urlparse.urljoin(base, 'g..')           == 'http://a/b/c/
g..'
assert urlparse.urljoin(base, '..g')           == 'http://a/b/c/
..g'

assert urlparse.urljoin(base, './../g')        ==  'http://a/b/g'
assert urlparse.urljoin(base, './g/.')         ==  'http://a/b/c/
g/'
assert urlparse.urljoin(base, 'g/./h')         ==  'http://a/b/c/
g/h'
assert urlparse.urljoin(base, 'g/../h')        ==  'http://a/b/c/
h'
assert urlparse.urljoin(base, 'g;x=1/./y')     ==  
'http://a/b/c/g;x=1/y'
assert urlparse.urljoin(base, 'g;x=1/../y')    ==  'http://a/b/
c/y'

assert urlparse.urljoin(base, 'g?y/./x')       ==  
'http://a/b/c/g?y/./x'
assert urlparse.urljoin(base, 'g?y/../x')      == 
'http://a/b/c/g?y/../x'
assert urlparse.urljoin(base, 'g#s/./x')       ==  'http://a/b/
c/g#s/./x'
assert urlparse.urljoin(base, 'g#s/../x')      ==  'http://a/b/
c/g#s/../x'



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-11-05 12:05

Message:
Logged In: YES 
user_id=3066

This looks like its probably related to #478038; I'll try to
tackle them together.  Can you attach your tests to the bug
report on SF?  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=450225&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 06:02:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 22 Mar 2002 22:02:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-411881 ] Use of "except:" in modules
Message-ID: <E16oecE-0003Wx-00@usw-sf-web3.sourceforge.net>

Bugs item #411881, was opened at 2001-03-28 06:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Itamar Shtull-Trauring (itamar)
Assigned to: Skip Montanaro (montanaro)
>Summary: Use of "except:" in modules

Initial Comment:
A large amount of modules in the standard library use
"except:" instead of specifying the exceptions to be
caught. In some cases this may be correct, but I think
in most cases this not true and this may cause
problems. Here's the list of modules, which I got by
doing:

   grep "except:" *.py | cut -f 1 -d " " | sort | uniq

Bastion.py
CGIHTTPServer.py
Cookie.py
SocketServer.py
anydbm.py
asyncore.py
bdb.py
cgi.py
chunk.py
cmd.py
code.py
compileall.py
doctest.py
fileinput.py
formatter.py
getpass.py
htmllib.py
imaplib.py
inspect.py
locale.py
locale.py
mailcap.py
mhlib.py
mimetools.py
mimify.py
os.py
pdb.py
popen2.py
posixfile.py
pre.py
pstats.py
pty.py
pyclbr.py
pydoc.py
repr.py
rexec.py
rfc822.py
shelve.py
shutil.py
tempfile.py
threading.py
traceback.py
types.py
unittest.py
urllib.py
zipfile.py


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-23 00:02

Message:
Logged In: YES 
user_id=44345

as partial fix, checked in changes for the following
modules:

  mimetools.py (1.24)
  popen2.py (1.23)
  quopripy (1.19)
  CGIHTTPServer.py (1.22)


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-20 15:24

Message:
Logged In: YES 
user_id=44345

Here is a context diff with proposed changes for the
following modules: CGIHTTPServer, cgi, cmd, code, 
fileinput, httplib, inspect, locale, mimetools, popen2,
quopri


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-08-11 10:06

Message:
Logged In: YES 
user_id=21627

Fixed urllib in 1.131 and types in 1.19.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-04 02:11

Message:
Logged In: YES 
user_id=3066

Fixed modules mhlib and rfc822 (SF is having a problem
generating the checkin emails, though).

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-05-11 14:40

Message:
Logged In: YES 
user_id=3066

OK, I've fixed up a few more modules:

anydbm
chunk
formatter
htmllib
mailcap
pre
pty

I made one change to asyncore as well, but other bare except
clauses remain there; I'm not sufficiently familiar with
that code to just go digging into those.

I also fixed an infraction in pstats, but left others for now.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-04-23 03:14

Message:
Logged In: YES 
user_id=31435

Ping's intent is that pydoc work under versions of Python 
as early as 1.5.2, so that sys._getframe is off-limits in 
pydoc and its supporting code (like inspect.py).

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-04-23 02:32

Message:
Logged In: YES 
user_id=21627

For inspect.py, why is it necessary to keep the old code at
all? My proposal: remove currentframe altogether, and do
currentframe = sys._getframe
unconditionally.

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-22 09:52

Message:
Logged In: YES 
user_id=32065

I submitted a 4th patch. I'm starting to run out of easy
cases...

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-04-19 04:15

Message:
Logged In: YES 
user_id=44345

I believe the following patch is correct for the try/except
in inspect.currentframe.  Note that it fixes two problems. 
One, it avoids a bare except.  Two, it gets rid of a string
argument to the raise statement (string exceptions are now
deprecated, right?).

*** /tmp/skip/inspect.py	Thu Apr 19 04:13:36 2001
--- /tmp/skip/inspect.py.~1.16~	Thu Apr 19 04:13:36 2001
***************
*** 643,650 ****
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         1/0
!     except ZeroDivisionError:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe
--- 643,650 ----
  def currentframe():
      """Return the frame object for the caller's stack
frame."""
      try:
!         raise 'catch me'
!     except:
          return sys.exc_traceback.tb_frame.f_back
  
  if hasattr(sys, '_getframe'): currentframe = sys._getframe


----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-04-17 10:27

Message:
Logged In: YES 
user_id=32065

inspect.py uses sys_getframe if it's there, the other code
is for backwards compatibility.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 12:24

Message:
Logged In: YES 
user_id=6380

Actually, inspect.py should use sys._getframe()!

And yes, KeyboardError is definitely one of the reasons why
this is such a bad idiom...

----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:15

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Walter Dörwald (doerwalter)
Date: 2001-04-11 12:13

Message:
Logged In: YES 
user_id=89016

> Can you identify modules where catching everything 
> is incorrect

If "everything" includes KeyboardInterrupt, it's
definitely incorrect, even in inspect.py's simple

    try:
        raise 'catch me'
    except:
        return sys.exc_traceback.tb_frame.f_back

which should probably be:

    try:
        raise 'catch me'
    except KeyboardInterrupt:
        raise
    except:
        return sys.exc_traceback.tb_frame.f_back


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 10:45

Message:
Logged In: YES 
user_id=6380

I've applied the three patches you supplied.

I agree with Martin that to do this right we'll have to
tread carefully. But please go on!

(No way more of this will find its way into 2.1 though.)

----------------------------------------------------------------------

Comment By: Itamar Shtull-Trauring (itamar)
Date: 2001-03-30 04:54

Message:
Logged In: YES 
user_id=32065

inspect.py should be removed from this list, the use is
correct.

In general, I just submitted this bug so that when people
are editing a module they'll notice these things, since in
some cases only someone who knows the code very well can
know if the "expect:" is needed or not.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-03-30 00:59

Message:
Logged In: YES 
user_id=21627

Can you identify modules where catching everything is
incorrect, and propose changes to correct them. This should
be done one-by-one, with careful analysis in each case, and
may take well months or years to complete.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 10:02:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 02:02:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oiMI-0005qh-00@usw-sf-web3.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 18:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 10:02

Message:
Logged In: YES 
user_id=911

Just to note that the latest fix removes the .capitalize()
from the strftime return value, which I think is correct
since the locale already knows local convention.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-23 03:27

Message:
Logged In: YES 
user_id=31435

Fixed again, by being duller instead of cleverer, in

Lib/calendar.py; new revision: 1.27
Lib/test/test_calendar.py; new revision: 1.3

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 00:01

Message:
Logged In: YES 
user_id=911

Although I agree passing a tuple stuff full of
co-incidental numbers isn't great, unfortunately, the
suggestion of (2001, 1, i+1, 12, 0, 0, i, i+1, 0) is
definitely wrong.

I think it should be (2001, item, 1, 12, 0, 0, item,
1, 0) and have attached calendar.patch which is
against latest CVS.

I'd guess that it was originally (item,) * 9 so
_localized_name could be used for anything.  It only
ended up being used for week and month names so item
should only appear twice in the tuple.

Also, Tim's suggestion made every month name the same,
e.g. `January'.  Plus it added one to item for the
month, yet the original just used plain item.

I've altered test_calendar.py to check that one week
day name doesn't match another, and the same for month
names.  But I've not written Python before so please
check carefully.

Lastly, _localized_name looks well dodgy to me.  It
only takes a len yet week day names are zero-based and
month names one-based!  Observe.

>>> ','.join(day_name[:])
'Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday'
>>> ','.join(day_abbr[:])
'Mon,Tue,Wed,Thu,Fri,Sat,Sun'

They seem fine.

>>> ','.join(month_name[:])
'Dec,January,February,March,April,May,June,July,August,
    September,October,November,December'
>>> ','.join(month_abbr[:])
'Saturday,Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec'

But accessing an invalid index 0 happens to give a
random string on this system, but could easily core
dump on another.

It seems _localized_name needs knowledge of the
minimum legal index too.  How well that maps onto the
Pythonic `negative index is relative to end' I don't
know.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 18:36

Message:
Logged In: YES 
user_id=44345

reclosing - thanks for the better fix (v. 1.26)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 18:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 18:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 16:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 15:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 12:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 18:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 10:19:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 02:19:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-533234 ] tm_isdst > 1 Passed to strftime.
Message-ID: <E16oicT-0005gy-00@usw-sf-web1.sourceforge.net>

Bugs item #533234, was opened at 2002-03-21 13:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Skip Montanaro (montanaro)
Summary: tm_isdst > 1 Passed to strftime.

Initial Comment:
README says

    On some Linux systems (those that are not yet
    using glibc 6), test_strftime fails due to a
    non-standard implementation of strftime() in the C
    library. Please ignore this, or upgrade to glibc
    version 6.

I find test_calendar fails.  As this is before
test_strftime I didn't find the above message for a
while.  I'd guess test_calendar is failing because of
the strftime problem.  Can README be updated to
suggest test_calendar may fail as well for the same
reason.

    % uname -a
    Linux anon 2.0.36 #1 Tue Dec 29 13:11:13 EST 1998 
        i586 unknown
    % ldd /usr/local/src/Python-2.2.1c1/python
        libdl.so.2 => /lib/libdl.so.2
        libpthread.so.0 => /lib/libpthread.so.0
        libutil.so.1 => /lib/libutil.so.1
        libm.so.6 => /lib/libm.so.6 
        libc.so.6 => /lib/libc.so.6
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2
    % rpm -qf /lib/libc.so.6
    glibc-2.0.7-29


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-23 05:19

Message:
Logged In: YES 
user_id=31435

Good eye, Ralph!  I forgot to comment that, but, yes, that 
was the thinking in leaving .capitalize() off.  Trying to 
outguess the platform is just another way of being too 
clever, and users can call .capitalize() themselves if they 
hate what their platform does.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 05:02

Message:
Logged In: YES 
user_id=911

Just to note that the latest fix removes the .capitalize()
from the strftime return value, which I think is correct
since the locale already knows local convention.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:27

Message:
Logged In: YES 
user_id=31435

Fixed again, by being duller instead of cleverer, in

Lib/calendar.py; new revision: 1.27
Lib/test/test_calendar.py; new revision: 1.3

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 19:01

Message:
Logged In: YES 
user_id=911

Although I agree passing a tuple stuff full of
co-incidental numbers isn't great, unfortunately, the
suggestion of (2001, 1, i+1, 12, 0, 0, i, i+1, 0) is
definitely wrong.

I think it should be (2001, item, 1, 12, 0, 0, item,
1, 0) and have attached calendar.patch which is
against latest CVS.

I'd guess that it was originally (item,) * 9 so
_localized_name could be used for anything.  It only
ended up being used for week and month names so item
should only appear twice in the tuple.

Also, Tim's suggestion made every month name the same,
e.g. `January'.  Plus it added one to item for the
month, yet the original just used plain item.

I've altered test_calendar.py to check that one week
day name doesn't match another, and the same for month
names.  But I've not written Python before so please
check carefully.

Lastly, _localized_name looks well dodgy to me.  It
only takes a len yet week day names are zero-based and
month names one-based!  Observe.

>>> ','.join(day_name[:])
'Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday'
>>> ','.join(day_abbr[:])
'Mon,Tue,Wed,Thu,Fri,Sat,Sun'

They seem fine.

>>> ','.join(month_name[:])
'Dec,January,February,March,April,May,June,July,August,
    September,October,November,December'
>>> ','.join(month_abbr[:])
'Saturday,Jan,Feb,Mar,Apr,May,Jun,Jul,Aug,Sep,Oct,Nov,Dec'

But accessing an invalid index 0 happens to give a
random string on this system, but could easily core
dump on another.

It seems _localized_name needs knowledge of the
minimum legal index too.  How well that maps onto the
Pythonic `negative index is relative to end' I don't
know.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 13:36

Message:
Logged In: YES 
user_id=44345

reclosing - thanks for the better fix (v. 1.26)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 13:23

Message:
Logged In: YES 
user_id=31435

I'm reopening this:  passing a vector of nonsense to 
strftime seems likely to break again somewhere else.  2001 
started on a Monday, so I'd rather we passed

(2001, 1, i+1, 12, 0, 0, i, i+1, 0)

Then all the fields are consistent with each other, and 
only a terribly broken strftime() could fail.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 13:08

Message:
Logged In: YES 
user_id=44345

fixed in calendar.py v. 1.25

bugfix candidate.


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 11:53

Message:
Logged In: YES 
user_id=911

Yep, passing a tm_isdst of 0 or -1 works fine.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-22 10:29

Message:
Logged In: YES 
user_id=44345

Ralph,

Thanks, that helps a lot.  Can you try changing the
strftime link in calendar.py:_localized_name to

return strftime(self.format, 
(item,)*8+(0,)).capitalize()

and let me know if that cures the problem?


----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 07:04

Message:
Logged In: YES 
user_id=911

PS.  Presumably, your Mandrake glibc doesn't use tm_isdst
without checking its value first?

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 06:57

Message:
Logged In: YES 
user_id=911

Ah, OK, I see I do have glibc 6.  I thought it was a
big jump from 2.0.7 to 6.x.x  :-)

I've tracked the SIGSEGV down further.  In
test_calendar.py there's

    self.assertEqual(len([d for d in calendar.day_abbr]), 7)

This SEGVs when d = 2.  For d of 0 and 1 it correctly
retrieves "Mon", "Tue".

calendar.py does

    return strftime(self.format, (item,)*9).capitalize()

constructing a struct tm structure on the fly with
that tuple.  Unfortunately, glibc's time/strftime.c
uses tm_isdst as an index into an array.

    # if HAVE_TZSET
      tzset ();
    # endif

      if (!(zone && *zone) && tp->tm_isdst >= 0)
        zone = tzname[tp->tm_isdst];

On this system tzname is really __tzname.

    (gdb) p __tzname
    $2 = {0x400d91d1 "GMT", 0x400d91cd "BST"}

Boom!

Elsewhere, glibc checks that tm_isdst is 0 or 1 before 
using it as an index, so this is probably a glibc bug.  
However, it makes little sense to pass in a value of 
tm_isdst that happens to match the day of the week so
I'd suggest passing in -1 instead since values < 0 are
used to indicate `unknown'.

If calendar.py doesn't change then README still needs
to say that test_calendar and test_strftime fail in
this situation.


----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-21 13:51

Message:
Logged In: YES 
user_id=44345

It's not clear to me that the README warning here is
correct.  I believe you *are* running glibc 6.  (Note
the '6' in libc.so.6.)  I have similar version numbers on
my Mandrake system which does have glibc 6.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533234&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:19:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:19:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes
Message-ID: <E16orzK-0006lb-00@usw-sf-web2.sourceforge.net>

Bugs item #534108, was opened at 2002-03-23 20:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX 3.2.5 Has No chroot/fsync Prototypes

Initial Comment:
`make' fails for Python-2.2.1c1 under AIX 3.2.5 due to
lack of prototypes for chroot and fsync in
Modules/posixmodule.c.  configure.in uses
AC_CHECK_FUNCS to check these two can be linked into
an executable, and configure correctly determines they
can.

    $ egrep 'chroot|fsync' config.cache
    ac_cv_func_chroot=${ac_cv_func_chroot='yes'}
    ac_cv_func_fsync=${ac_cv_func_fsync='yes'}
   
However, AC_CHECK_FUNCS essentially compiles and links

    #include "confdefs.h"
    #include <assert.h>
    char chroot();
    int main() {
    chroot();
    ; return 0; }
    
which under AIX 3.2.5 works fine.  But chroot isn't
prototyped in *any* system include file, nor is fsync.
Consequently, Modules/posixmodule.c has problems when
it attempts to use both chroot and fsync as an rvalue
for a pointer to a function.

    return posix_1str(args, "et:chroot", chroot);
    return posix_int(args, "i:fsync", fsync);
    
Both lines cause `Undeclared identifier' errors.
    
The solution is to conditionally add prototypes for
these two functions.  Modules/posixmodule.c has an
icky set of conditional prototypes at the start but 
they rely heavily on __IBMC__, __sun__, etc,
preprocessor symbols.  These could be expanded to
cover AIX 3.2.5's case but it may be better to use
autoconf's AC_CHECK_DECLS macro,
http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52.

By manually adding two prototypes at the start of the
source file I've confirmed the source file builds
successfully.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:26:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:26:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-534113 ] missing "is" in "sys.exit" doc string
Message-ID: <E16os5w-0003oN-00@usw-sf-web1.sourceforge.net>

Bugs item #534113, was opened at 2002-03-23 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534113&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Berthold Höllmann (hoel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: missing "is" in "sys.exit" doc string

Initial Comment:
calling 

>>> help (sys.exit)

gives:

exit(...)
    exit([status])
    
    Exit the interpreter by raising SystemExit(status).
    If the status is omitted or None, it defaults to
zero (i.e., success).
    If the status numeric, it will be used as the
system exit status.
    If it is another kind of object, it will be printed
and the system
    exit status will be one (i.e., failure).

I think the line on numeric argument should read:

If the status is numeric, it will be used as the system
exit status.

greetings

Berthold Höllmann

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534113&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:42:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:42:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-534116 ] Python-2.*.exe has virus?
Message-ID: <E16osLo-000711-00@usw-sf-web2.sourceforge.net>

Bugs item #534116, was opened at 2002-03-23 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470

Category: Installation
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: joth tupper (joth3)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python-2.*.exe has virus?

Initial Comment:
Two files within the Windows installation files Python-
2.2.exe and Python-2.1.2.exe downloaded from 
www.python.org show as infected with the same virus.  
I have not run the install, by the way.

GENINDEX.HTML
MODULE-XMLLIB.HTML

The files are identified as infected with VBS.NewLoveA 
according to Norton Anti-Virus v.5.01.03 for Windows 
(95/98) using (ancient) virus definitions dated 
5/18/2000.

I am currently downloading Python-2.2.exe from 
SourceForge.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:44:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:44:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-526357 ] cmd.py does not flush stdout
Message-ID: <E16osNA-0007Pk-00@usw-sf-web4.sourceforge.net>

Bugs item #526357, was opened at 2002-03-06 12:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526357&group_id=5470

Category: Python Library
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jonathan Gardner (jgardn)
Assigned to: Neil Schemenauer (nascheme)
Summary: cmd.py does not flush stdout

Initial Comment:
The module cmd (located in cmd.py in the library) does not flush stdout 
before it waits for input.

What does that mean? That means that unless you are running cmd 
from the terminal, or unless stdout happens to magically flush before it 
waits for new input, that there will be no data written to stdout before it 
waits for input.

This is a problem if you want to fork() a module that uses cmd, or set it 
up to work with sockets as stdout and stdin.

When running in no_rawinput=1 mode (should that be renamed to 
no_raw_input?) , it executes the following code:

79                    sys.stdout.write(self.prompt)
80                    line = sys.stdin.readline()

It should read:

79                    sys.stdout.write(self.prompt)
80                    sys.stdout.flush()
81                    line = sys.stdin.readline(79

There may also be a problem with raw_input(). raw_input should flush 
stdout before asking for input. I'll submit a seperate bug report for that.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 20:44

Message:
Logged In: YES 
user_id=35752

Fixed in cmd.py 1.27.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-06 13:49

Message:
Logged In: YES 
user_id=6380

Might it have occurred to you that you're the first person
ever who's using cmd in a situation where it's not talking
directly to a real human user? I agree that this should
probably be fixed, but it's got low priority compared to
many other bugs.

PS. The convention is that if you have a fix for a bug, you
submit a patch, not a bug report. And please use context
diffs in attachments, never out the patch in the initial bug
description.

----------------------------------------------------------------------

Comment By: Jonathan Gardner (jgardn)
Date: 2002-03-06 12:51

Message:
Logged In: YES 
user_id=126343

no_rawinput should be use_rawinput.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=526357&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:46:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:46:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-534113 ] missing "is" in "sys.exit" doc string
Message-ID: <E16osPe-0007RQ-00@usw-sf-web4.sourceforge.net>

Bugs item #534113, was opened at 2002-03-23 20:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534113&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Berthold Höllmann (hoel)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: missing "is" in "sys.exit" doc string

Initial Comment:
calling 

>>> help (sys.exit)

gives:

exit(...)
    exit([status])
    
    Exit the interpreter by raising SystemExit(status).
    If the status is omitted or None, it defaults to
zero (i.e., success).
    If the status numeric, it will be used as the
system exit status.
    If it is another kind of object, it will be printed
and the system
    exit status will be one (i.e., failure).

I think the line on numeric argument should read:

If the status is numeric, it will be used as the system
exit status.

greetings

Berthold Höllmann

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 20:46

Message:
Logged In: YES 
user_id=35752

Fixed in sysmodule.c 2.102.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534113&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:51:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:51:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-518076 ] Error in tutorial chapter 4
Message-ID: <E16osTw-0007Uq-00@usw-sf-web4.sourceforge.net>

Bugs item #518076, was opened at 2002-02-15 18:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518076&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matt Behrens (mattbehrens)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in tutorial chapter 4

Initial Comment:
Tutorial, 4.7.4, paragraph 1.  Paragraph claims lambda
function adds a+b when it is actually an incrementor.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 20:51

Message:
Logged In: YES 
user_id=35752

This has either already been fixed or the documentation
was correct.  The lambda function is "lambda a, b: a+b"
and the documentation says it returns the sum of its two
arguments.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518076&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 20:57:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 12:57:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-523833 ] Inaccuracy in PyErr_SetFromErrno()'s doc
Message-ID: <E16osa2-00048l-00@usw-sf-web1.sourceforge.net>

Bugs item #523833, was opened at 2002-02-28 13:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523833&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: Inaccuracy in PyErr_SetFromErrno()'s doc

Initial Comment:
Python 2.1 and 2.2 documentations (file
api/exceptionHandling.html) about PyErr_SetFromErrno
say:

[...] a wrapper function around a system call can write
"return PyErr_SetFromErrno();" when the system call
returns an error.

but this function's prototype is:

   PyObject* PyErr_SetFromErrno(PyObject *type)

therefore, I would prefer something like:

[...] a wrapper function around a system call can write
"return PyErr_SetFromErrno(type);" when the system call
returns an error.

(or PyErr_SetFromErrno(exc_type) or whatever you want
provided the function is called with its argument)

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 20:57

Message:
Logged In: YES 
user_id=35752

Fixed in exceptions.tex 1.4.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=523833&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 21:08:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 13:08:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-534116 ] Python-2.*.exe has virus?
Message-ID: <E16osk9-0004Fa-00@usw-sf-web1.sourceforge.net>

Bugs item #534116, was opened at 2002-03-23 15:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470

Category: Installation
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: joth tupper (joth3)
>Assigned to: Tim Peters (tim_one)
Summary: Python-2.*.exe has virus?

Initial Comment:
Two files within the Windows installation files Python-
2.2.exe and Python-2.1.2.exe downloaded from 
www.python.org show as infected with the same virus.  
I have not run the install, by the way.

GENINDEX.HTML
MODULE-XMLLIB.HTML

The files are identified as infected with VBS.NewLoveA 
according to Norton Anti-Virus v.5.01.03 for Windows 
(95/98) using (ancient) virus definitions dated 
5/18/2000.

I am currently downloading Python-2.2.exe from 
SourceForge.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-23 16:08

Message:
Logged In: YES 
user_id=31435

NAV 6.10.24 on Win98 with more recent definitions detects 
no viruses.  These are plain HTML files, and don't contain 
any script (let alone VBScript), so the threat here is 
simply non-existent.  Closing this as a NAV bug (not the 
first, and won't be the last <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 21:21:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 13:21:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E16osxF-0007R9-00@usw-sf-web2.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 21:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 21:21

Message:
Logged In: YES 
user_id=35752

Attached is a first stab at documentation.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:27

Message:
Logged In: YES 
user_id=35752

Okay, I moved unquote to a method of str.  I also fixed
pickle.py and the tests (no need to test for insecure
strings).

Fred, do you have to time to write documentation for 
_PyString_Unquote and str.unquote?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 19:12

Message:
Logged In: YES 
user_id=31435

I haven't tried the patch, but yes, it looks sane to me.  A 
deprecated module is definitely a poor place to add a new 
feature <wink>; it makes as much sense as a string method 
as, say, .upper(), right?  That is, why not?  String in, 
string out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-16 01:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 21:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 23:19:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 15:19:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes
Message-ID: <E16ounM-0000Eb-00@usw-sf-web2.sourceforge.net>

Bugs item #534108, was opened at 2002-03-23 20:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
>Assigned to: Michael Hudson (mwh)
Summary: AIX 3.2.5 Has No chroot/fsync Prototypes

Initial Comment:
`make' fails for Python-2.2.1c1 under AIX 3.2.5 due to
lack of prototypes for chroot and fsync in
Modules/posixmodule.c.  configure.in uses
AC_CHECK_FUNCS to check these two can be linked into
an executable, and configure correctly determines they
can.

    $ egrep 'chroot|fsync' config.cache
    ac_cv_func_chroot=${ac_cv_func_chroot='yes'}
    ac_cv_func_fsync=${ac_cv_func_fsync='yes'}
   
However, AC_CHECK_FUNCS essentially compiles and links

    #include "confdefs.h"
    #include <assert.h>
    char chroot();
    int main() {
    chroot();
    ; return 0; }
    
which under AIX 3.2.5 works fine.  But chroot isn't
prototyped in *any* system include file, nor is fsync.
Consequently, Modules/posixmodule.c has problems when
it attempts to use both chroot and fsync as an rvalue
for a pointer to a function.

    return posix_1str(args, "et:chroot", chroot);
    return posix_int(args, "i:fsync", fsync);
    
Both lines cause `Undeclared identifier' errors.
    
The solution is to conditionally add prototypes for
these two functions.  Modules/posixmodule.c has an
icky set of conditional prototypes at the start but 
they rely heavily on __IBMC__, __sun__, etc,
preprocessor symbols.  These could be expanded to
cover AIX 3.2.5's case but it may be better to use
autoconf's AC_CHECK_DECLS macro,
http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52.

By manually adding two prototypes at the start of the
source file I've confirmed the source file builds
successfully.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 23:31:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 15:31:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16ouyY-0005lb-00@usw-sf-web1.sourceforge.net>

Bugs item #534153, was opened at 2002-03-23 23:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Nobody/Anonymous (nobody)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470


From noreply@sourceforge.net  Sat Mar 23 23:37:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 15:37:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-534158 ] Running MacPython as non-priv user may fail
Message-ID: <E16ov4g-0005pi-00@usw-sf-web1.sourceforge.net>

Bugs item #534158, was opened at 2002-03-24 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Running MacPython as non-priv user may fail

Initial Comment:
Running Python (especially the IDE, but possibly also the interpreter from a non-standard place)on OSX as a non-privileged user if you've previously installed it system-wide (as a privileged user) may not work the first time. In some cases it will start to work automatically, in other cases you have to throw away the (per-user) preferences file.

At the very least we need to warn for this in the README.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 00:34:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 16:34:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-534116 ] Python-2.*.exe has virus?
Message-ID: <E16ovxz-0006cX-00@usw-sf-web3.sourceforge.net>

Bugs item #534116, was opened at 2002-03-23 12:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470

Category: Installation
Group: 3rd Party
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: joth tupper (joth3)
Assigned to: Tim Peters (tim_one)
Summary: Python-2.*.exe has virus?

Initial Comment:
Two files within the Windows installation files Python-
2.2.exe and Python-2.1.2.exe downloaded from 
www.python.org show as infected with the same virus.  
I have not run the install, by the way.

GENINDEX.HTML
MODULE-XMLLIB.HTML

The files are identified as infected with VBS.NewLoveA 
according to Norton Anti-Virus v.5.01.03 for Windows 
(95/98) using (ancient) virus definitions dated 
5/18/2000.

I am currently downloading Python-2.2.exe from 
SourceForge.

----------------------------------------------------------------------

>Comment By: joth tupper (joth3)
Date: 2002-03-23 16:34

Message:
Logged In: YES 
user_id=494718

Thanks, Tim.  I was hoping it was a false positive.
Prior to submitting the bug report, I did do a search 
for "virus" and turned up no hits.  

Were there prior postings of this NAV bug?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-23 13:08

Message:
Logged In: YES 
user_id=31435

NAV 6.10.24 on Win98 with more recent definitions detects 
no viruses.  These are plain HTML files, and don't contain 
any script (let alone VBScript), so the threat here is 
simply non-existent.  Closing this as a NAV bug (not the 
first, and won't be the last <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534116&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 02:03:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 23 Mar 2002 18:03:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-502503 ] pickle interns strings
Message-ID: <E16oxMJ-0002MJ-00@usw-sf-web4.sourceforge.net>

Bugs item #502503, was opened at 2002-01-11 21:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pickle interns strings

Initial Comment:
Pickle (and cPickle) use eval to reconstruct string
variables from the stored format.  Eval is used because
it correctly reconstructs the repr of a string back
into the original string object by translating all the
appropriately escape characters like "\m" and "\n"

There is an side effect in that eval interns string
variables for faster lookup.

This causes the following sample code to unexpectedly
grow in memory consumption:

import pickle
import random
import string

def genstring(length=100):
    s = [random.choice(string.letters) for x in
range(length)]
    return "".join(s)

def test():
    while 1:
        s = genstring()
        dump = pickle.dumps(s)
        s2 = pickle.loads(dump)
        assert s == s2

test()

Note that all strings are not interned, just ones that,
as Tim Peters once said, "look like", variable names. 
The above example is contrived to generate a lot of
different names that "look like" variables names but
since this has happened in practice it probably should
documented.

Interestingly, by inserting
 s.append(" ")
before
 return "".join(s)

The memory consumption is not seen because the names no
longer "look like" variable names.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-24 02:03

Message:
Logged In: YES 
user_id=35752

See patch 505705 for a slightly different solution.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-23 21:21

Message:
Logged In: YES 
user_id=35752

Attached is a first stab at documentation.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 20:27

Message:
Logged In: YES 
user_id=35752

Okay, I moved unquote to a method of str.  I also fixed
pickle.py and the tests (no need to test for insecure
strings).

Fred, do you have to time to write documentation for 
_PyString_Unquote and str.unquote?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 19:12

Message:
Logged In: YES 
user_id=31435

I haven't tried the patch, but yes, it looks sane to me.  A 
deprecated module is definitely a poor place to add a new 
feature <wink>; it makes as much sense as a string method 
as, say, .upper(), right?  That is, why not?  String in, 
string out.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 18:35

Message:
Logged In: YES 
user_id=35752

Attached is a patch that implements _PyString_Unquote
and strop.unquote.  strop is probably the wrong place since
it's deprecated but I'm not sure if unquote as a string method
is right either.  cPickle.c is changed to use
_PyString_Unquote instead of calling eval.  pickle.py
still needs to be fixed, documentation added, tests fixed.
Before all that, does this patch look sane?

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2002-02-16 01:26

Message:
Logged In: YES 
user_id=72053

I agree about eval being dangerous.  Also, the memory leak
is itself a security concern: if an attacker can stuff
enough strings into the unpickler to exhaust memory, that's
a denial of service attack.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-11 21:36

Message:
Logged In: YES 
user_id=31435

Noting that Security Geeks are uncomfortable with using eval
() for this purpose regardless.  Would be good if Python 
got refactored so that pickle and cPickle and the front end 
all called a new routine that simply parsed the escape 
sequences in a character buffer, returning a Python string 
object.

Don't ask me about Unicode <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502503&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 15:00:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 07:00:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16p9UP-0000Q6-00@usw-sf-web3.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2002-03-24 15:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 16:30:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 08:30:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-534347 ] Potential AV in vgetargskeywords
Message-ID: <E16pAsl-0004BG-00@usw-sf-web4.sourceforge.net>

Bugs item #534347, was opened at 2002-03-24 07:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential AV in vgetargskeywords

Initial Comment:
If you are dumb enough to do what I just did, pass a 
dictionary with non-string keys to 
PyEval_CallObjectWithKeyWords, you may cause an access 
violation in Python (if the call ends up going through 
PyArg_ParseTupleAndKeywords).  The problem is in the 
section of vgetargskeywords which checks for 
extraneous keyword arguments: it does not check to 
make sure PyString_AsString(key) succeeded.  Attached 
is a simple patch.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 16:42:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 08:42:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-210715 ] Segmentation fault with kernel 2.2.12 (PR#103)
Message-ID: <E16pB4O-0001D0-00@usw-sf-web3.sourceforge.net>

Bugs item #210715, was opened at 2000-07-31 16:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210715&group_id=5470

Category: None
Group: Irreproducible
Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault with kernel 2.2.12 (PR#103)

Initial Comment:
Jitterbug-Id: 103
Submitted-By: apsteffe@netwood.net
Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT)
Version: 1.5.2
OS: Linux


I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
 execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
The functions work ok with kernel 1.2.13 .



====================================================================
Audit trail:
Mon Oct 18 18:08:00 1999	guido	changed notes
Mon Oct 18 18:08:00 1999	guido	changed notification
Mon Oct 18 18:08:00 1999	guido	moved from incoming to irreproducible

----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-24 10:42

Message:
Logged In: YES 
user_id=44345

outdated - references 1.5.2 and old versions of gcc
and glibc

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-08-01 16:27

Message:
test bug from Jitterbug -> SF conversion

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210715&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 17:55:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 09:55:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-210715 ] Segmentation fault with kernel 2.2.12 (PR#103)
Message-ID: <E16pCDR-0004oZ-00@usw-sf-web4.sourceforge.net>

Bugs item #210715, was opened at 2000-07-31 17:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210715&group_id=5470

>Category: None
>Group: 3rd Party
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault with kernel 2.2.12 (PR#103)

Initial Comment:
Jitterbug-Id: 103
Submitted-By: apsteffe@netwood.net
Date: Mon, 11 Oct 1999 22:21:00 -0400 (EDT)
Version: 1.5.2
OS: Linux


I'm using glibc 2.0.6 and kernel 2.2.12 and gcc-2.7.2.1 .  When I try to
 execute httplib.HTTP() or urllib.urlretrieve() I get a segmentation fault.
The functions work ok with kernel 1.2.13 .



====================================================================
Audit trail:
Mon Oct 18 18:08:00 1999	guido	changed notes
Mon Oct 18 18:08:00 1999	guido	changed notification
Mon Oct 18 18:08:00 1999	guido	moved from incoming to irreproducible

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-24 12:55

Message:
Logged In: YES 
user_id=31435

Closed as 3rd-Party and Fixed:  no info was added to this 
bug in more than 2 years, the original report said it 
depended on which kernel was in use, and AFAICT the problem 
was never reported again.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-24 11:42

Message:
Logged In: YES 
user_id=44345

outdated - references 1.5.2 and old versions of gcc
and glibc

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2000-08-01 17:27

Message:
test bug from Jitterbug -> SF conversion

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=210715&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 19:26:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 11:26:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-480215 ] softspace confused in nested print
Message-ID: <E16pDdm-00024i-00@usw-sf-web1.sourceforge.net>

Bugs item #480215, was opened at 2001-11-09 17:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&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: softspace confused in nested print

Initial Comment:
Adapted from a c.l.py report:

class C:
.   def __str__(self):
.       print "a"
.       return "b"
print C()

The output is " a\nb\n" -- note the surprising leading 
space.  This is because PRINT_ITEM forces softspace to 
1 *before* converting the output item (so softspace is 
1 when we get into __str__, despite that nothing yet 
has been written).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-24 14:26

Message:
Logged In: YES 
user_id=31435

Fixed, in

Lib/test/test_softspace.py; new file
Python/ceval.c; new revision: 2.308

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-01-25 12:48

Message:
Logged In: YES 
user_id=31435

It should be easier to fix than to argue about, yes.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-25 09:09

Message:
Logged In: YES 
user_id=6380

But there's an easy fix for this one, right?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-01-25 05:14

Message:
Logged In: YES 
user_id=6656

In my bid to reduce the number of unassigned bugs I say: so
what?

print is magical, maybe too magical, but I thought the
consensus was that it's not worth changing.  Having
side-effects in __str__ methods is gross anyway.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=480215&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 21:41:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 13:41:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16pFkT-0006RM-00@usw-sf-web4.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 16:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 10:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 21:54:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 13:54:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16pFwo-0003Vk-00@usw-sf-web3.sourceforge.net>

Bugs item #534153, was opened at 2002-03-24 00:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
>Assigned to: Martin v. Löwis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470


From noreply@sourceforge.net  Sun Mar 24 22:23:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 14:23:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-510910 ] File inheritance across exec/spawn
Message-ID: <E16pGOb-0003iP-00@usw-sf-web3.sourceforge.net>

Bugs item #510910, was opened at 2002-01-30 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Neil Schemenauer (nascheme)
Summary: File inheritance across exec/spawn

Initial Comment:
For 2.3, I added a new tempfile.TemporaryFile 
implementation for Windows that (among other good 
things) arranges that spawned processes will no longer 
inherit the temp files' underlying open file 
descriptors.  There are multiple reasons for doing so 
on Windows, and one that's "an issue" across all 
platforms is security.

Temp files may (will, AFAICT) still get inherited on 
other platforms.  And inheriting open files of other 
kinds may still be an issue on all platforms.

Guido sez (from email):

"""
This is exactly what happens on Unix, I'm afraid.  Is
there a way around that?  Across fork(), I think it's 
fair (might be intentional).  Across exec(), I think 
there's no point.  We should use fcntl() with F_SETFD 
to set the FD_CLOEXEC bit.
"""

There is no fork on Windows, so life is simpler there; 
OTOH, there's no FD_CLOEXEC bit on Windows either, so 
life is harder there if we want to extend this to 
other files.  I'm inclined to think we should stick to 
setting policy only for temp files;  *we* create them, 
and the user has no control over how we create them.  
For files the user opens themself, they can get at 
FD_CLOEXEC (on platforms supporting it) from Python.  
They can also get at O_NOINHERIT on Windows in 2.3 
(when using os.open()).

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-24 22:23

Message:
Logged In: YES 
user_id=35752

Fixed in tempfile.py 1.38.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 23:16

Message:
Logged In: YES 
user_id=35752

Okay.  I'll take it since I'm a wannabe security geek.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 22:49

Message:
Logged In: YES 
user_id=31435

I expect Guido is suggesting at least that, and since it's 
my bug report <wink> I'd be happy to close it if that much 
is done.  Security Geeks may or may not wish to argue that 
all files opened by Python do likewise, but, if so, they 
can open their bug report.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-22 22:35

Message:
Logged In: YES 
user_id=35752

What's the bug here?  I'm guessing that Guido is suggesting
that TemporaryFile set the FD_CLOEXEC.  Is that right?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510910&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 00:24:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 16:24:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16pIHP-0007zG-00@usw-sf-web4.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 1
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 19:24

Message:
Logged In: YES 
user_id=248775

Guido - 

Thanks for your attention to my report.

Another bit of suprise with operator overriding
in a subclass of complex:
  
from __future__ import division
class Complex(complex):
    def __div__(self,other):
        t=complex.__div__(self,other)       
        return Complex(t.real,t.imag)
a=Complex(5,4)
b=Complex(1,7)

>> <type 'complex'>

But:

everything the same *without* calling
from __future__ import division  

print type(a/b)
>><class '__main__.Complex'>

Based your analysis of the previous
issue(which I follow only
in broad outline), I have a sense of 
what's happening.   

My general sense, though, is that this issue
is in some sense more of a problem than
the other.

Don't think anyone will expect a change in
behavior here based on the from __future__
call.  Not that subbing complex is a common pursuit -
but couldn't this actually break working code
in a very unanticpated way, eventually.

Obviously not a big issue if the other changes
you see happening with complex coercian kick in
first, and in fact those changes - as I suspect - 
would prevent a different return type based
on which way int/int is toggled.

Art  

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=6380

It seems that * is the exception -- all other operators (+,
-, /, **) return the type of the left operand.  It gets even
weirder if we change the left operand from 7 to 7.0 -- then
* is no longer an exception and returns a complex like all
other operators!

The weirdness is in int_mul. If the right argument is not an
int but a sequence that implements the sq_repeat slot, it
invokes that. But if you create a class that defines
__mul__, that implements the sequence repeat slot! (Python
doesn't know if you intend to implement a seqence or a
number, when you define a __mul__ method, so it maps both
the nb_multiply and the sq_repeat slots to the __mul__
method).

So 7 + Complex() takes the path through int_mul that calls
the Complex.__mul__ , and that's why you get a Complex value
back. Floats can't be used in the sequence repeat operator,
so its multiply is "normal".

But wait...! There's another mystery. Ints don't know how to
add themselves to complex numbers! So why wouldn't
7+Complex() use the normal pattern of (a) try the left
operand, (b) if that returns NotImplemented, try the right
operand? The answer is that complex numbers implement
coercion! And in that case, step (b) is modified to (b) ask
either operand to perform a coercion, and if it succeeds,
ask the left operand of the resulting coerced pair to
perform the operation. So complex coerces the int to a plain
complex, and then invokes the plain complex's add/mul/etc.
operation.

Solution: add the following to your Complex class:

    def __coerce__(self, other):
        x = complex.__coerce__(self, other)
        if x is NotImplemented:
            return x
        a, b = x
        return Complex(a), Complex(b)

I don't think I want to do anything to fix this, although I
think I'll pass it on to Fred for documentation (not that I
expect him to be in a hurry to fix it either, given the
subtlety of the issues).

In the long run, I think complex should stop using coercion
and start behaving like a "new-style" number like all the
other numeric types. That should fix the second mystery.

Also, in the long run, the sq_repeat and sq_concat slots
should be deprecated and instead sequences should implement
multiply and add operations. Then the funny business in
int_mul could be taken out and the first mystery would
disappear.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 01:11:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 17:11:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16pJ1K-0005WN-00@usw-sf-web3.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 1
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 20:11

Message:
Logged In: YES 
user_id=248775

Have just re-read my submission - and
in addition to my usual quota of typos
I see I left out something that could 
confuse what I am trying to bring to 
your attention.

The gist, I am sure you will see, is that
type(a/b), where a and b are of a class derived
from complex, will change based on whether
from __future__ import division is or is not
called.

And I am assuming that behavior is unanticipated.

And I assuming there is no reason to submit this a
a bug report separate from this thread.

Art

----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 19:24

Message:
Logged In: YES 
user_id=248775

Guido - 

Thanks for your attention to my report.

Another bit of suprise with operator overriding
in a subclass of complex:
  
from __future__ import division
class Complex(complex):
    def __div__(self,other):
        t=complex.__div__(self,other)       
        return Complex(t.real,t.imag)
a=Complex(5,4)
b=Complex(1,7)

>> <type 'complex'>

But:

everything the same *without* calling
from __future__ import division  

print type(a/b)
>><class '__main__.Complex'>

Based your analysis of the previous
issue(which I follow only
in broad outline), I have a sense of 
what's happening.   

My general sense, though, is that this issue
is in some sense more of a problem than
the other.

Don't think anyone will expect a change in
behavior here based on the from __future__
call.  Not that subbing complex is a common pursuit -
but couldn't this actually break working code
in a very unanticpated way, eventually.

Obviously not a big issue if the other changes
you see happening with complex coercian kick in
first, and in fact those changes - as I suspect - 
would prevent a different return type based
on which way int/int is toggled.

Art  

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=6380

It seems that * is the exception -- all other operators (+,
-, /, **) return the type of the left operand.  It gets even
weirder if we change the left operand from 7 to 7.0 -- then
* is no longer an exception and returns a complex like all
other operators!

The weirdness is in int_mul. If the right argument is not an
int but a sequence that implements the sq_repeat slot, it
invokes that. But if you create a class that defines
__mul__, that implements the sequence repeat slot! (Python
doesn't know if you intend to implement a seqence or a
number, when you define a __mul__ method, so it maps both
the nb_multiply and the sq_repeat slots to the __mul__
method).

So 7 + Complex() takes the path through int_mul that calls
the Complex.__mul__ , and that's why you get a Complex value
back. Floats can't be used in the sequence repeat operator,
so its multiply is "normal".

But wait...! There's another mystery. Ints don't know how to
add themselves to complex numbers! So why wouldn't
7+Complex() use the normal pattern of (a) try the left
operand, (b) if that returns NotImplemented, try the right
operand? The answer is that complex numbers implement
coercion! And in that case, step (b) is modified to (b) ask
either operand to perform a coercion, and if it succeeds,
ask the left operand of the resulting coerced pair to
perform the operation. So complex coerces the int to a plain
complex, and then invokes the plain complex's add/mul/etc.
operation.

Solution: add the following to your Complex class:

    def __coerce__(self, other):
        x = complex.__coerce__(self, other)
        if x is NotImplemented:
            return x
        a, b = x
        return Complex(a), Complex(b)

I don't think I want to do anything to fix this, although I
think I'll pass it on to Fred for documentation (not that I
expect him to be in a hurry to fix it either, given the
subtlety of the issues).

In the long run, I think complex should stop using coercion
and start behaving like a "new-style" number like all the
other numeric types. That should fix the second mystery.

Also, in the long run, the sq_repeat and sq_concat slots
should be deprecated and instead sequences should implement
multiply and add operations. Then the funny business in
int_mul could be taken out and the first mystery would
disappear.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 01:42:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 24 Mar 2002 17:42:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-534495 ] PyErr_Format format char bugs
Message-ID: <E16pJVa-0008Tc-00@usw-sf-web2.sourceforge.net>

Bugs item #534495, was opened at 2002-03-24 19:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyErr_Format format char bugs

Initial Comment:
The API docs for PyErr_Format have a slight typo
(I think) and are missing a table entry for the 'p'
format character.  I think the attached patch
corrects that, though since I don't use this
function much, I'm not sure (hence the bug report
instead of just checking in what looks like a 
trivial change).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 08:43:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 00:43:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16pQ52-0001Ee-00@usw-sf-web1.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 15:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

>Comment By: Peter Harris (scav)
Date: 2002-03-25 08:43

Message:
Logged In: YES 
user_id=8911

Thanks all.

I am using the HP-UX ANSI C compiler (cc -Ae).

Recompiling longobject.c without optimisations worked OK, 
so I'm content.

If no similar problems emerge, I'll not need to learn how 
to use the debugger (adb, which I find fairly daunting!)

Peter

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:58

Message:
Logged In: YES 
user_id=31435

Peter, no, there have been no other reports of this on 64-
bit platforms.  If possible, try recompiling longobject.c 
with optimization disabled.  Its internal long_format() 
routine is complicated so has a better-than-usual chance of 
provoking bad code generation. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:29

Message:
Logged In: YES 
user_id=21627

Can you please also report which compiler you have been using?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:29

Message:
Logged In: YES 
user_id=21627

Can you use a debugger to find out and report where it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 10:32:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 02:32:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-534613 ] urllib.unquote() is not idempotent
Message-ID: <E16pRmL-0005v2-00@usw-sf-web4.sourceforge.net>

Bugs item #534613, was opened at 2002-03-25 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.unquote() is not idempotent

Initial Comment:
There are URLs s, where

unquote(unquote(s)) != unquote(s)

I.e. unquote sometimes does not complete its task. Example (real world):

s = 
'/r?ck_sm=765ea975&ref=20096&r=http%3A%2F%2Fwww.altavista.com%2Fsites%2Fsearch%2Fmm
_resultframe%3Fq%3Dbike%26type%3DIMG%26url%3Dhttp%253A%252F%252Fvmesa17.u-3mrs.fr
%253A10081%252F%257Em9402001%252Fbike.htm%26title%3Dbike_1.jpg%26isrc%3Dhttp%253A
%252F%252Fthumb-1.image.altavista.com%252Fimage%252F49909424%26src%3Dhttp%253A%25
2F%252Fvmesa17.u-3mrs.fr%253A10081%252F%257Em9402001%252Fbike_1.jpg%26stq%3D50%2
6stype%3Dsimage'

unquote(s) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike.htm&titl
e=bike_1.jpg&isrc=http%3A%2F%2Fthumb-1.image.altavista.com%2Fimage%2F49909424&src=http
%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike_1.jpg&stq=50&stype=simage
'
unquote(unquote(s)) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http://vmesa17.u-3mrs.fr:10081/~m9402001/bike.htm&title=bike_1.jpg&isrc=http:
//thumb-1.image.altavista.com/image/49909424&src=http://vmesa17.u-3mrs.fr:10081/~m9402001/
bike_1.jpg&stq=50&stype=simage'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 10:45:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 02:45:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-534613 ] urllib.unquote() is not idempotent
Message-ID: <E16pRyV-0005kn-00@usw-sf-web2.sourceforge.net>

Bugs item #534613, was opened at 2002-03-25 11:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.unquote() is not idempotent

Initial Comment:
There are URLs s, where

unquote(unquote(s)) != unquote(s)

I.e. unquote sometimes does not complete its task. Example (real world):

s = 
'/r?ck_sm=765ea975&ref=20096&r=http%3A%2F%2Fwww.altavista.com%2Fsites%2Fsearch%2Fmm
_resultframe%3Fq%3Dbike%26type%3DIMG%26url%3Dhttp%253A%252F%252Fvmesa17.u-3mrs.fr
%253A10081%252F%257Em9402001%252Fbike.htm%26title%3Dbike_1.jpg%26isrc%3Dhttp%253A
%252F%252Fthumb-1.image.altavista.com%252Fimage%252F49909424%26src%3Dhttp%253A%25
2F%252Fvmesa17.u-3mrs.fr%253A10081%252F%257Em9402001%252Fbike_1.jpg%26stq%3D50%2
6stype%3Dsimage'

unquote(s) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike.htm&titl
e=bike_1.jpg&isrc=http%3A%2F%2Fthumb-1.image.altavista.com%2Fimage%2F49909424&src=http
%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike_1.jpg&stq=50&stype=simage
'
unquote(unquote(s)) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http://vmesa17.u-3mrs.fr:10081/~m9402001/bike.htm&title=bike_1.jpg&isrc=http:
//thumb-1.image.altavista.com/image/49909424&src=http://vmesa17.u-3mrs.fr:10081/~m9402001/
bike_1.jpg&stq=50&stype=simage'


----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-25 11:45

Message:
Logged In: YES 
user_id=43607

What makes you think that urllib.unquote *should* be idempotent?
The whole reason for unquote is to remove the %-escapes from a URL, and this *cannot* be idempotent.

I would say "Not a bug".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 11:08:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 03:08:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-534625 ] ftplib hangs: ftp=FTP('ftp.example.com')
Message-ID: <E16pSLO-0006J5-00@usw-sf-web4.sourceforge.net>

Bugs item #534625, was opened at 2002-03-25 12:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Pascal Oberndörfer (oberndoerfer)
Assigned to: Jack Jansen (jackjansen)
Summary: ftplib hangs: ftp=FTP('ftp.example.com')

Initial Comment:
Typing the following at the interpreter:

>>> from ftplib import FTP
>>> ftp = FTP('ftp.example.com')

the interpreter hangs.

MacPython 2.2.1c1 on MacOS X 10.1.3


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 12:46:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 04:46:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] install fails if build .so fails
Message-ID: <E16pTsG-0007ER-00@usw-sf-web2.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
>Summary: install fails if build .so fails

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 07:46

Message:
Logged In: YES 
user_id=33168

Changed the subject to more closely describe the problem.
The patch may be more treating the symptom, but I don't know
distutils well enough to know.  There is a big comment which
immediately above the code which seems related, but I'm not
sure how.

I think this patch (or another which fixes the problem)
should be applied to 2.2.1.  Note the problem is not
specific to any particular library or OS.

I'll try to get fpectl to work on Solaris 8, but that is a
different subject to the build/install failure which is the
problem addressed by the patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 04:16

Message:
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-20 19:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 14:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 13:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:26:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:26:41 -0800
Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees
Message-ID: <E16pUUj-00050M-00@usw-sf-web3.sourceforge.net>

Bugs item #534669, was opened at 2002-03-25 13:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: remember to sync trees

Initial Comment:
There are various fixes hitting the trunk that I'm not
considering for 2.2.1 that should probably be
considered for 2.2.2 if that ever happens.

Conversely there may be a few things I've fixed in the
22-maint branch that haven't been fixed on the trunk.

Don't forget these.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:29:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:29:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16pUX6-00052O-00@usw-sf-web3.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:29

Message:
Logged In: YES 
user_id=6656

I've ported Tim's fix from the trunk.  It will be in 2.2.1c2
which will probably be released tomorrow.

Can this be closed?

> For the moment, I propose to reactivate -lieee 
> for Linux again in 2.2.1.

No chance.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=31435

It would help if you simply tried your example under 2.1 -- 
I don't have your system, and can't try it for you.  It's 
extraordinarily risky making any last-second change to a 
bugfix release, and whether it's an old bug feeds into the 
tradeoff calculation.

Enabling -lieee at the last second isn't something I'll do 
without lots of people swearing it doesn't hurt anything on 
their boxes.  Not all systems act the same way in the 
presence of -lieee.  The change I did make is in our C 
code, where I have a good chance of guessing what various C 
compilers will do; -lieee does whatever a platform feels 
like doing, and there's no standard to constrain it.

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-22 13:53

Message:
Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 19:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:36:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:36:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16pUe9-00057n-00@usw-sf-web3.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:36

Message:
Logged In: YES 
user_id=6656

I'm getting lost.  What action is needed?

The LINKCC thing was fixed, but I forgot to run autoconf
before building the 2.2.1c1 tarball (sorry).

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 00:43

Message:
Logged In: YES 
user_id=911

BTW, the build then halts because 1.295 of configure.in
isn't in the release candidate so LINKCC's definition
in Makefile contains LINKCC and the recursion isn't welcome.
SF bug #477487 apparently.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 21:34

Message:
Logged In: YES 
user_id=911

Replying to a few comments at once...  The C compiler
on AIX comes in many guises.  They are normally all
hard links to the same executable.  /etc/xlc.cfg
defines these identities, so cc_r, if it exists, just
causes a certain set of options to be used.

* extended c compiler aliased as cc_r
cc_r: use        = DEFLT
    crt        = /lib/crt0_r.o
    mcrt       = /lib/mcrt0.o
    gcrt       = /lib/gcrt0.o
    libraries  = -L/usr/lib/dce,-lc_r,-lpthreads
    proflibs   = -L/lib/profiled,-L/usr/lib/profiled
    options    = -H512,-T512,-qlanglvl=extended,
        -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_,
        -qnoroconst

So
http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html
is wrong when it says that you can't use cc with an
appropriate set of options since that's all that cc_r,
cckern, c89, xlc_r, or any of the other hard links
are.

However, not all AIX installations have all bits of
the C compiler available to support all its guises.
So I think it's preferable to use cc_r if it is
available, else fall-back on cc.  And if using cc
hopefully configure's testing for whether threads is
available will determine it isn't.

This is all based on AIX 3, AIX 4 expanded on this in
a few ways.

In summary, I'd agree with donnc `Without cc_r, just
don't enable threads'.  Hopefully, that'll happen
automatically.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 18:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:37:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:37:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-533306 ] not building on AIX
Message-ID: <E16pUeo-00058J-00@usw-sf-web3.sourceforge.net>

Bugs item #533306, was opened at 2002-03-21 21:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Peter Toneby (toneby)
Assigned to: Michael Hudson (mwh)
Summary: not building on AIX

Initial Comment:
Simply due to configure not beeing up to date, running
autoconf solves this. Please run autoconf when making a
distribution.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:37

Message:
Logged In: YES 
user_id=6656

Closing this.  Further problems can go in further reports.

----------------------------------------------------------------------

Comment By: Peter Toneby (toneby)
Date: 2002-03-22 12:14

Message:
Logged In: YES 
user_id=219420

Yes, it does, but I have some other issues that stem from
setup.py, I'm not sure (haven't looked) if it uses the info
configure figured out, But I suppose those should be filed
as another bug (and I have to do a little bit of research
into it), but I've got a mostly working installation now :)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 11:25

Message:
Logged In: YES 
user_id=6656

Oops, you're right.  Fixed in revision 1.279.6.4 of configure.

(usually the practice is to run autoconf whenever a change
is made to configure.in.  it looks like I forgot to do that
this time).

Does everything more-or-less work when you run autoconf?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533306&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:41:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:41:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes
Message-ID: <E16pUj0-0005BP-00@usw-sf-web3.sourceforge.net>

Bugs item #534108, was opened at 2002-03-23 20:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: AIX 3.2.5 Has No chroot/fsync Prototypes

Initial Comment:
`make' fails for Python-2.2.1c1 under AIX 3.2.5 due to
lack of prototypes for chroot and fsync in
Modules/posixmodule.c.  configure.in uses
AC_CHECK_FUNCS to check these two can be linked into
an executable, and configure correctly determines they
can.

    $ egrep 'chroot|fsync' config.cache
    ac_cv_func_chroot=${ac_cv_func_chroot='yes'}
    ac_cv_func_fsync=${ac_cv_func_fsync='yes'}
   
However, AC_CHECK_FUNCS essentially compiles and links

    #include "confdefs.h"
    #include <assert.h>
    char chroot();
    int main() {
    chroot();
    ; return 0; }
    
which under AIX 3.2.5 works fine.  But chroot isn't
prototyped in *any* system include file, nor is fsync.
Consequently, Modules/posixmodule.c has problems when
it attempts to use both chroot and fsync as an rvalue
for a pointer to a function.

    return posix_1str(args, "et:chroot", chroot);
    return posix_int(args, "i:fsync", fsync);
    
Both lines cause `Undeclared identifier' errors.
    
The solution is to conditionally add prototypes for
these two functions.  Modules/posixmodule.c has an
icky set of conditional prototypes at the start but 
they rely heavily on __IBMC__, __sun__, etc,
preprocessor symbols.  These could be expanded to
cover AIX 3.2.5's case but it may be better to use
autoconf's AC_CHECK_DECLS macro,
http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52.

By manually adding two prototypes at the start of the
source file I've confirmed the source file builds
successfully.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:41

Message:
Logged In: YES 
user_id=6656

Hmm, AC_CHECK_DECLS might well be useful (and not just for
these declarations).

However, I'm not an autoconf guru, and really don't want to
have to become one.

Is there a way to identify AIX 3 using the preprocessor?  Or
does AIX 4 not have these prototypes either?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:56:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:56:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] install fails if build .so fails
Message-ID: <E16pUxd-0004qN-00@usw-sf-web1.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 19:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: install fails if build .so fails

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-25 14:56

Message:
Logged In: YES 
user_id=21627

The patch to setup.py itself is fine (although I'm not sure
what the Carbon chunk is doing there). It is not quite clear
to me why it is needed, though: When fpectl.so was first
built, an import was attempted. That import must have
succeeded, or else the built_objects would have been
removed, and 'make install' would have rebuilt them again.

One scenario where this can go wrong is that  Python crashes
during import of the extension module, in which case the
extension remains there, but is not built again. So assuming
something like that happened to you, please apply the patch.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 13:46

Message:
Logged In: YES 
user_id=33168

Changed the subject to more closely describe the problem.
The patch may be more treating the symptom, but I don't know
distutils well enough to know.  There is a big comment which
immediately above the code which seems related, but I'm not
sure how.

I think this patch (or another which fixes the problem)
should be applied to 2.2.1.  Note the problem is not
specific to any particular library or OS.

I'll try to get fpectl to work on Solaris 8, but that is a
different subject to the build/install failure which is the
problem addressed by the patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 10:16

Message:
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 02:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 01:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 19:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 13:58:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 05:58:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16pUzU-0005NH-00@usw-sf-web3.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-25 13:58

Message:
Logged In: YES 
user_id=11850

The bug is indeed old, the behaviour is the same under 2.1.2, as I just checked.

I will try 2.2.1c2 as soon as it is out.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:29

Message:
Logged In: YES 
user_id=6656

I've ported Tim's fix from the trunk.  It will be in 2.2.1c2
which will probably be released tomorrow.

Can this be closed?

> For the moment, I propose to reactivate -lieee 
> for Linux again in 2.2.1.

No chance.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=31435

It would help if you simply tried your example under 2.1 -- 
I don't have your system, and can't try it for you.  It's 
extraordinarily risky making any last-second change to a 
bugfix release, and whether it's an old bug feeds into the 
tradeoff calculation.

Enabling -lieee at the last second isn't something I'll do 
without lots of people swearing it doesn't hurt anything on 
their boxes.  Not all systems act the same way in the 
presence of -lieee.  The change I did make is in our C 
code, where I have a good chance of guessing what various C 
compilers will do; -lieee does whatever a platform feels 
like doing, and there's no standard to constrain it.

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-22 13:53

Message:
Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 02:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 19:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:00:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:00:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] install fails if build .so fails
Message-ID: <E16pV13-0005Od-00@usw-sf-web3.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
Status: Open
>Resolution: Duplicate
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: install fails if build .so fails

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 14:00

Message:
Logged In: YES 
user_id=6656

Hokay, checked in as revision 1.73.4.3 of setup.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-25 13:56

Message:
Logged In: YES 
user_id=21627

The patch to setup.py itself is fine (although I'm not sure
what the Carbon chunk is doing there). It is not quite clear
to me why it is needed, though: When fpectl.so was first
built, an import was attempted. That import must have
succeeded, or else the built_objects would have been
removed, and 'make install' would have rebuilt them again.

One scenario where this can go wrong is that  Python crashes
during import of the extension module, in which case the
extension remains there, but is not built again. So assuming
something like that happened to you, please apply the patch.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 12:46

Message:
Logged In: YES 
user_id=33168

Changed the subject to more closely describe the problem.
The patch may be more treating the symptom, but I don't know
distutils well enough to know.  There is a big comment which
immediately above the code which seems related, but I'm not
sure how.

I think this patch (or another which fixes the problem)
should be applied to 2.2.1.  Note the problem is not
specific to any particular library or OS.

I'll try to get fpectl to work on Solaris 8, but that is a
different subject to the build/install failure which is the
problem addressed by the patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 09:16

Message:
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 01:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-21 01:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-21 00:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 19:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 18:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:06:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:06:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16pV7U-0005T4-00@usw-sf-web3.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2002-03-25 14:06

Message:
Logged In: YES 
user_id=4771

Ok. This patch prevents the default module loader hooks 
used by RExec to locate any PY_COMPILED file. I added an 
ok_file_types tuple to RExec that lists the file types we 
should allow loading from -- currently only C_EXTENSION and 
PY_SOURCE.

I can add the above comment to the docs as well if the 
patch is acceptable.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 21:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 15:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:04:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:04:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-533632 ] 2.2 on HP-UX 11 64-bit - longs crash
Message-ID: <E16pV5W-0008BK-00@usw-sf-web2.sourceforge.net>

Bugs item #533632, was opened at 2002-03-22 16:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2.2 on HP-UX 11 64-bit - longs crash

Initial Comment:
>>> a=1L
>>> type(a)
<type 'long'>
>>> a
Bus error(coredump)

F***! Nearly everything else works. It just seems to
be something in repr() of a long that crashes it.

Anyone else have this problem?


----------------------------------------------------------------------

Comment By: Peter Harris (scav)
Date: 2002-03-25 09:43

Message:
Logged In: YES 
user_id=8911

Thanks all.

I am using the HP-UX ANSI C compiler (cc -Ae).

Recompiling longobject.c without optimisations worked OK, 
so I'm content.

If no similar problems emerge, I'll not need to learn how 
to use the debugger (adb, which I find fairly daunting!)

Peter

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 18:58

Message:
Logged In: YES 
user_id=31435

Peter, no, there have been no other reports of this on 64-
bit platforms.  If possible, try recompiling longobject.c 
with optimization disabled.  Its internal long_format() 
routine is complicated so has a better-than-usual chance of 
provoking bad code generation. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:29

Message:
Logged In: YES 
user_id=21627

Can you please also report which compiler you have been using?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:29

Message:
Logged In: YES 
user_id=21627

Can you use a debugger to find out and report where it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533632&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:22:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:22:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-517704 ] Installing Python 2.2 on Solaris 2.x
Message-ID: <E16pVMX-000591-00@usw-sf-web1.sourceforge.net>

Bugs item #517704, was opened at 2002-02-14 15:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517704&group_id=5470

Category: Installation
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Jeff Bauer (jeffbauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installing Python 2.2 on Solaris 2.x

Initial Comment:
I'm having problems installing Python 2.2 onto
my Solaris 2.6 workstation.

I am doing the boilerplate ...

  ./configure
  make
  make install

I checked for prior related bug reports and posted
on c.l.py.  Chris Wysocki reported similar problems
and Barry Warsaw mentioned on python-dev how
setup.py agressively deletes .so files when it
gets an import error after building the file.

Note:  No problems building Python 2.1 (2.1.2) on
this platform.

Log files attached.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 09:22

Message:
Logged In: YES 
user_id=33168

This should be fixed in setup.py 1.85 and 1.73.4.3.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:59

Message:
Logged In: YES 
user_id=33168

For a possible fix, see the patch in bug # 532618 :
http://sourceforge.net/tracker/index.php?func=detail&aid=532618&group_id=5470&atid=105470

The patch is against the latest in CVS.  Need to apply the
try/except around the for filename in self._built_objects
for this to work.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517704&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:24:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:24:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-532618 ] install fails if build .so fails
Message-ID: <E16pVOJ-0005AA-00@usw-sf-web1.sourceforge.net>

Bugs item #532618, was opened at 2002-03-20 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470

Category: Distutils
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: install fails if build .so fails

Initial Comment:
This is when using purify, fpectl.so fails to build.
After this an exception is raised in distutils.

Here's some of the interesting bits.

The attached file should have everyhing:

Instrumenting: fpectl.so Done.
WARNING: removing "fpectl" since importing it failed
Traceback (most recent call last):
  File "./setup.py", line 796, in ?
    main()
  File "./setup.py", line 790, in main
    scripts = ['Tools/scripts/pydoc']
...
  File
"/space/purify/python/python/dist/2.2/Lib/distutils/cmd.py",
line 107, in __getattr__
    raise AttributeError, attr
AttributeError: _built_objects

In order to get this far, I also had to include this
patch to Python/dynload_shlib.c:93:


<    PyErr_SetString(PyExc_ImportError, dlerror());
---
>    const char* err = dlerror();
>    if (! err)
>        err = "";
>    PyErr_SetString(PyExc_ImportError, err);

This patch should not be applied.  It's just necessary
for purify, AFAIK.

This problem can be duplicated outside of purify with
the following steps (on Linux):

    configure
    make
    # stop make after fpectl.o
    chmod 000 build/*/fpe*
    make
    # exception should be raised

Purify version is 2002a.06.00 Proto 38 on 
Solaris 8/Sparc.


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 09:24

Message:
Logged In: YES 
user_id=33168

Checked in as setup.py 1.85 and 1.73.4.3.
The Carbon chunk was fixing whitespace.
It should not have been in the patch, but I didn't
notice until after your comment and Michaels checkin.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 09:00

Message:
Logged In: YES 
user_id=6656

Hokay, checked in as revision 1.73.4.3 of setup.py.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-25 08:56

Message:
Logged In: YES 
user_id=21627

The patch to setup.py itself is fine (although I'm not sure
what the Carbon chunk is doing there). It is not quite clear
to me why it is needed, though: When fpectl.so was first
built, an import was attempted. That import must have
succeeded, or else the built_objects would have been
removed, and 'make install' would have rebuilt them again.

One scenario where this can go wrong is that  Python crashes
during import of the extension module, in which case the
extension remains there, but is not built again. So assuming
something like that happened to you, please apply the patch.


----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-25 07:46

Message:
Logged In: YES 
user_id=33168

Changed the subject to more closely describe the problem.
The patch may be more treating the symptom, but I don't know
distutils well enough to know.  There is a big comment which
immediately above the code which seems related, but I'm not
sure how.

I think this patch (or another which fixes the problem)
should be applied to 2.2.1.  Note the problem is not
specific to any particular library or OS.

I'll try to get fpectl to work on Solaris 8, but that is a
different subject to the build/install failure which is the
problem addressed by the patch.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-21 04:16

Message:
Logged In: YES 
user_id=21627

SUNWspro is the unbundled compiler, an optional payware
package, see

http://www.sun.com/forte/cplusplus/index.html

If you don't have it, you can't find it :-)

I believe this package is the only way to obtain
libsunmath.so (it's actually SPROsmsx), and that libsunmath
is required for proper operation of fpectl on Solaris.

So if libsunmath is not found, this module should not be built.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:51

Message:
Logged In: YES 
user_id=33168

Ok, I did a little more searching and found the problem.
There is a generic problem with dist/src/setup.py.
I can't say I completely understand it, but the
attached patch fixes the problem.

This patch should also fix bug # 517704 :
http://sourceforge.net/tracker/index.php?func=detail&aid=517704&group_id=5470&atid=105470
At certain points, if a build fails, install will
also fail.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 20:06

Message:
Logged In: YES 
user_id=33168

I don't have the directory /opt/SUNWspro.
I did a:  find /opt -name '*sunmath*' -print
and got nothing.  Also looked for *ieee*,
nm /usr/lib/lib*.a also yields nothing.

But there is fpsetmask() now.  And there's 
#include <floatingpoint.h> or <sys/ieeefp.h>
I think the code needs to be rewritten, but I'm
not sure what to do.  I think the whole code in
#ifdef sun, should be something like this (for solaris 8 only):

    #include <floatingpoint.h>
    sigfpe(FPE_FLTOVF, handler);
    sigfpe(FPE_FLTDIV, handler);
    sigfpe(FPE_FLTUBV, handler);

or

    #include <ieeefp.h>
    fpsetmask(FP_X_INV | FP_X_OFL | FP_X_DZ);   
PyOS_setsig(SIGFPE, handler);

But that's a guess from the man pages.
Are there any tests for fpectl?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-20 19:08

Message:
Logged In: NO 

for me, -lsunmath is in /opt/SUNWspro/lib. I don't
believe we have the sun compilers.

(Anthony here - stupid sf keeps telling me to log back
in)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-03-20 14:07

Message:
Logged In: YES 
user_id=33168

Actually the bug report was more about the distutils
problem.  It should not be specific to fpectl, although
that was the problem when I noticed it.

Distutils will presumably always raise an exception if it
cannot open a dynamic library.

Also, in 530163 there is mention of -lsunmath, 
I cannot find any sunmath or ieee library on solaris.
The other report was for solaris 7, where this is solaris 8.
There is an ieee_handlers in -lc.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-20 13:45

Message:
Logged In: YES 
user_id=21627

I got crashes from loading fpectl.so, too. It seems to be
related to #530163: does the problem go away if you link
with -lsunmath?

This appears to be a duplicate of #472642, so I'm resolving
it tentatively as such. Unless further information is
expected, I recommend to close this report.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532618&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 14:53:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 06:53:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-534158 ] Running MacPython as non-priv user may fail
Message-ID: <E16pVrB-0000UD-00@usw-sf-web4.sourceforge.net>

Bugs item #534158, was opened at 2002-03-24 00:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Running MacPython as non-priv user may fail

Initial Comment:
Running Python (especially the IDE, but possibly also the interpreter from a non-standard place)on OSX as a non-privileged user if you've previously installed it system-wide (as a privileged user) may not work the first time. In some cases it will start to work automatically, in other cases you have to throw away the (per-user) preferences file.

At the very least we need to warn for this in the README.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-25 15:53

Message:
Logged In: YES 
user_id=45365

Added a note to the readme for 2.2.1.

Lowering the priority, it may be a while before I get around to all the OSX multiuser intricacies.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534158&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 15:13:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 07:13:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16pWAW-0005e0-00@usw-sf-web1.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 1
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 10:13

Message:
Logged In: YES 
user_id=6380

If you want to override division in a complex subclass, you
should define both __truediv__ and __div__, as well as
__rtruediv__ and __rdiv__.  You can do this by saying
__truediv__ = __div__, of course.


----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 20:11

Message:
Logged In: YES 
user_id=248775

Have just re-read my submission - and
in addition to my usual quota of typos
I see I left out something that could 
confuse what I am trying to bring to 
your attention.

The gist, I am sure you will see, is that
type(a/b), where a and b are of a class derived
from complex, will change based on whether
from __future__ import division is or is not
called.

And I am assuming that behavior is unanticipated.

And I assuming there is no reason to submit this a
a bug report separate from this thread.

Art

----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 19:24

Message:
Logged In: YES 
user_id=248775

Guido - 

Thanks for your attention to my report.

Another bit of suprise with operator overriding
in a subclass of complex:
  
from __future__ import division
class Complex(complex):
    def __div__(self,other):
        t=complex.__div__(self,other)       
        return Complex(t.real,t.imag)
a=Complex(5,4)
b=Complex(1,7)

>> <type 'complex'>

But:

everything the same *without* calling
from __future__ import division  

print type(a/b)
>><class '__main__.Complex'>

Based your analysis of the previous
issue(which I follow only
in broad outline), I have a sense of 
what's happening.   

My general sense, though, is that this issue
is in some sense more of a problem than
the other.

Don't think anyone will expect a change in
behavior here based on the from __future__
call.  Not that subbing complex is a common pursuit -
but couldn't this actually break working code
in a very unanticpated way, eventually.

Obviously not a big issue if the other changes
you see happening with complex coercian kick in
first, and in fact those changes - as I suspect - 
would prevent a different return type based
on which way int/int is toggled.

Art  

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=6380

It seems that * is the exception -- all other operators (+,
-, /, **) return the type of the left operand.  It gets even
weirder if we change the left operand from 7 to 7.0 -- then
* is no longer an exception and returns a complex like all
other operators!

The weirdness is in int_mul. If the right argument is not an
int but a sequence that implements the sq_repeat slot, it
invokes that. But if you create a class that defines
__mul__, that implements the sequence repeat slot! (Python
doesn't know if you intend to implement a seqence or a
number, when you define a __mul__ method, so it maps both
the nb_multiply and the sq_repeat slots to the __mul__
method).

So 7 + Complex() takes the path through int_mul that calls
the Complex.__mul__ , and that's why you get a Complex value
back. Floats can't be used in the sequence repeat operator,
so its multiply is "normal".

But wait...! There's another mystery. Ints don't know how to
add themselves to complex numbers! So why wouldn't
7+Complex() use the normal pattern of (a) try the left
operand, (b) if that returns NotImplemented, try the right
operand? The answer is that complex numbers implement
coercion! And in that case, step (b) is modified to (b) ask
either operand to perform a coercion, and if it succeeds,
ask the left operand of the resulting coerced pair to
perform the operation. So complex coerces the int to a plain
complex, and then invokes the plain complex's add/mul/etc.
operation.

Solution: add the following to your Complex class:

    def __coerce__(self, other):
        x = complex.__coerce__(self, other)
        if x is NotImplemented:
            return x
        a, b = x
        return Complex(a), Complex(b)

I don't think I want to do anything to fix this, although I
think I'll pass it on to Fred for documentation (not that I
expect him to be in a hurry to fix it either, given the
subtlety of the issues).

In the long run, I think complex should stop using coercion
and start behaving like a "new-style" number like all the
other numeric types. That should fix the second mystery.

Also, in the long run, the sq_repeat and sq_concat slots
should be deprecated and instead sequences should implement
multiply and add operations. Then the funny business in
int_mul could be taken out and the first mystery would
disappear.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 15:20:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 07:20:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-531355 ] surprise overriding __radd__ in subclass of complex
Message-ID: <E16pWHC-0000UU-00@usw-sf-web2.sourceforge.net>

Bugs item #531355, was opened at 2002-03-18 09:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 1
Submitted By: Arthur Siegel (aj_siegel)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: surprise overriding __radd__ in subclass of complex

Initial Comment:
I had presented this on tutor and python-list:

class Complex(complex):
    def __mul__(self,other):
       other=Complex(other)
       t = complex.__mul__(self,other)
       return Complex(t.real,t.imag)
    __rmul__ = __mul__

    def __add__(self,other):
       other=Complex(other)
       return Complex(self.real.__add__
(other.real),self.imag.__add__(other.imag))
    __radd__ = __add__

Then:

print type(Complex(5,4) * 7)
>><class '__main__.Complex'>
print type(7 * Complex(5,4))
>><class '__main__.Complex'>
print type(Complex(5,4) + 7)
>><class '__main__.Complex'>

But:

print type(7 + Complex(5,4))
>><type 'complex'>


Danny Yoo, after looking into it pretty deeply - 
and going to the docs and source gace me this
advice.

"In any case, this is definitely a bug in the 
documentation.  Arthur, bring
it up on comp.lang.python and Sourceforge again.  
Someone should really
look at your example, since it does seem serious... if 
not a little
obscure.  *grin*  "



----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-25 10:20

Message:
Logged In: YES 
user_id=248775

Knew I'd embarass myself soon enough in this
company.

Found the __truediv__ answer on the train into
work.  Came here hoping to catch it, before you caught
me.

Too late.

Thanks again - oops for the false alarm.

Art 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 10:13

Message:
Logged In: YES 
user_id=6380

If you want to override division in a complex subclass, you
should define both __truediv__ and __div__, as well as
__rtruediv__ and __rdiv__.  You can do this by saying
__truediv__ = __div__, of course.


----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 20:11

Message:
Logged In: YES 
user_id=248775

Have just re-read my submission - and
in addition to my usual quota of typos
I see I left out something that could 
confuse what I am trying to bring to 
your attention.

The gist, I am sure you will see, is that
type(a/b), where a and b are of a class derived
from complex, will change based on whether
from __future__ import division is or is not
called.

And I am assuming that behavior is unanticipated.

And I assuming there is no reason to submit this a
a bug report separate from this thread.

Art

----------------------------------------------------------------------

Comment By: Arthur Siegel (aj_siegel)
Date: 2002-03-24 19:24

Message:
Logged In: YES 
user_id=248775

Guido - 

Thanks for your attention to my report.

Another bit of suprise with operator overriding
in a subclass of complex:
  
from __future__ import division
class Complex(complex):
    def __div__(self,other):
        t=complex.__div__(self,other)       
        return Complex(t.real,t.imag)
a=Complex(5,4)
b=Complex(1,7)

>> <type 'complex'>

But:

everything the same *without* calling
from __future__ import division  

print type(a/b)
>><class '__main__.Complex'>

Based your analysis of the previous
issue(which I follow only
in broad outline), I have a sense of 
what's happening.   

My general sense, though, is that this issue
is in some sense more of a problem than
the other.

Don't think anyone will expect a change in
behavior here based on the from __future__
call.  Not that subbing complex is a common pursuit -
but couldn't this actually break working code
in a very unanticpated way, eventually.

Obviously not a big issue if the other changes
you see happening with complex coercian kick in
first, and in fact those changes - as I suspect - 
would prevent a different return type based
on which way int/int is toggled.

Art  

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 22:18

Message:
Logged In: YES 
user_id=6380

It seems that * is the exception -- all other operators (+,
-, /, **) return the type of the left operand.  It gets even
weirder if we change the left operand from 7 to 7.0 -- then
* is no longer an exception and returns a complex like all
other operators!

The weirdness is in int_mul. If the right argument is not an
int but a sequence that implements the sq_repeat slot, it
invokes that. But if you create a class that defines
__mul__, that implements the sequence repeat slot! (Python
doesn't know if you intend to implement a seqence or a
number, when you define a __mul__ method, so it maps both
the nb_multiply and the sq_repeat slots to the __mul__
method).

So 7 + Complex() takes the path through int_mul that calls
the Complex.__mul__ , and that's why you get a Complex value
back. Floats can't be used in the sequence repeat operator,
so its multiply is "normal".

But wait...! There's another mystery. Ints don't know how to
add themselves to complex numbers! So why wouldn't
7+Complex() use the normal pattern of (a) try the left
operand, (b) if that returns NotImplemented, try the right
operand? The answer is that complex numbers implement
coercion! And in that case, step (b) is modified to (b) ask
either operand to perform a coercion, and if it succeeds,
ask the left operand of the resulting coerced pair to
perform the operation. So complex coerces the int to a plain
complex, and then invokes the plain complex's add/mul/etc.
operation.

Solution: add the following to your Complex class:

    def __coerce__(self, other):
        x = complex.__coerce__(self, other)
        if x is NotImplemented:
            return x
        a, b = x
        return Complex(a), Complex(b)

I don't think I want to do anything to fix this, although I
think I'll pass it on to Fred for documentation (not that I
expect him to be in a hurry to fix it either, given the
subtlety of the issues).

In the long run, I think complex should stop using coercion
and start behaving like a "new-style" number like all the
other numeric types. That should fix the second mystery.

Also, in the long run, the sq_repeat and sq_concat slots
should be deprecated and instead sequences should implement
multiply and add operations. Then the funny business in
int_mul could be taken out and the first mystery would
disappear.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-18 09:49

Message:
Logged In: YES 
user_id=6380

You're right, something's weird. I'll add this to my list.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531355&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 15:36:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 07:36:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-534625 ] ftplib hangs: ftp=FTP('ftp.example.com')
Message-ID: <E16pWVy-0006LA-00@usw-sf-web3.sourceforge.net>

Bugs item #534625, was opened at 2002-03-25 12:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Pascal Oberndörfer (oberndoerfer)
>Assigned to: Michael Hudson (mwh)
Summary: ftplib hangs: ftp=FTP('ftp.example.com')

Initial Comment:
Typing the following at the interpreter:

>>> from ftplib import FTP
>>> ftp = FTP('ftp.example.com')

the interpreter hangs.

MacPython 2.2.1c1 on MacOS X 10.1.3


----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-25 16:36

Message:
Logged In: YES 
user_id=45365

Fixed in socketmodule.c 1.211. Michael, can you check it into the 221 branch?

(for reference: this turned out to be a problem with the fix for getting rid of short reads on urlopened files. With the GUSI/MSL combo we can get either read()s from binary buffered files working or read()s from binary unbuffered files, but not both. The fix (workaround, actually) is to have socket.makefile() force unbuffered for binary files.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 16:48:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 08:48:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful
Message-ID: <E16pXeG-0006ww-00@usw-sf-web3.sourceforge.net>

Bugs item #534748, was opened at 2002-03-25 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Nobody/Anonymous (nobody)
Summary: Removing _tkinter considered harmful

Initial Comment:
The Python build process now tries to import _tkinter
and if it cannot removes it. There are two problems
with this:

a. It isn't correct.
b. It removes the very thing required to understand why
it  won't import.

(a) It isn't correct because it might import correctly
later. If the user has, for example, installed tk / tcl
in a place that is not in LD_LIBRARY_PATH, the import
might fail during the Python build but succeed after
the user sets this variable. Since the installer having
it set is no guarantee the user will have it set, we
aren't buying anything by verifying that the installer
can import it.

(b) If it won't import you just destroyed the evidence.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 17:02:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 09:02:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16pXs3-00074h-00@usw-sf-web3.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 12:02

Message:
Logged In: YES 
user_id=6380

Thanks. I'll have to think about this some more. I guess
it's easy enough to document that one can get performance
back by adding imp.PY_COMPILED to ok_file_types.

I've added a context diff (1) to make your patch less
suscpetible to going stale (2) to use a list comprehension
instead of filter().

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-25 09:06

Message:
Logged In: YES 
user_id=4771

Ok. This patch prevents the default module loader hooks 
used by RExec to locate any PY_COMPILED file. I added an 
ok_file_types tuple to RExec that lists the file types we 
should allow loading from -- currently only C_EXTENSION and 
PY_SOURCE.

I can add the above comment to the docs as well if the 
patch is acceptable.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 16:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 10:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 17:41:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 09:41:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-534625 ] ftplib hangs: ftp=FTP('ftp.example.com')
Message-ID: <E16pYTa-0007NB-00@usw-sf-web3.sourceforge.net>

Bugs item #534625, was opened at 2002-03-25 11:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Pascal Oberndörfer (oberndoerfer)
Assigned to: Michael Hudson (mwh)
Summary: ftplib hangs: ftp=FTP('ftp.example.com')

Initial Comment:
Typing the following at the interpreter:

>>> from ftplib import FTP
>>> ftp = FTP('ftp.example.com')

the interpreter hangs.

MacPython 2.2.1c1 on MacOS X 10.1.3


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-25 17:41

Message:
Logged In: YES 
user_id=6656

Done, in revision 1.200.6.3, so closing.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-25 15:36

Message:
Logged In: YES 
user_id=45365

Fixed in socketmodule.c 1.211. Michael, can you check it into the 221 branch?

(for reference: this turned out to be a problem with the fix for getting rid of short reads on urlopened files. With the GUSI/MSL combo we can get either read()s from binary buffered files working or read()s from binary unbuffered files, but not both. The fix (workaround, actually) is to have socket.makefile() force unbuffered for binary files.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534625&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 18:22:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 10:22:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-533198 ] Complex power underflow raises exception
Message-ID: <E16pZ7H-0007Re-00@usw-sf-web1.sourceforge.net>

Bugs item #533198, was opened at 2002-03-21 12:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Konrad Hinsen (hinsen)
Assigned to: Tim Peters (tim_one)
Summary: Complex power underflow raises exception

Initial Comment:
Python 2.2.1c1 (#1, Mar 19 2002, 12:10:26) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> (0.01+0.01j)**200
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: 0.0 to a negative or complex power


I could trace this back to the routine c_pow() in complexobject.c. It explicitly sets ERANGE for the case that it quoted in the error message, but in my example, ERANGE is set by pow() in line 140 of complexobject.c.

The problem disappears if I link Python with -lieee under Linux, but after the recent discussion I had the impression that Python is not supposed to use -lieee under Linux, for whatever reason.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-25 13:22

Message:
Logged In: YES 
user_id=31435

Thanks for the 2.1 confirmation, Konrad!

As Michael asked, closing as (presumed) Fixed so this 
doesn't show up as a showstopper 2.2.1 issue anymore.  
Konrad, if the example still fails under 2.2.1c2, leave a 
note here and I'll reopen this.

Michael, are you intending a second release candidate?  Or 
is this really 2.2.1 final?

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-25 08:58

Message:
Logged In: YES 
user_id=11850

The bug is indeed old, the behaviour is the same under 2.1.2, as I just checked.

I will try 2.2.1c2 as soon as it is out.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 08:29

Message:
Logged In: YES 
user_id=6656

I've ported Tim's fix from the trunk.  It will be in 2.2.1c2
which will probably be released tomorrow.

Can this be closed?

> For the moment, I propose to reactivate -lieee 
> for Linux again in 2.2.1.

No chance.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=31435

It would help if you simply tried your example under 2.1 -- 
I don't have your system, and can't try it for you.  It's 
extraordinarily risky making any last-second change to a 
bugfix release, and whether it's an old bug feeds into the 
tradeoff calculation.

Enabling -lieee at the last second isn't something I'll do 
without lots of people swearing it doesn't hurt anything on 
their boxes.  Not all systems act the same way in the 
presence of -lieee.  The change I did make is in our C 
code, where I have a good chance of guessing what various C 
compilers will do; -lieee does whatever a platform feels 
like doing, and there's no standard to constrain it.

----------------------------------------------------------------------

Comment By: Konrad Hinsen (hinsen)
Date: 2002-03-22 08:53

Message:
Logged In: YES 
user_id=11850

Perhaps these are old bugs, but I never ran into them before. I will try the CVS as soon as I can. Given my bad track record with downloads from SourceForge, that might be a while...

For the moment, I propose to reactivate -lieee for Linux again in 2.2.1. I have done lots of tests with that combination recently, with no adverse effects.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:51

Message:
Logged In: YES 
user_id=31435

These are old bugs in complex_pow() and friends.  Please 
give current CVS a try!  Changes made in

Objects/complexobject.c; new revision: 2.55:

1. Raising 0 to a negative power isn't a range error, it's 
a domain error, so changed c_pow() to set errno to EDOM in
that case instead of ERANGE.

2. Changed complex_pow() to:

A. Use the Py_ADJUST_ERANGE2 macro to try to clear errno of
a spurious ERANGE error due to underflow in the libm pow()
called by c_pow().

B. Produce different exceptions depending on the errno
value:

i) For errno==EDOM, raise ZeroDivisionError instead of
ValueError.  This is for consistency with the non-complex 
cases 0.0**-2 and 0**-2 and 0L**-2.

ii) For errno==ERANGE, raise OverflowError.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 21:38

Message:
Logged In: YES 
user_id=31435

Assigned to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-21 14:20

Message:
Logged In: YES 
user_id=31435

1. Konrad, this isn't a *new* problem, right?  That is, 
this code hasn't changed in ages.  I'd expect it to fail 
the same way in, e.g., 2.1.

2. I know of no reason to avoid -lieee.  Someone checked in 
a patch to stop linking with it sometimes, but the reason 
for the change wasn't recorded.  People do lots of random 
stuff <0.5 wink>.  If you find a sensible reason to avoid 
it, let me know.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533198&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 18:54:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 10:54:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16pZcQ-0002RS-00@usw-sf-web2.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 10:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 20:24:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 12:24:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-529923 ] re module syntax documentation omission
Message-ID: <E16pb0o-0000QW-00@usw-sf-web1.sourceforge.net>

Bugs item #529923, was opened at 2002-03-14 10:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529923&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: re module syntax documentation omission

Initial Comment:
The discussion of what the backslash character does in 
the documentation chapter "4.2.1 Regular Expression 
Syntax" is incorrect. In addition to the sequences 
listed, other sequences also work, e.g. "\n", "\x7f", 
etc.

>>> p = r"\x40"
>>> p
'\x40'
>>> re.search(p, "foo@bar")
<_sre.SRE_Match object at 0x183fc0>
>>> re.search(p, "x40")           
>>>

According to the documentation, the first search 
should fail and the second should succeed. In fact, 
the opposite occurs.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-25 15:24

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libre.tex revisions 1.81 and 1.73.6.6.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=529923&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 20:25:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 12:25:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-520904 ] Regex object finditer not documented
Message-ID: <E16pb2S-0003XB-00@usw-sf-web2.sourceforge.net>

Bugs item #520904, was opened at 2002-02-21 05:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520904&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Regex object finditer not documented

Initial Comment:
The finditer method of regex objects is not listed in 
the documentation.

doc/current/lib/re-objects.html should include a 
description of this method.

Oh, and there is another undocumented method 'scanner' 
which is a lot less intuitively obvious than finditer.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-25 15:25

Message:
Logged In: YES 
user_id=3066

finditer() documented in Doc/lib/libre.tex revisions 1.81
and 1.73.6.6.  The scanner() method remains undocumented
until Fredrik Lundh determines that it should be documented
(and provides text for the description).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=520904&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 21:15:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 13:15:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E16pboN-0004Pm-00@usw-sf-web4.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 16:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 21:19:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 13:19:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E16pbsI-0001Tt-00@usw-sf-web3.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 16:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Nobody/Anonymous (nobody)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


----------------------------------------------------------------------

>Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 16:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 22:27:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 14:27:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E16pcw3-0005Gy-00@usw-sf-web4.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 16:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-25 17:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

----------------------------------------------------------------------

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 16:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 22:46:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 14:46:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-534613 ] urllib.unquote() is not idempotent
Message-ID: <E16pdEh-0005VQ-00@usw-sf-web4.sourceforge.net>

Bugs item #534613, was opened at 2002-03-25 05:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
>Assigned to: Tim Peters (tim_one)
Summary: urllib.unquote() is not idempotent

Initial Comment:
There are URLs s, where

unquote(unquote(s)) != unquote(s)

I.e. unquote sometimes does not complete its task. Example (real world):

s = 
'/r?ck_sm=765ea975&ref=20096&r=http%3A%2F%2Fwww.altavista.com%2Fsites%2Fsearch%2Fmm
_resultframe%3Fq%3Dbike%26type%3DIMG%26url%3Dhttp%253A%252F%252Fvmesa17.u-3mrs.fr
%253A10081%252F%257Em9402001%252Fbike.htm%26title%3Dbike_1.jpg%26isrc%3Dhttp%253A
%252F%252Fthumb-1.image.altavista.com%252Fimage%252F49909424%26src%3Dhttp%253A%25
2F%252Fvmesa17.u-3mrs.fr%253A10081%252F%257Em9402001%252Fbike_1.jpg%26stq%3D50%2
6stype%3Dsimage'

unquote(s) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike.htm&titl
e=bike_1.jpg&isrc=http%3A%2F%2Fthumb-1.image.altavista.com%2Fimage%2F49909424&src=http
%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike_1.jpg&stq=50&stype=simage
'
unquote(unquote(s)) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http://vmesa17.u-3mrs.fr:10081/~m9402001/bike.htm&title=bike_1.jpg&isrc=http:
//thumb-1.image.altavista.com/image/49909424&src=http://vmesa17.u-3mrs.fr:10081/~m9402001/
bike_1.jpg&stq=50&stype=simage'


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-25 17:46

Message:
Logged In: YES 
user_id=31435

Python's behavior here is correct.  URL encoding is defined 
in RFC 1738:

http://www.ietf.org/rfc/rfc1738.txt

If you still believe Python's behavior is in error here, 
quote the RFC for justification.

If you ever find a URL decoder that, for example, changes

    %2525

into

    %

instead of into

    %25

it's a broken decoder.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-25 05:45

Message:
Logged In: YES 
user_id=43607

What makes you think that urllib.unquote *should* be idempotent?
The whole reason for unquote is to remove the %-escapes from a URL, and this *cannot* be idempotent.

I would say "Not a bug".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 23:08:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 15:08:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python)
Message-ID: <E16pdZt-0005Tz-00@usw-sf-web2.sourceforge.net>

Bugs item #502085, was opened at 2002-01-10 14:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Nobody/Anonymous (nobody)
Summary: pickle problems (with Boost.Python)

Initial Comment:
Boost.Python 
(http://www.boost.org/libs/python/doc/index.html) is a
popular package for integrating Python and C++.

Boost.Python pickle support is broken when using 
Python 2.2 final, but
works with Python 2.2c1.

I noticed this difference:

diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py /usr/local_cci/Python-
2.2c1/lib/python2.2/pickle.py
26c26
< __version__ = "$Revision: 1.56 $"       # Code 
version
---
> __version__ = "$Revision: 1.55 $"       # Code 
version
166,169d165
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return

I inserted one line in pickle.py:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
165a166
>             print "t", t

Result:

t <extension class pickle1.world at 1400c9c08>
t 
<boost::python::meta_class<boost::python::detail::exten
sion_instance> object at 0x3ffffe41ae0>
Traceback (most recent call last):
  File "zi", line 9, in ?
    pstr = pickle.dumps(wd)
  File "pickle.py", line 974, in dumps
    Pickler(file, bin).dump(object)
  File "pickle.py", line 115, in dump
    self.save(object)
  File "pickle.py", line 216, in save
    self.save_reduce(callable, arg_tup, state)
  File "pickle.py", line 241, in save_reduce
    save(callable)
  File "pickle.py", line 167, in save
    if issubclass(t, TypeType):
TypeError: issubclass() arg 1 must be a class

The following patch restores backward-compatibility:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
166,168c166,173
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return
---
>             try:
>                 issc = issubclass(t, TypeType)
>             except TypeError:
>                 pass
>             else:
>                 if issc:
>                     self.save_global(object)
>                     return

Remark: I also noticed that 2.2 cPickle still works 
for us
(double-checked) even though the CVS logs indicate 
that it was
also modified between 2.2c1 and 2.2.

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-03-25 15:08

Message:
Logged In: YES 
user_id=71407

python 2.2.1c1 still exhibits the problem described
in the original posting. Is this expected? Is there
still hope that the suggested fix/work-around is
considered for 2.2.1?
Thanks,
         Ralf


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 10:39

Message:
Logged In: YES 
user_id=6380

Ah, I didn't realize this was the old Boost. I should have
(the new one only runs on Python 2.2).

I'll think about it.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-01-11 09:17

Message:
Logged In: YES 
user_id=71407

> IOW I think that the correct solution would be a change to
> Boost. But I'm open to persuasion.

In principle I agree with you, but here are a few arguments 
to
justify the easy fix:

- The old Boost.Python metaclass system is a dead branch.
  We would prefer to concentrate our time on the ongoing
  rewrite of Boost.Python which will be fully based on
  the new Python 2.2 type system.

- A significant number of people are using released versions
  of Boost(.Python). If the easy fix is integrated in 
Python 2.2.1,
  they could continue to use what they have.

- Other people might be affected by your change. The 
suggested solution
  will restore backward-compatibility with more people's 
existing code.

- This is more a question: can you envision that the 
suggested
  fix has negative side-effects?

Thanks,
        Ralf

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-10 21:07

Message:
Logged In: YES 
user_id=6380

Hm, I'm surprised that t (which was returned by
type(object)) is not considered a type. Can you explain the
Boost metaclass hierarchy a bit so that I can understand how
this can work? It was found in the ob_type slot of the
object (because that's what type() returns) so it should
look a lot like a type! Then why isn't it one?

IOW I think that the correct solution would be a change to
Boost. But I'm open to persuasion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470


From noreply@sourceforge.net  Mon Mar 25 23:19:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 15:19:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python)
Message-ID: <E16pdkT-0005tH-00@usw-sf-web4.sourceforge.net>

Bugs item #502085, was opened at 2002-01-10 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle problems (with Boost.Python)

Initial Comment:
Boost.Python 
(http://www.boost.org/libs/python/doc/index.html) is a
popular package for integrating Python and C++.

Boost.Python pickle support is broken when using 
Python 2.2 final, but
works with Python 2.2c1.

I noticed this difference:

diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py /usr/local_cci/Python-
2.2c1/lib/python2.2/pickle.py
26c26
< __version__ = "$Revision: 1.56 $"       # Code 
version
---
> __version__ = "$Revision: 1.55 $"       # Code 
version
166,169d165
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return

I inserted one line in pickle.py:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
165a166
>             print "t", t

Result:

t <extension class pickle1.world at 1400c9c08>
t 
<boost::python::meta_class<boost::python::detail::exten
sion_instance> object at 0x3ffffe41ae0>
Traceback (most recent call last):
  File "zi", line 9, in ?
    pstr = pickle.dumps(wd)
  File "pickle.py", line 974, in dumps
    Pickler(file, bin).dump(object)
  File "pickle.py", line 115, in dump
    self.save(object)
  File "pickle.py", line 216, in save
    self.save_reduce(callable, arg_tup, state)
  File "pickle.py", line 241, in save_reduce
    save(callable)
  File "pickle.py", line 167, in save
    if issubclass(t, TypeType):
TypeError: issubclass() arg 1 must be a class

The following patch restores backward-compatibility:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
166,168c166,173
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return
---
>             try:
>                 issc = issubclass(t, TypeType)
>             except TypeError:
>                 pass
>             else:
>                 if issc:
>                     self.save_global(object)
>                     return

Remark: I also noticed that 2.2 cPickle still works 
for us
(double-checked) even though the CVS logs indicate 
that it was
also modified between 2.2c1 and 2.2.

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-25 18:19

Message:
Logged In: YES 
user_id=31435

Boosted priority and assigned to Guido.  Guido, if you want 
to do something here for 2.2.1, now's the time.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-03-25 18:08

Message:
Logged In: YES 
user_id=71407

python 2.2.1c1 still exhibits the problem described
in the original posting. Is this expected? Is there
still hope that the suggested fix/work-around is
considered for 2.2.1?
Thanks,
         Ralf


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 13:39

Message:
Logged In: YES 
user_id=6380

Ah, I didn't realize this was the old Boost. I should have
(the new one only runs on Python 2.2).

I'll think about it.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-01-11 12:17

Message:
Logged In: YES 
user_id=71407

> IOW I think that the correct solution would be a change to
> Boost. But I'm open to persuasion.

In principle I agree with you, but here are a few arguments 
to
justify the easy fix:

- The old Boost.Python metaclass system is a dead branch.
  We would prefer to concentrate our time on the ongoing
  rewrite of Boost.Python which will be fully based on
  the new Python 2.2 type system.

- A significant number of people are using released versions
  of Boost(.Python). If the easy fix is integrated in 
Python 2.2.1,
  they could continue to use what they have.

- Other people might be affected by your change. The 
suggested solution
  will restore backward-compatibility with more people's 
existing code.

- This is more a question: can you envision that the 
suggested
  fix has negative side-effects?

Thanks,
        Ralf

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 00:07

Message:
Logged In: YES 
user_id=6380

Hm, I'm surprised that t (which was returned by
type(object)) is not considered a type. Can you explain the
Boost metaclass hierarchy a bit so that I can understand how
this can work? It was found in the ob_type slot of the
object (because that's what type() returns) so it should
look a lot like a type! Then why isn't it one?

IOW I think that the correct solution would be a change to
Boost. But I'm open to persuasion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 00:54:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 16:54:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python)
Message-ID: <E16pfE3-0006dI-00@usw-sf-web2.sourceforge.net>

Bugs item #502085, was opened at 2002-01-10 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle problems (with Boost.Python)

Initial Comment:
Boost.Python 
(http://www.boost.org/libs/python/doc/index.html) is a
popular package for integrating Python and C++.

Boost.Python pickle support is broken when using 
Python 2.2 final, but
works with Python 2.2c1.

I noticed this difference:

diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py /usr/local_cci/Python-
2.2c1/lib/python2.2/pickle.py
26c26
< __version__ = "$Revision: 1.56 $"       # Code 
version
---
> __version__ = "$Revision: 1.55 $"       # Code 
version
166,169d165
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return

I inserted one line in pickle.py:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
165a166
>             print "t", t

Result:

t <extension class pickle1.world at 1400c9c08>
t 
<boost::python::meta_class<boost::python::detail::exten
sion_instance> object at 0x3ffffe41ae0>
Traceback (most recent call last):
  File "zi", line 9, in ?
    pstr = pickle.dumps(wd)
  File "pickle.py", line 974, in dumps
    Pickler(file, bin).dump(object)
  File "pickle.py", line 115, in dump
    self.save(object)
  File "pickle.py", line 216, in save
    self.save_reduce(callable, arg_tup, state)
  File "pickle.py", line 241, in save_reduce
    save(callable)
  File "pickle.py", line 167, in save
    if issubclass(t, TypeType):
TypeError: issubclass() arg 1 must be a class

The following patch restores backward-compatibility:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
166,168c166,173
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return
---
>             try:
>                 issc = issubclass(t, TypeType)
>             except TypeError:
>                 pass
>             else:
>                 if issc:
>                     self.save_global(object)
>                     return

Remark: I also noticed that 2.2 cPickle still works 
for us
(double-checked) even though the CVS logs indicate 
that it was
also modified between 2.2c1 and 2.2.

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 19:54

Message:
Logged In: YES 
user_id=6380

I checked in a fix on the trunk.

There's nothing I can do to get this into 2.2.1c2, but
Michael might be willing to put it in 2.2.1final. Otherwise
it should go into 2.2.2, if we ever release one.

(Sorry -- I forgot about this, and you were just a tad too
late to make the 2.2.1c2 release.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 18:19

Message:
Logged In: YES 
user_id=31435

Boosted priority and assigned to Guido.  Guido, if you want 
to do something here for 2.2.1, now's the time.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-03-25 18:08

Message:
Logged In: YES 
user_id=71407

python 2.2.1c1 still exhibits the problem described
in the original posting. Is this expected? Is there
still hope that the suggested fix/work-around is
considered for 2.2.1?
Thanks,
         Ralf


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 13:39

Message:
Logged In: YES 
user_id=6380

Ah, I didn't realize this was the old Boost. I should have
(the new one only runs on Python 2.2).

I'll think about it.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-01-11 12:17

Message:
Logged In: YES 
user_id=71407

> IOW I think that the correct solution would be a change to
> Boost. But I'm open to persuasion.

In principle I agree with you, but here are a few arguments 
to
justify the easy fix:

- The old Boost.Python metaclass system is a dead branch.
  We would prefer to concentrate our time on the ongoing
  rewrite of Boost.Python which will be fully based on
  the new Python 2.2 type system.

- A significant number of people are using released versions
  of Boost(.Python). If the easy fix is integrated in 
Python 2.2.1,
  they could continue to use what they have.

- Other people might be affected by your change. The 
suggested solution
  will restore backward-compatibility with more people's 
existing code.

- This is more a question: can you envision that the 
suggested
  fix has negative side-effects?

Thanks,
        Ralf

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 00:07

Message:
Logged In: YES 
user_id=6380

Hm, I'm surprised that t (which was returned by
type(object)) is not considered a type. Can you explain the
Boost metaclass hierarchy a bit so that I can understand how
this can work? It was found in the ob_type slot of the
object (because that's what type() returns) so it should
look a lot like a type! Then why isn't it one?

IOW I think that the correct solution would be a change to
Boost. But I'm open to persuasion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 07:39:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 25 Mar 2002 23:39:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-534613 ] urllib.unquote() is not idempotent
Message-ID: <E16plYL-0002lI-00@usw-sf-web4.sourceforge.net>

Bugs item #534613, was opened at 2002-03-25 10:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Tim Peters (tim_one)
Summary: urllib.unquote() is not idempotent

Initial Comment:
There are URLs s, where

unquote(unquote(s)) != unquote(s)

I.e. unquote sometimes does not complete its task. Example (real world):

s = 
'/r?ck_sm=765ea975&ref=20096&r=http%3A%2F%2Fwww.altavista.com%2Fsites%2Fsearch%2Fmm
_resultframe%3Fq%3Dbike%26type%3DIMG%26url%3Dhttp%253A%252F%252Fvmesa17.u-3mrs.fr
%253A10081%252F%257Em9402001%252Fbike.htm%26title%3Dbike_1.jpg%26isrc%3Dhttp%253A
%252F%252Fthumb-1.image.altavista.com%252Fimage%252F49909424%26src%3Dhttp%253A%25
2F%252Fvmesa17.u-3mrs.fr%253A10081%252F%257Em9402001%252Fbike_1.jpg%26stq%3D50%2
6stype%3Dsimage'

unquote(s) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike.htm&titl
e=bike_1.jpg&isrc=http%3A%2F%2Fthumb-1.image.altavista.com%2Fimage%2F49909424&src=http
%3A%2F%2Fvmesa17.u-3mrs.fr%3A10081%2F%7Em9402001%2Fbike_1.jpg&stq=50&stype=simage
'
unquote(unquote(s)) = 
'/r?ck_sm=765ea975&ref=20096&r=http://www.altavista.com/sites/search/mm_resultframe?q=bike
&type=IMG&url=http://vmesa17.u-3mrs.fr:10081/~m9402001/bike.htm&title=bike_1.jpg&isrc=http:
//thumb-1.image.altavista.com/image/49909424&src=http://vmesa17.u-3mrs.fr:10081/~m9402001/
bike_1.jpg&stq=50&stype=simage'


----------------------------------------------------------------------

>Comment By: Ralf Juengling (rjuengling)
Date: 2002-03-26 07:39

Message:
Logged In: YES 
user_id=495820

Thanks for clearing up matters; now I agree, it's not a bug.
A pointer to RFC 1738 in the documentation would be reasonable to state more precisely, what unquote() is 
supposed to do.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 22:46

Message:
Logged In: YES 
user_id=31435

Python's behavior here is correct.  URL encoding is defined 
in RFC 1738:

http://www.ietf.org/rfc/rfc1738.txt

If you still believe Python's behavior is in error here, 
quote the RFC for justification.

If you ever find a URL decoder that, for example, changes

    %2525

into

    %

instead of into

    %25

it's a broken decoder.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-25 10:45

Message:
Logged In: YES 
user_id=43607

What makes you think that urllib.unquote *should* be idempotent?
The whole reason for unquote is to remove the %-escapes from a URL, and this *cannot* be idempotent.

I would say "Not a bug".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534613&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 12:49:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 04:49:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-535170 ] new.instance() breaks with new classes
Message-ID: <E16pqON-0002tw-00@usw-sf-web1.sourceforge.net>

Bugs item #535170, was opened at 2002-03-26 23:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535170&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Nobody/Anonymous (nobody)
Summary: new.instance() breaks with new classes

Initial Comment:
>>> class a1: pass
... 
>>> a2 = type('a2', (), {})
>>> class a3(object): pass
... 
>>> a1
<class __main__.a1 at 0x815111c>
>>> a2
<class '__main__.a2'>
>>> a3
<class '__main__.a3'>
>>> import new
>>> new.instance(a1)
<__main__.a1 instance at 0x8148a04>
>>> new.instance(a2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: instance() argument 1 must be class, not type
>>> new.instance(a3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: instance() argument 1 must be class, not type

2.2 branch and current CVS...  _so_ not a 2.2 bugfix
necessity, tho :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535170&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 12:59:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 04:59:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-502085 ] pickle problems (with Boost.Python)
Message-ID: <E16pqYM-0005zc-00@usw-sf-web2.sourceforge.net>

Bugs item #502085, was opened at 2002-01-10 22:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Guido van Rossum (gvanrossum)
Summary: pickle problems (with Boost.Python)

Initial Comment:
Boost.Python 
(http://www.boost.org/libs/python/doc/index.html) is a
popular package for integrating Python and C++.

Boost.Python pickle support is broken when using 
Python 2.2 final, but
works with Python 2.2c1.

I noticed this difference:

diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py /usr/local_cci/Python-
2.2c1/lib/python2.2/pickle.py
26c26
< __version__ = "$Revision: 1.56 $"       # Code 
version
---
> __version__ = "$Revision: 1.55 $"       # Code 
version
166,169d165
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return

I inserted one line in pickle.py:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
165a166
>             print "t", t

Result:

t <extension class pickle1.world at 1400c9c08>
t 
<boost::python::meta_class<boost::python::detail::exten
sion_instance> object at 0x3ffffe41ae0>
Traceback (most recent call last):
  File "zi", line 9, in ?
    pstr = pickle.dumps(wd)
  File "pickle.py", line 974, in dumps
    Pickler(file, bin).dump(object)
  File "pickle.py", line 115, in dump
    self.save(object)
  File "pickle.py", line 216, in save
    self.save_reduce(callable, arg_tup, state)
  File "pickle.py", line 241, in save_reduce
    save(callable)
  File "pickle.py", line 167, in save
    if issubclass(t, TypeType):
TypeError: issubclass() arg 1 must be a class

The following patch restores backward-compatibility:

% diff /usr/local_cci/Python-
2.2/lib/python2.2/pickle.py .
166,168c166,173
<             if issubclass(t, TypeType):
<                 self.save_global(object)
<                 return
---
>             try:
>                 issc = issubclass(t, TypeType)
>             except TypeError:
>                 pass
>             else:
>                 if issc:
>                     self.save_global(object)
>                     return

Remark: I also noticed that 2.2 cPickle still works 
for us
(double-checked) even though the CVS logs indicate 
that it was
also modified between 2.2c1 and 2.2.

Thanks,
        Ralf


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-26 12:59

Message:
Logged In: YES 
user_id=6656

It's in 221c2

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-26 00:54

Message:
Logged In: YES 
user_id=6380

I checked in a fix on the trunk.

There's nothing I can do to get this into 2.2.1c2, but
Michael might be willing to put it in 2.2.1final. Otherwise
it should go into 2.2.2, if we ever release one.

(Sorry -- I forgot about this, and you were just a tad too
late to make the 2.2.1c2 release.)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 23:19

Message:
Logged In: YES 
user_id=31435

Boosted priority and assigned to Guido.  Guido, if you want 
to do something here for 2.2.1, now's the time.

----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-03-25 23:08

Message:
Logged In: YES 
user_id=71407

python 2.2.1c1 still exhibits the problem described
in the original posting. Is this expected? Is there
still hope that the suggested fix/work-around is
considered for 2.2.1?
Thanks,
         Ralf


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 18:39

Message:
Logged In: YES 
user_id=6380

Ah, I didn't realize this was the old Boost. I should have
(the new one only runs on Python 2.2).

I'll think about it.


----------------------------------------------------------------------

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2002-01-11 17:17

Message:
Logged In: YES 
user_id=71407

> IOW I think that the correct solution would be a change to
> Boost. But I'm open to persuasion.

In principle I agree with you, but here are a few arguments 
to
justify the easy fix:

- The old Boost.Python metaclass system is a dead branch.
  We would prefer to concentrate our time on the ongoing
  rewrite of Boost.Python which will be fully based on
  the new Python 2.2 type system.

- A significant number of people are using released versions
  of Boost(.Python). If the easy fix is integrated in 
Python 2.2.1,
  they could continue to use what they have.

- Other people might be affected by your change. The 
suggested solution
  will restore backward-compatibility with more people's 
existing code.

- This is more a question: can you envision that the 
suggested
  fix has negative side-effects?

Thanks,
        Ralf

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-11 05:07

Message:
Logged In: YES 
user_id=6380

Hm, I'm surprised that t (which was returned by
type(object)) is not considered a type. Can you explain the
Boost metaclass hierarchy a bit so that I can understand how
this can work? It was found in the ob_type slot of the
object (because that's what type() returns) so it should
look a lot like a type! Then why isn't it one?

IOW I think that the correct solution would be a change to
Boost. But I'm open to persuasion.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=502085&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 13:02:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 05:02:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16pqah-00061X-00@usw-sf-web2.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 18:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-26 13:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 14:07:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 06:07:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16prbb-0003qG-00@usw-sf-web1.sourceforge.net>

Bugs item #410541, was opened at 2001-03-22 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-03-26 15:07

Message:
Logged In: YES 
user_id=11105

IMO it is impossible to create a dumb binary distribution 
which can be used to install a package - even on the same 
platform for different Python versions. So it seems the 
only possibility is document dumb binary distros as broken.

The DISTUTILS TODO list is mainly just a list of thoughts 
from the previous maintainer, nobody (so far) is caring too 
much about it currently.

Assigning to AMK: Andrew, if you think this is ok, let us 
close this bug.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2002-03-06 21:33

Message:
Logged In: YES 
user_id=149084

I'm not sure what is meant by "everyone should install from
source or the native binary for his platform."  My
understanding is that Distutils was created to provide a
uniform way to install third party packages.

It seems that bdist_dumb has problems building a package
distribution which will install properly.  What about
non-Linux or Windows systems? It rather looks like the code
is unfinished....

To quote the TODO (DISTUTILS 1.1 PLANS):

"* bdist_dumb should grow a little intelligence: let
packager choose 
whether to make archive relative to prefix or the root
(prefix is essential for proper Windows support )"

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-03-05 22:08

Message:
Logged In: YES 
user_id=11105

I expect nobody will install from a zip-file on windows, 
either.

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:54

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-28 00:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 22:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 14:52:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 06:52:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16psIu-0007Pc-00@usw-sf-web2.sourceforge.net>

Bugs item #410541, was opened at 2001-03-22 11:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-26 09:52

Message:
Logged In: YES 
user_id=11375

Why not just remove bdist_dumb, then?


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-03-26 09:07

Message:
Logged In: YES 
user_id=11105

IMO it is impossible to create a dumb binary distribution 
which can be used to install a package - even on the same 
platform for different Python versions. So it seems the 
only possibility is document dumb binary distros as broken.

The DISTUTILS TODO list is mainly just a list of thoughts 
from the previous maintainer, nobody (so far) is caring too 
much about it currently.

Assigning to AMK: Andrew, if you think this is ok, let us 
close this bug.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2002-03-06 15:33

Message:
Logged In: YES 
user_id=149084

I'm not sure what is meant by "everyone should install from
source or the native binary for his platform."  My
understanding is that Distutils was created to provide a
uniform way to install third party packages.

It seems that bdist_dumb has problems building a package
distribution which will install properly.  What about
non-Linux or Windows systems? It rather looks like the code
is unfinished....

To quote the TODO (DISTUTILS 1.1 PLANS):

"* bdist_dumb should grow a little intelligence: let
packager choose 
whether to make archive relative to prefix or the root
(prefix is essential for proper Windows support )"

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-03-05 16:08

Message:
Logged In: YES 
user_id=11105

I expect nobody will install from a zip-file on windows, 
either.

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:54

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-27 18:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 16:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 15:29:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 07:29:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-410541 ] bdist builds bogus .zips
Message-ID: <E16psso-00056G-00@usw-sf-web3.sourceforge.net>

Bugs item #410541, was opened at 2001-03-22 17:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Thomas Heller (theller)
Summary: bdist builds bogus .zips

Initial Comment:
According to Thomas Heller: "... the resulting zip-file
from
'bdist --formats=zip' is unusable because it contains
filenames relative to
the root directory)"

Such paths may be OK for Unix (cd / and unzip it,
perhaps?), 
but isn't much good for Windows, where Python might be
installed anywhere.  


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-03-26 16:29

Message:
Logged In: YES 
user_id=11105

Yes. We would have to remove everything except 'rpm' 
and 'wininst' from bdist's available formats lists. But it 
seems the right way to do.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-26 15:52

Message:
Logged In: YES 
user_id=11375

Why not just remove bdist_dumb, then?


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-03-26 15:07

Message:
Logged In: YES 
user_id=11105

IMO it is impossible to create a dumb binary distribution 
which can be used to install a package - even on the same 
platform for different Python versions. So it seems the 
only possibility is document dumb binary distros as broken.

The DISTUTILS TODO list is mainly just a list of thoughts 
from the previous maintainer, nobody (so far) is caring too 
much about it currently.

Assigning to AMK: Andrew, if you think this is ok, let us 
close this bug.

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2002-03-06 21:33

Message:
Logged In: YES 
user_id=149084

I'm not sure what is meant by "everyone should install from
source or the native binary for his platform."  My
understanding is that Distutils was created to provide a
uniform way to install third party packages.

It seems that bdist_dumb has problems building a package
distribution which will install properly.  What about
non-Linux or Windows systems? It rather looks like the code
is unfinished....

To quote the TODO (DISTUTILS 1.1 PLANS):

"* bdist_dumb should grow a little intelligence: let
packager choose 
whether to make archive relative to prefix or the root
(prefix is essential for proper Windows support )"

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-03-05 22:08

Message:
Logged In: YES 
user_id=11105

I expect nobody will install from a zip-file on windows, 
either.

I suggest making bdist_wininst the default bdist format on 
windows and forget this one: Everyone should (will?) 
install either from source, or from the native binary 
distribution for his platform.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 23:54

Message:
Logged In: YES 
user_id=31392

Can you look at this one, Thomas?


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2001-05-28 00:33

Message:
Logged In: YES 
user_id=149084

gztar, ztar, tar, and zip appear to create the same install tree rooted at / . Only the compression differs. (I guess wininst is the intended way to create a Windows distribution.)

The Unix tree contains PythonX.X in its paths, so not only is the full tree NG for Windows, but if someone prepares a bdist package on a Unix system running 2.2, it appears that it is not going to install correctly on a Unix system running 2.1. It is impractical to ask developers to update their Tools distributions for each version of Python, so what to do?

It may be that the bdist paths should be rooted at site-packages, with script installation to prefix/bin. If there are extensions to go into lib-dynload, the path is ../lib-dynload from site-packages.

Then the user would unpack the file in the site-package directory. Note that right now the file names for source and 'binary' distribution are very similar, but the method of installation is different, and this has to be made clear to the user.

GvR seems to be interested in making the install trees the same on Linux and Windows, that would help.

Incidently, the distutils docs say the default is to install relative to prefix, but it appears that that has not been implemented, the default is / . Also, though the docs mention Windows installers, rpms, etc., they don't say anything about install files prepared with bdist. Maybe no one uses bdist?

If there is something I can do here, let me know. It seems it may take some discussion on python-dev first, though.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2001-05-21 22:39

Message:
Logged In: YES 
user_id=11375

I expect no one will install from a .zip file on Unix.

Options:

1) Make both the .tgz and .zip relative to sys.prefix or 
something.
2) Make only the .zip relative.
3) Document this as being broken and forget about it.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=410541&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 17:00:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 09:00:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-535285 ] urllib, fragment identifiers and 404s
Message-ID: <E16puJX-0000p9-00@usw-sf-web4.sourceforge.net>

Bugs item #535285, was opened at 2002-03-26 17:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tadgh O'Leary (tadgher)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib, fragment identifiers and 404s

Initial Comment:
URLOpener raises a 404 IOError accessing a non-existent fragment 
identifier on certain web servers (in fact, all that I've tested, 
except Apache).

I couldn't find any user-agent guidelines, but 
every user-agent I've tested returns the document with a 200 
response code (including lynx).

To repeat:
Python 2.2 (#1, 
Jan 18 2002, 09:22:45) 
[GCC 2.95.3 20010315 (release) 
[FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or 
"license" for more information.
>>> import urllib
>>> 
urllib.URLopener().open('http://www.apache.org/#fake')
<addinfourl 
at 136169196 whose fp = <open file '<socket>', mode 'rb' at 
0x81e7480>>
>>> 
urllib.URLopener().open('http://www.microsoft.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.sun.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.zeus.com/#fake')
Traceback 
(most recent call 
last):
(snipped)
urllib.URLopener().open('http://www.lotus.com/#fake')
Traceback 
(most recent call last):
(snipped)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 18:06:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 10:06:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-535324 ] "if foo=bar:" error-message
Message-ID: <E16pvKd-0001Mg-00@usw-sf-web2.sourceforge.net>

Bugs item #535324, was opened at 2002-03-26 18:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535324&group_id=5470

Category: Parser/Compiler
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
Summary: "if foo=bar:" error-message

Initial Comment:
It would be nice for newbies and tired
programmers if the error-message
of "if foo=bar" should not only be
"SyntaxError: invalid syntax" but 
"SyntaxError: invalid syntax. Expecting =="

thomas



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535324&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 20:05:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 12:05:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-517451 ] Option processing in setup.cfg
Message-ID: <E16pxBv-0002n8-00@usw-sf-web2.sourceforge.net>

Bugs item #517451, was opened at 2002-02-14 06:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470

Category: Distutils
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Konrad Hinsen (hinsen)
Assigned to: A.M. Kuchling (akuchling)
Summary: Option processing in setup.cfg

Initial Comment:
When building RPM files with distutils, I noticed that adding "use_rpm_opt_flags=0" to the file setup.cfg had no effect, although the equivalent command-line option --no-rpm-opt-flags works as advertised.

Some debugging showed the reason: in the first case, the variable self.use_rpm_opt_flags in commands/bdist_rpm.py has the value '0' (string), whereas in the second case it is 0 (integer). The test "if self.use_rpm_opt_flags" does not work as expected if the variable is a string, of course.

I suppose that individual commands should not have to worry about the data type of binary options, so I suspect this is a general bug in distutils option processing.


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-26 15:05

Message:
Logged In: YES 
user_id=11375

Marking as fixed and closing this bug.


----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-21 18:27

Message:
Logged In: YES 
user_id=11375

Actually the Distutils has machinery to handle this; 
however, no one told it that the use_rpm_opt_flags option 
is a Boolean.  Try the attached patch, and let me know if 
it fixes this.  (I'll check it into CVS anyway, since
it's obviously needed, whether or not it fixes your 
problem.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=517451&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 20:35:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 12:35:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-535285 ] urllib, fragment identifiers and 404s
Message-ID: <E16pxex-00008C-00@usw-sf-web1.sourceforge.net>

Bugs item #535285, was opened at 2002-03-26 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470

>Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tadgh O'Leary (tadgher)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib, fragment identifiers and 404s

Initial Comment:
URLOpener raises a 404 IOError accessing a non-existent fragment 
identifier on certain web servers (in fact, all that I've tested, 
except Apache).

I couldn't find any user-agent guidelines, but 
every user-agent I've tested returns the document with a 200 
response code (including lynx).

To repeat:
Python 2.2 (#1, 
Jan 18 2002, 09:22:45) 
[GCC 2.95.3 20010315 (release) 
[FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or 
"license" for more information.
>>> import urllib
>>> 
urllib.URLopener().open('http://www.apache.org/#fake')
<addinfourl 
at 136169196 whose fp = <open file '<socket>', mode 'rb' at 
0x81e7480>>
>>> 
urllib.URLopener().open('http://www.microsoft.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.sun.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.zeus.com/#fake')
Traceback 
(most recent call 
last):
(snipped)
urllib.URLopener().open('http://www.lotus.com/#fake')
Traceback 
(most recent call last):
(snipped)

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-26 21:35

Message:
Logged In: YES 
user_id=43607

The fragment identifier is for "local consumption" only: the way it works for all web browsers is that the URL without 
the fragment identifier is used to retrieve the document, and the identifier is then used to position the browser to the 
correct position in the document.  In other words, you are not supposed to send it to the server.

See section 4.1 of RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) which is the current specification.

I'd say, this is "Not a bug", and so I close this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 21:50:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 13:50:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin
Message-ID: <E16pypO-0000zY-00@usw-sf-web1.sourceforge.net>

Bugs item #497160, was opened at 2001-12-27 21:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_commands assumes ls is in /bin

Initial Comment:
I got this test failure while building Python 2.2:
test test_commands failed -- Traceback (most recent
call last):
  File "./Lib/test/test_commands.py", line 43, in
test_getstatus
    self.assert_(re.match(pat, getstatus("/bin/ls"),
re.VERBOSE))
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

My ls happens to be somewhere other than /bin.  It would
be nice if the test used a different file, such as "/",
".", or even "./Lib/test/test_commands.py".

----------------------------------------------------------------------

>Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 21:50

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 07:12

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-commands.patch>
This regexp test is weaker than the original one, but seems to 
be still stronger than necessary.  If ls is broken here, we
don't care, because it isn't part of Python.  All wee need is
to be able to spawn a shell.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 14:55

Message:
Logged In: YES 
user_id=6380

Assigned to Fred Drake, who wrote the test suite.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 14:54

Message:
Logged In: YES 
user_id=6380

OK, reopening.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2001-12-29 11:55

Message:
Logged In: YES 
user_id=43607

This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed 
and which is still open.
The problem there is that /bin/ls *does* exist, but is a symlink.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 22:42

Message:
Logged In: YES 
user_id=6380

If the patch is so simple, why don't you provide it?

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 22:20

Message:
Logged In: YES 
user_id=412110

The test suite already uses $PATH to *run* ls (as does other
software, which is why I don't get into a lot of trouble).
It merely uses /bin/ls as a filename to pass to ls so it can
check the output.  Any other filename will do just as well
here, and the fix is extremely simple; what's the benefit of
listing /bin/ls in particular that makes it worth risk
breaking on systems like this?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 21:56

Message:
Logged In: YES 
user_id=6380

I think you are going to get in a lot of trouble when
/bin/ls doesn't exist. It's not worth fixing the test suite
for this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 21:52:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 13:52:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
Message-ID: <E16pyro-000114-00@usw-sf-web1.sourceforge.net>

Bugs item #497162, was opened at 2001-12-27 21:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email assumes Unix uses NTP scale

Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
  File "./Lib/test/test_email.py", line 935, in
test_formatdate
    self.assertEqual(gdate, matchdate)
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'

This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock 
values ambiguous, and complicates interval calculations.  
So my clock counts *all* seconds since the epoch.  It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.

----------------------------------------------------------------------

>Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 21:52

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?  (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)



----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-09 00:05

Message:
Logged In: YES 
user_id=412110

A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior.  The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 08:46

Message:
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 14:34

Message:
Logged In: YES 
user_id=6380

Thanks for the patch. I'm assigning this to Barry, who wrote
the test.

Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 07:18

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>

On a separate note, some patches would not be so easy simply
because of the filenames containing spaces.  You might
consider renaming those files.  This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 22:43

Message:
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 22:12

Message:
Logged In: YES 
user_id=412110

Most software will trust localtime() and gmtime() to
interpret the clock.  It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other 
use of the C functions, you check it against a precomputed
string, thus doubting the C functions.  C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.

I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous.  The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility.  By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.

I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them.  This will still fail for
people who use even more exotic setups, but I don't know of
any such.  Is there anything wrong with this?  I think the
benefit easily outweighs the cost.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 21:54

Message:
Logged In: YES 
user_id=6380

I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 22:13:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 14:13:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16pzC5-0001Jv-00@usw-sf-web3.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 22:23:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 14:23:44 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-535450 ] documentation in CHM format
Message-ID: <E16pzM0-0004Lo-00@usw-sf-web2.sourceforge.net>

Feature Requests item #535450, was opened at 2002-03-26 17:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gábor Lipták (gliptak)
Assigned to: Nobody/Anonymous (nobody)
Summary: documentation in CHM format

Initial Comment:
Please add html-help-2.2.chm to the sf.net 
downloadables.

Thanks



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 23:24:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 15:24:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16q0J5-00023V-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 23:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Tue Mar 26 23:25:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 15:25:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16q0Js-000243-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 23:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
>Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 00:25:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 16:25:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-535495 ] threading.RLock memory leak
Message-ID: <E16q1Fl-0002ER-00@usw-sf-web4.sourceforge.net>

Bugs item #535495, was opened at 2002-03-27 00:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535495&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Shane Green (shanegreen)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.RLock memory leak

Initial Comment:
each time a new thread acquires an rlock for the first
time it seems a Condition and a Dummy thread are
allocated to it.  If that thread then dies, the
condition and dummy are never cleaned up.  The code
snipit below will leave 100 instances of Condition and
DummyThread in memory.




import threading
import thread

_lock = threading.RLock()
def run():
  _lock.acquire()
  _lock.release()

for x in range(0, 100):
  thread.start_new_thread(run, ())

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535495&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 01:31:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 17:31:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
Message-ID: <E16q2I4-0006Ln-00@usw-sf-web2.sourceforge.net>

Bugs item #497162, was opened at 2001-12-27 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email assumes Unix uses NTP scale

Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
  File "./Lib/test/test_email.py", line 935, in
test_formatdate
    self.assertEqual(gdate, matchdate)
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'

This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock 
values ambiguous, and complicates interval calculations.  
So my clock counts *all* seconds since the epoch.  It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:31

Message:
Logged In: YES 
user_id=31435

Presumably Barry believed other work had priority.  You're 
running an unusual configuration, and are the only one 
asking for this change.

BTW, Python isn't assuming NTP, it's assuming either POSIX 
compliance (which mandates the results Python is checking 
for) or Mac compliance.  Selling variations is much easier 
when they're backed by common practice or a relevant 
standard.  Right or wrong, neither applies here.  When we 
toss in any old crap someone feels like having, we end up 
with stuff like embedded spaces in filenames <wink>.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:52

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?  (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)



----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-08 19:05

Message:
Logged In: YES 
user_id=412110

A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior.  The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 03:46

Message:
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 09:34

Message:
Logged In: YES 
user_id=6380

Thanks for the patch. I'm assigning this to Barry, who wrote
the test.

Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:18

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>

On a separate note, some patches would not be so easy simply
because of the filenames containing spaces.  You might
consider renaming those files.  This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:43

Message:
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:12

Message:
Logged In: YES 
user_id=412110

Most software will trust localtime() and gmtime() to
interpret the clock.  It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other 
use of the C functions, you check it against a precomputed
string, thus doubting the C functions.  C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.

I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous.  The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility.  By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.

I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them.  This will still fail for
people who use even more exotic setups, but I don't know of
any such.  Is there anything wrong with this?  I think the
benefit easily outweighs the cost.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:54

Message:
Logged In: YES 
user_id=6380

I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 01:41:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 17:41:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-535495 ] threading.RLock memory leak
Message-ID: <E16q2RQ-0006SK-00@usw-sf-web2.sourceforge.net>

Bugs item #535495, was opened at 2002-03-26 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535495&group_id=5470

Category: Threads
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Shane Green (shanegreen)
>Assigned to: Tim Peters (tim_one)
Summary: threading.RLock memory leak

Initial Comment:
each time a new thread acquires an rlock for the first
time it seems a Condition and a Dummy thread are
allocated to it.  If that thread then dies, the
condition and dummy are never cleaned up.  The code
snipit below will leave 100 instances of Condition and
DummyThread in memory.




import threading
import thread

_lock = threading.RLock()
def run():
  _lock.acquire()
  _lock.release()

for x in range(0, 100):
  thread.start_new_thread(run, ())

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:41

Message:
Logged In: YES 
user_id=31435

True, but not a bug.  As the comment block in threading.py 
says,

# Dummy thread class to represent threads not started here.
# These aren't garbage collected when they die,
# nor can they be waited for.

Because threading didn't create these threads, it's 
impossible for threading to know when these threads die.  
As the docs for threading.Thread say, "They are never 
deleted, since it is impossible to detect the termination 
of alien threads."

If you don't want to leak thread structures, don't mix 
thread models:  use the threading module (instead of the 
thread module) to create your threads.  threading.py knows 
when the threads it creates dies, and cleans up after them 
properly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535495&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 01:59:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 17:59:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
Message-ID: <E16q2iV-0006db-00@usw-sf-web2.sourceforge.net>

Bugs item #497162, was opened at 2001-12-27 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Paul Jarc (prjsf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: test_email assumes Unix uses NTP scale

Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
  File "./Lib/test/test_email.py", line 935, in
test_formatdate
    self.assertEqual(gdate, matchdate)
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'

This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock 
values ambiguous, and complicates interval calculations.  
So my clock counts *all* seconds since the epoch.  It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-26 20:59

Message:
Logged In: YES 
user_id=6380

Thanks Tim for explaining it. I take responsibility for
closing this.

Leap seconds: Just Say No.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:31

Message:
Logged In: YES 
user_id=31435

Presumably Barry believed other work had priority.  You're 
running an unusual configuration, and are the only one 
asking for this change.

BTW, Python isn't assuming NTP, it's assuming either POSIX 
compliance (which mandates the results Python is checking 
for) or Mac compliance.  Selling variations is much easier 
when they're backed by common practice or a relevant 
standard.  Right or wrong, neither applies here.  When we 
toss in any old crap someone feels like having, we end up 
with stuff like embedded spaces in filenames <wink>.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:52

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?  (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)



----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-08 19:05

Message:
Logged In: YES 
user_id=412110

A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior.  The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 03:46

Message:
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 09:34

Message:
Logged In: YES 
user_id=6380

Thanks for the patch. I'm assigning this to Barry, who wrote
the test.

Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:18

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>

On a separate note, some patches would not be so easy simply
because of the filenames containing spaces.  You might
consider renaming those files.  This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:43

Message:
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:12

Message:
Logged In: YES 
user_id=412110

Most software will trust localtime() and gmtime() to
interpret the clock.  It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other 
use of the C functions, you check it against a precomputed
string, thus doubting the C functions.  C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.

I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous.  The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility.  By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.

I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them.  This will still fail for
people who use even more exotic setups, but I don't know of
any such.  Is there anything wrong with this?  I think the
benefit easily outweighs the cost.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:54

Message:
Logged In: YES 
user_id=6380

I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 02:26:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 18:26:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16q38r-0003z3-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 03:21:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 19:21:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
Message-ID: <E16q40Z-0004WV-00@usw-sf-web1.sourceforge.net>

Bugs item #497162, was opened at 2001-12-27 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470

Category: Build
Group: Python 2.2
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: test_email assumes Unix uses NTP scale

Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
  File "./Lib/test/test_email.py", line 935, in
test_formatdate
    self.assertEqual(gdate, matchdate)
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'

This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock 
values ambiguous, and complicates interval calculations.  
So my clock counts *all* seconds since the epoch.  It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-26 22:21

Message:
Logged In: YES 
user_id=12800

Thanks Guido and Tim for resolving this.  BTW, the right way
to submit patches is to attach either context or unified
diffs to the bug report using the file upload feature of the
tracker.  Be sure to click on the checkbox too, otherwise
your upload won't get attached (yeah, this sucks).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-26 20:59

Message:
Logged In: YES 
user_id=6380

Thanks Tim for explaining it. I take responsibility for
closing this.

Leap seconds: Just Say No.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:31

Message:
Logged In: YES 
user_id=31435

Presumably Barry believed other work had priority.  You're 
running an unusual configuration, and are the only one 
asking for this change.

BTW, Python isn't assuming NTP, it's assuming either POSIX 
compliance (which mandates the results Python is checking 
for) or Mac compliance.  Selling variations is much easier 
when they're backed by common practice or a relevant 
standard.  Right or wrong, neither applies here.  When we 
toss in any old crap someone feels like having, we end up 
with stuff like embedded spaces in filenames <wink>.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:52

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?  (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)



----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-08 19:05

Message:
Logged In: YES 
user_id=412110

A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior.  The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 03:46

Message:
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 09:34

Message:
Logged In: YES 
user_id=6380

Thanks for the patch. I'm assigning this to Barry, who wrote
the test.

Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:18

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>

On a separate note, some patches would not be so easy simply
because of the filenames containing spaces.  You might
consider renaming those files.  This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:43

Message:
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:12

Message:
Logged In: YES 
user_id=412110

Most software will trust localtime() and gmtime() to
interpret the clock.  It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other 
use of the C functions, you check it against a precomputed
string, thus doubting the C functions.  C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.

I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous.  The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility.  By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.

I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them.  This will still fail for
people who use even more exotic setups, but I don't know of
any such.  Is there anything wrong with this?  I think the
benefit easily outweighs the cost.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:54

Message:
Logged In: YES 
user_id=6380

I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 04:14:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 20:14:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-497162 ] test_email assumes Unix uses NTP scale
Message-ID: <E16q4pK-0004ed-00@usw-sf-web4.sourceforge.net>

Bugs item #497162, was opened at 2001-12-27 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470

Category: Build
Group: Python 2.2
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Guido van Rossum (gvanrossum)
Summary: test_email assumes Unix uses NTP scale

Initial Comment:
I got this test failure while building Python 2.2:
test test_email failed -- Traceback (most recent call
last):
  File "./Lib/test/test_email.py", line 935, in
test_formatdate
    self.assertEqual(gdate, matchdate)
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 286, in failUnlessEqual
    raise self.failureException, \
AssertionError: 'Fri, 09 Nov 2001 17:33:30 -0000' !=
'Fri, 09 Nov 2001 17:33:52 -0000'

This happens because the test assumes that the system
clock is a count of non-leap seconds since the epoch.
This is a common configuration, but it renders some clock 
values ambiguous, and complicates interval calculations.  
So my clock counts *all* seconds since the epoch.  It
would be nice if the test could handle both cases, by
checking the broken-down values around a leap second, or
by checking that the calculated string matches either of
the two possibilities.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-26 23:14

Message:
Logged In: YES 
user_id=31435

Guido, I just want to be clear that the OP is fighting the 
bad effects of leap seconds too.  Leap seconds are part of 
the definition of UTC, but not part of the OP's preferred 
TAI.

POSIX mandates that time_t <-> struct tm conversions be 
computed as if every day had 86400 seconds, but because 
people using NTP (or other sync services) end up having 
clocks displaying UTC, the POSIX standard is forced to add:

"The relationship between the actual time of day and the 
current value for seconds since the Epoch is unspecified."

IOW, POSIX defines localtime() in such a way that there's 
no defined relationship between time_t values and what a 
box believes the time is.

I think POSIX gave up too easily here -- the result is 
unusable for many purposes.  So I sympathize w/ the OP.  At 
the same time, it's not Python's job to repair POSIX's 
shortcomings, and the POSIX rules are at least platform-
independent and predictable.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-26 22:21

Message:
Logged In: YES 
user_id=12800

Thanks Guido and Tim for resolving this.  BTW, the right way
to submit patches is to attach either context or unified
diffs to the bug report using the file upload feature of the
tracker.  Be sure to click on the checkbox too, otherwise
your upload won't get attached (yeah, this sucks).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-26 20:59

Message:
Logged In: YES 
user_id=6380

Thanks Tim for explaining it. I take responsibility for
closing this.

Leap seconds: Just Say No.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-26 20:31

Message:
Logged In: YES 
user_id=31435

Presumably Barry believed other work had priority.  You're 
running an unusual configuration, and are the only one 
asking for this change.

BTW, Python isn't assuming NTP, it's assuming either POSIX 
compliance (which mandates the results Python is checking 
for) or Mac compliance.  Selling variations is much easier 
when they're backed by common practice or a relevant 
standard.  Right or wrong, neither applies here.  When we 
toss in any old crap someone feels like having, we end up 
with stuff like embedded spaces in filenames <wink>.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:52

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?  (Setting $TZ probably isn't entirely reliable;
some machines could have the TAI zones installed without the
right/ prefix.)



----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-08 19:05

Message:
Logged In: YES 
user_id=412110

A different way of handling this, instead of the patch I gave,
would be to set $TZ to something with known behavior.  The
TAI time zones are in right/; things like "US/Eastern" and
"UTC" should work without the patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-01-01 03:46

Message:
Logged In: YES 
user_id=412110

Are the Mac folks aware that the spaces impact everyone else,
not just them?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-31 09:34

Message:
Logged In: YES 
user_id=6380

Thanks for the patch. I'm assigning this to Barry, who wrote
the test.

Re spaces in filenames: I think the only filenames with
spaces in them occur in the Mac subtree, and the Mac folks
insist on having them...

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:18

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-email.patch>

On a separate note, some patches would not be so easy simply
because of the filenames containing spaces.  You might
consider renaming those files.  This bit me when I tried to
patch the 2.1.1 sources up to 2.2 on a machine stuck behind
a slow modem.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:43

Message:
Logged In: YES 
user_id=6380

If you want this fixed, please submit a patch.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:12

Message:
Logged In: YES 
user_id=412110

Most software will trust localtime() and gmtime() to
interpret the clock.  It's only a problem here because
you're testing (and thus doubting) the Python bindings to
those functions, and rather than check it against some other 
use of the C functions, you check it against a precomputed
string, thus doubting the C functions.  C's localtime and
gmtime give correct results on my system, because I'm using
a time zone designed for a clock that counts all seconds.
Don't doubt the C functions; they aren't what you're trying
to test.

I already explained the point of keeping the clock this way
(the TAI scale): it simplifies interval calculations (the
difference t1-t0 actually tells you how many seconds passed
between those times), and it makes no clock values
ambiguous.  The NTP scale (counting only non-leap seconds)
is a horrible bit of backward compatibility.  By depending
on it, you punish those with well-configured systems to
reward those with badly-configured systems.

I mentioned an easy fix, which is to compare the computed
string to each of the values seen above, and to pass the
test if it matches either of them.  This will still fail for
people who use even more exotic setups, but I don't know of
any such.  Is there anything wrong with this?  I think the
benefit easily outweighs the cost.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:54

Message:
Logged In: YES 
user_id=6380

I think a lot of other software will fail too if you set
your clock this way. What's the point? I don't want to
argume too much about this, but I believe that this idea has
been tried before and rejected. So I'm closing this as a
won't fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497162&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 07:55:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 26 Mar 2002 23:55:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-535619 ] HTTPS not working in httplib
Message-ID: <E16q8HP-0007RP-00@usw-sf-web3.sourceforge.net>

Bugs item #535619, was opened at 2002-03-26 23:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535619&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: K. C. Wong (dvusboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPS not working in httplib

Initial Comment:
It appears there is a bug in httplib.py where sendall()
is called on a socket object (line 391). But in the
case of a HTTPSConnection, a socket is actually a
FakeSocket object and the sendall() call will be mapped
to the underlying socket instead of the SSL object,
causing the server to drop connection.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535619&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 09:05:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 01:05:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-535285 ] urllib, fragment identifiers and 404s
Message-ID: <E16q9NK-0002bC-00@usw-sf-web2.sourceforge.net>

Bugs item #535285, was opened at 2002-03-26 17:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tadgh O'Leary (tadgher)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib, fragment identifiers and 404s

Initial Comment:
URLOpener raises a 404 IOError accessing a non-existent fragment 
identifier on certain web servers (in fact, all that I've tested, 
except Apache).

I couldn't find any user-agent guidelines, but 
every user-agent I've tested returns the document with a 200 
response code (including lynx).

To repeat:
Python 2.2 (#1, 
Jan 18 2002, 09:22:45) 
[GCC 2.95.3 20010315 (release) 
[FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or 
"license" for more information.
>>> import urllib
>>> 
urllib.URLopener().open('http://www.apache.org/#fake')
<addinfourl 
at 136169196 whose fp = <open file '<socket>', mode 'rb' at 
0x81e7480>>
>>> 
urllib.URLopener().open('http://www.microsoft.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.sun.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.zeus.com/#fake')
Traceback 
(most recent call 
last):
(snipped)
urllib.URLopener().open('http://www.lotus.com/#fake')
Traceback 
(most recent call last):
(snipped)

----------------------------------------------------------------------

>Comment By: Tadgh O'Leary (tadgher)
Date: 2002-03-27 09:05

Message:
Logged In: YES 
user_id=497284

>the way it works for all web browsers is that the URL >without the fragment 
identifier is used to retrieve the >document
Fair enough. I would have 
seen urllib in the role of "web browser" in this situation, though

>In 
other words, you are not supposed to send it to the >server.

The 
problem here is that URLopener is sending the fragment identifier. If the 
fix is that the user should *always* remove it, then why not let the module 
do the work?

I would have thought most users would expect urllib to 
behave as other user-agents do.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-26 20:35

Message:
Logged In: YES 
user_id=43607

The fragment identifier is for "local consumption" only: the way it works for all web browsers is that the URL without 
the fragment identifier is used to retrieve the document, and the identifier is then used to position the browser to the 
correct position in the document.  In other words, you are not supposed to send it to the server.

See section 4.1 of RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) which is the current specification.

I'd say, this is "Not a bug", and so I close this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 10:24:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 02:24:30 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-517371 ] Add .count() method to tuples
Message-ID: <E16qAbW-0003XC-00@usw-sf-web2.sourceforge.net>

Feature Requests item #517371, was opened at 2002-02-14 08:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=517371&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add .count() method to tuples

Initial Comment:
Tuples have every method afforded to lists except for 
those which mutate the list; however, there is one 
exception:  .count() appears to have been left out 
eventhough it can be well-defined for tuples as well 
as lists.

>>> s = 'the trump'
>>> s.count('t')
2
>>> list(s).count('t')
2
>>> tuple(s).count('t')
Traceback (most recent call last):
  File "<pyshell#12>", line 1, in ?
    tuple(s).count('t')
AttributeError: 'tuple' object has no attribute 'count'


----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2002-03-27 10:24

Message:
Logged In: YES 
user_id=80475

IMHO, the forces pushing toward using lists versus tuples 
should be immutability and performance rather than the 
absence of methods.

Even if being pushed were a feature, a more important 
feature is substitutability -- the ability to develop a 
program using lists and then make a late design decision 
that tuples would have been a better choice.  

Substitutability is unnecessarily impaired by the absence 
of .index() and .count().

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-14 19:33

Message:
Logged In: YES 
user_id=31435

Guido has rejected this idea before, so don't hold your 
breath.  tuples and lists are intended to be used in 
different ways, and it's "a feature" that their differing 
methods push you toward using them as intended.

Note that tuples don't support .index() either, and that's 
also intentional.

Note that you can use the operator.countOf() function on 
tuples (and, in 2.2, on any iterable object).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=517371&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 10:55:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 02:55:12 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-510394 ] Add base classes for numeric types
Message-ID: <E16qB5E-0003u0-00@usw-sf-web2.sourceforge.net>

Feature Requests item #510394, was opened at 2002-01-29 22:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510394&group_id=5470

Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add base classes for numeric types

Initial Comment:
Create a class hierarchy for numeric types (similar to 
the structure for exceptions) so that the following 
work:

issubclass(int,numeric)==1
issubclass(int,real)==1
issubclass(complex,real)==0
isinstance( 3.14, real ) == 1


----------------------------------------------------------------------

Comment By: Gregory Smith (gregsmith)
Date: 2002-02-08 15:14

Message:
Logged In: YES 
user_id=292741

I don't think it's entirely clear whether ints are
a subclass of floats or vice versa, or whether complex
are a subclass of complex, or vice versa, but I'd be
interested to hear reasons. B is a subclass of A makes
sense when there are things you can do to the 'B' as
if it were an 'A'. Clearly, ints (but not longs) are
numerically a subSET of float and float is a subset
of complex; I don't see how that relates to subclassing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=510394&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 11:11:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 03:11:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-535285 ] urllib, fragment identifiers and 404s
Message-ID: <E16qBKy-0000gV-00@usw-sf-web4.sourceforge.net>

Bugs item #535285, was opened at 2002-03-26 18:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470

Category: Python Library
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tadgh O'Leary (tadgher)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib, fragment identifiers and 404s

Initial Comment:
URLOpener raises a 404 IOError accessing a non-existent fragment 
identifier on certain web servers (in fact, all that I've tested, 
except Apache).

I couldn't find any user-agent guidelines, but 
every user-agent I've tested returns the document with a 200 
response code (including lynx).

To repeat:
Python 2.2 (#1, 
Jan 18 2002, 09:22:45) 
[GCC 2.95.3 20010315 (release) 
[FreeBSD]] on freebsd4
Type "help", "copyright", "credits" or 
"license" for more information.
>>> import urllib
>>> 
urllib.URLopener().open('http://www.apache.org/#fake')
<addinfourl 
at 136169196 whose fp = <open file '<socket>', mode 'rb' at 
0x81e7480>>
>>> 
urllib.URLopener().open('http://www.microsoft.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.sun.com/#fake')
Traceback 
(most recent call last):
(snipped)
>>> 
urllib.URLopener().open('http://www.zeus.com/#fake')
Traceback 
(most recent call 
last):
(snipped)
urllib.URLopener().open('http://www.lotus.com/#fake')
Traceback 
(most recent call last):
(snipped)

----------------------------------------------------------------------

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-27 12:11

Message:
Logged In: YES 
user_id=43607

If you really want urllib.urlopen to remove the fragment ID for you, I guess should submit this as a feature request.
I personally don't see urllib.urlopen as a web browser, and hence I don't think it should bother removing the 
fragment ID.
Anyway, not a bug, maybe a feature request.

----------------------------------------------------------------------

Comment By: Tadgh O'Leary (tadgher)
Date: 2002-03-27 10:05

Message:
Logged In: YES 
user_id=497284

>the way it works for all web browsers is that the URL >without the fragment 
identifier is used to retrieve the >document
Fair enough. I would have 
seen urllib in the role of "web browser" in this situation, though

>In 
other words, you are not supposed to send it to the >server.

The 
problem here is that URLopener is sending the fragment identifier. If the 
fix is that the user should *always* remove it, then why not let the module 
do the work?

I would have thought most users would expect urllib to 
behave as other user-agents do.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2002-03-26 21:35

Message:
Logged In: YES 
user_id=43607

The fragment identifier is for "local consumption" only: the way it works for all web browsers is that the URL without 
the fragment identifier is used to retrieve the document, and the identifier is then used to position the browser to the 
correct position in the document.  In other words, you are not supposed to send it to the server.

See section 4.1 of RFC 2396 (http://www.ietf.org/rfc/rfc2396.txt) which is the current specification.

I'd say, this is "Not a bug", and so I close this bug report.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535285&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:17:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:17:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16qCNE-0001UT-00@usw-sf-web4.sourceforge.net>

Bugs item #534153, was opened at 2002-03-24 00:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. Löwis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:21:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:21:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qCR3-000230-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:23:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:23:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16qCSy-0001Yb-00@usw-sf-web4.sourceforge.net>

Bugs item #535474, was opened at 2002-03-27 00:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:23

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:24:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:24:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16qCTu-0001ZO-00@usw-sf-web4.sourceforge.net>

Bugs item #535474, was opened at 2002-03-27 00:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:23

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:26:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:26:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16qCVJ-0001ax-00@usw-sf-web4.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 23:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:26:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:26:56 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-535324 ] "if foo=bar:" error-message
Message-ID: <E16qCW0-00026W-00@usw-sf-web3.sourceforge.net>

Feature Requests item #535324, was opened at 2002-03-26 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Guettler (guettli)
Assigned to: Nobody/Anonymous (nobody)
>Summary: "if foo=bar:" error-message

Initial Comment:
It would be nice for newbies and tired
programmers if the error-message
of "if foo=bar" should not only be
"SyntaxError: invalid syntax" but 
"SyntaxError: invalid syntax. Expecting =="

thomas



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:26

Message:
Logged In: YES 
user_id=21627

Moved into the feature requests tracker.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535324&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:30:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:30:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-534864 ] profiling with xml parsing asserts
Message-ID: <E16qCZD-00024B-00@usw-sf-web1.sourceforge.net>

Bugs item #534864, was opened at 2002-03-25 22:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Aron K. Insinga (ainsinga)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: profiling with xml parsing asserts

Initial Comment:
I'm getting a 'bad call' assertion error when using the
profiler when parsing XML.  (It works ok without the
profiler, and if I don't call SAXparser.parse it
doesn't happen.)


Python 2.2 (#1, Dec 23 2001, 09:30:32)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import t4crash
start document
end document
>>> import profile
>>> t4crash.test()
start document
end document
>>> profile.run('t4crash.test()')
start document
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/profile.py", line 71, in run
    prof = prof.run(statement)
  File "/usr/lib/python2.2/profile.py", line 404, in
run
    return self.runctx(cmd, dict, dict)
  File "/usr/lib/python2.2/profile.py", line 410, in
runctx
    exec cmd in globals, locals
  File "<string>", line 1, in ?
  File "t4crash.py", line 46, in test
    main(files)
  File "t4crash.py", line 39, in main
    SAXparser.parse(fileName)
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 53, in parse
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/xmlreader.py",
line
123, in parse  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 106,
in feed
  File
"/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py",
line 179, in start_element
  File "/usr/lib/python2.2/profile.py", line 214, in
trace_dispatch_i
    if self.dispatch[event](self, frame,t):
  File "/usr/lib/python2.2/profile.py", line 260, in
trace_dispatch_call
    assert rframe.f_back is frame.f_back, ("Bad call",
rfn,
AssertionError: ('Bad call',
('/var/tmp/python2-2.2-root/usr/lib/python2.2/xml/sax/expatreader.py',
95,
'feed'), <frame object at 0x81d5454>, <frame object at
0x81c82e4>, <frame object
at 0x81d50b4>, <frame object at 0x81d5284>)
>>>
[ainsinga@ainsinga index_xml]$ cat t4crash.py
#!/usr/bin/env python2

# t4crash.py by Aron K. Insinga (aron.insinga@av.com)
25-Mar-2002

import xml.sax
import sys
import string
import re


class ContentHandler(xml.sax.ContentHandler):
    """ Handle callbacks from the SAX XML parser. """

    def __init__(selfy):
        pass

    def setDocumentLocator(self, locator):
        pass

    def startDocument(self):
        print 'start document'

    def endDocument(self):
        print 'end document'

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass


def main(files):
    SAXparser = xml.sax.make_parser()
    chand = ContentHandler()
    SAXparser.setContentHandler(chand)
    try:
        for fileName in files:
            SAXparser.parse(fileName)
    except xml.sax.SAXParseException:
        sys.stderr.write("%s; processing aborted\n" %
(xml.sax.SAXParseException))
        sys.exit(1)

def test():
    files = ['doc0.xml']
    main(files)

test()
[ainsinga@ainsinga index_xml]$ cat doc0.xml
<?xml version="1.0" encoding="ISO-8859-1"?>
<html>
  <head>
    <title>Gettysburg Address</title>
  </head>
  <body>
    <p>
      Four score and seven years ago...<br/>
    </p>
  </body>
  <info>
    <author>
     
<lastname>Lincoln</lastname><firstname>Abraham</firstname>
    </author>
    <date>
      <month>11</month><day>19</day><year>1863</year>
    </date>
    <editor /><!-- editor name="aki"/ -->
    <editor/>
  </info>
</html>
[ainsinga@ainsinga index_xml]$ which python
/usr/bin/python
[ainsinga@ainsinga index_xml]$ set | grep PATH
LD_LIBRARY_PATH=/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:/home/ainsinga/adabas/lib:
PATH=$'/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:.:/home/ainsinga/bin:/home/ainsinga/adabas/bin:/home/ainsinga/adabas/pgm:.:/bin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/staroffice6.0:/home/ainsinga/mozilla:~/
staroffice6.0:/home/ainsinga/mozilla'
[ainsinga@ainsinga index_xml]$ set | grep -i py
[ainsinga@ainsinga index_xml]$uname -a
Linux ainsinga 2.4.7-10 #1 Thu Sep 6 17:27:27 EDT 2001
i686 unknown
[ainsinga@ainsinga index_xml]$


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:30

Message:
Logged In: YES 
user_id=21627

I can't reproduce the crash, with 2.3a0.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-25 23:27

Message:
Logged In: YES 
user_id=31435

Assigned to Fred.

----------------------------------------------------------------------

Comment By: Aron K. Insinga (ainsinga)
Date: 2002-03-25 22:19

Message:
Logged In: YES 
user_id=496408

attached is the sample program (which ought to have
indenting preserved!)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534864&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:32:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:32:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16qCbV-0002Ae-00@usw-sf-web3.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:32

Message:
Logged In: YES 
user_id=21627

I can't see why this gives a conflict. When Python loads the
module, it requests the symbol specifically from the shared
library it just loaded. What operating system are you using?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-26 14:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:37:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:37:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-534495 ] PyErr_Format format char bugs
Message-ID: <E16qCg4-000297-00@usw-sf-web1.sourceforge.net>

Bugs item #534495, was opened at 2002-03-25 02:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Skip Montanaro (montanaro)
>Assigned to: Skip Montanaro (montanaro)
Summary: PyErr_Format format char bugs

Initial Comment:
The API docs for PyErr_Format have a slight typo
(I think) and are missing a table entry for the 'p'
format character.  I think the attached patch
corrects that, though since I don't use this
function much, I'm not sure (hence the bug report
instead of just checking in what looks like a 
trivial change).


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:37

Message:
Logged In: YES 
user_id=21627

The patch looks right to me; please check it in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:40:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:40:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-534347 ] Potential AV in vgetargskeywords
Message-ID: <E16qCiq-0002GI-00@usw-sf-web3.sourceforge.net>

Bugs item #534347, was opened at 2002-03-24 17:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential AV in vgetargskeywords

Initial Comment:
If you are dumb enough to do what I just did, pass a 
dictionary with non-string keys to 
PyEval_CallObjectWithKeyWords, you may cause an access 
violation in Python (if the call ends up going through 
PyArg_ParseTupleAndKeywords).  The problem is in the 
section of vgetargskeywords which checks for 
extraneous keyword arguments: it does not check to 
make sure PyString_AsString(key) succeeded.  Attached 
is a simple patch.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:40

Message:
Logged In: YES 
user_id=21627

I think you need to clear the previous exception which is
indicated by the NULL return value (or just let it trough as
is).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 12:54:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 04:54:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes
Message-ID: <E16qCx9-0002Qh-00@usw-sf-web3.sourceforge.net>

Bugs item #534108, was opened at 2002-03-23 21:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: AIX 3.2.5 Has No chroot/fsync Prototypes

Initial Comment:
`make' fails for Python-2.2.1c1 under AIX 3.2.5 due to
lack of prototypes for chroot and fsync in
Modules/posixmodule.c.  configure.in uses
AC_CHECK_FUNCS to check these two can be linked into
an executable, and configure correctly determines they
can.

    $ egrep 'chroot|fsync' config.cache
    ac_cv_func_chroot=${ac_cv_func_chroot='yes'}
    ac_cv_func_fsync=${ac_cv_func_fsync='yes'}
   
However, AC_CHECK_FUNCS essentially compiles and links

    #include "confdefs.h"
    #include <assert.h>
    char chroot();
    int main() {
    chroot();
    ; return 0; }
    
which under AIX 3.2.5 works fine.  But chroot isn't
prototyped in *any* system include file, nor is fsync.
Consequently, Modules/posixmodule.c has problems when
it attempts to use both chroot and fsync as an rvalue
for a pointer to a function.

    return posix_1str(args, "et:chroot", chroot);
    return posix_int(args, "i:fsync", fsync);
    
Both lines cause `Undeclared identifier' errors.
    
The solution is to conditionally add prototypes for
these two functions.  Modules/posixmodule.c has an
icky set of conditional prototypes at the start but 
they rely heavily on __IBMC__, __sun__, etc,
preprocessor symbols.  These could be expanded to
cover AIX 3.2.5's case but it may be better to use
autoconf's AC_CHECK_DECLS macro,
http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52.

By manually adding two prototypes at the start of the
source file I've confirmed the source file builds
successfully.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:54

Message:
Logged In: YES 
user_id=21627

AC_CHECK_DECLS is not supported in autoconf 2.13, so it is
not available for use in Python 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 14:41

Message:
Logged In: YES 
user_id=6656

Hmm, AC_CHECK_DECLS might well be useful (and not just for
these declarations).

However, I'm not an autoconf guru, and really don't want to
have to become one.

Is there a way to identify AIX 3 using the preprocessor?  Or
does AIX 4 not have these prototypes either?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 13:06:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 05:06:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16qD7x-0002TC-00@usw-sf-web1.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 13:38:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 05:38:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16qDd2-0002yW-00@usw-sf-web3.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 13:43:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 05:43:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-534495 ] PyErr_Format format char bugs
Message-ID: <E16qDhz-00032M-00@usw-sf-web3.sourceforge.net>

Bugs item #534495, was opened at 2002-03-24 19:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Skip Montanaro (montanaro)
Summary: PyErr_Format format char bugs

Initial Comment:
The API docs for PyErr_Format have a slight typo
(I think) and are missing a table entry for the 'p'
format character.  I think the attached patch
corrects that, though since I don't use this
function much, I'm not sure (hence the bug report
instead of just checking in what looks like a 
trivial change).


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-03-27 07:43

Message:
Logged In: YES 
user_id=44345

Checked in as version 1.5


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 06:37

Message:
Logged In: YES 
user_id=21627

The patch looks right to me; please check it in.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534495&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 15:33:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 07:33:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qFQF-0007Io-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 16:34:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 08:34:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qGNi-0004xs-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 16:48:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 08:48:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-535619 ] HTTPS not working in httplib
Message-ID: <E16qGaw-0005KE-00@usw-sf-web3.sourceforge.net>

Bugs item #535619, was opened at 2002-03-27 08:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535619&group_id=5470

Category: Python Library
Group: Python 2.1.2
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: K. C. Wong (dvusboy)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTTPS not working in httplib

Initial Comment:
It appears there is a bug in httplib.py where sendall()
is called on a socket object (line 391). But in the
case of a HTTPSConnection, a socket is actually a
FakeSocket object and the sendall() call will be mapped
to the underlying socket instead of the SSL object,
causing the server to drop connection.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:48

Message:
Logged In: YES 
user_id=21627

Duplicate of #531616.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535619&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 16:49:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 08:49:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-521706 ] Python expects __eprintf on Solaris
Message-ID: <E16qGcF-0005LH-00@usw-sf-web3.sourceforge.net>

Bugs item #521706, was opened at 2002-02-23 04:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521706&group_id=5470

Category: Build
Group: Python 2.1.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Greg Kochanski (gpk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python expects __eprintf on Solaris

Initial Comment:
ftp_up.py
Traceback (most recent call last):
  File "/usr/local/bin/ftp_up.py", line 10, in ?
    import ftplib
  File "/usr/local/lib/python2.1/ftplib.py", line 46,
in ?
    import socket
  File "/usr/local/lib/python2.1/socket.py", line 41,
in ?
    from _socket import *
ImportError: ld.so.1: /usr/local/bin/python: fatal:
relocation error: file
/usr/local/lib/python2.1/lib-dynload/_socket.so: symbol
__eprintf: referenced symbol not found


On Solaris 2.6 (current patches), Python 2.1.2
out-of-the-box install.

nm *.a | grep eprintf   shows nothing in /lib and
/usr/lib.  Presumably, the build system is expecting
that function to exist, when it really doesn't.

Same problem on Solaris 2.7:

/usr/local/bin/python
Python 2.1.2 (#1, Jan 23 2002, 10:44:53) [C] on sunos5
Type "copyright", "credits" or "license" for more
information.
>>> import _socket
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ld.so.1: /usr/local/bin/python: fatal:
relocation error: file
/usr/local/lib/python2.1/lib-dynload/_socket.so: symbol
__eprintf: referenced symbol not found
>>> 


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:49

Message:
Logged In: YES 
user_id=21627

Closed for lack of feedback.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-24 00:09

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python, but in your installation.
Python does not, in itself, ever call __eprintf. Instead,
certain versions of gcc emit references to this symbol when
expanding the assert macro. In turn, you need to link such
object files with libgcc.a.

Are you certain that you have build all relevant objects
with the system compiler (including, for example, any
OpenSSL installation)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521706&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 16:52:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 08:52:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-519028 ] make-pyexpat failed
Message-ID: <E16qGfO-0005Nj-00@usw-sf-web3.sourceforge.net>

Bugs item #519028, was opened at 2002-02-18 11:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=519028&group_id=5470

Category: XML
Group: Python 2.1.1
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Chalaoux (copter)
Assigned to: Nobody/Anonymous (nobody)
Summary: make-pyexpat failed

Initial Comment:
Hi,

This the make_pyexpat report after my compilation of 
python 2.1.1 on a sun machine.

Bye

####################################################
>python Lib/test/test_pyexpat.py

OK.
OK.
OK.
OK.
PI:
	'xml-stylesheet' 'href="stylesheet.css"'
Comment:
	' comment data '
Notation declared: ('notation', None, 'notation.jpeg', 
None)
Unparsed entity decl:
	('unparsed_entity', None, 'entity.file', 
None, 'notation')
Start element:
	'root' {'attr1': 'value1', 'attr2': 'value2\xe1
\xbd\x80'}
NS decl:
	'myns' 'http://www.python.org/namespace'
Start element:
	'http://www.python.org/namespace!subelement' {}
Character data:
	'Contents of subelements'
End element:
	'http://www.python.org/namespace!subelement'
End of NS decl:
	'myns'
Start element:
	'sub2' {}
Start of CDATA section
Character data:
	'contents of CDATA section'
End of CDATA section
End element:
	'sub2'
External entity ref: (None, 'entity.file', None)
End element:
	'root'
PI:
	u'xml-stylesheet' u'href="stylesheet.css"'
Comment:
	u' comment data '
Notation declared: (u'notation', None, 
u'notation.jpeg', None)
Unparsed entity decl:
	(u'unparsed_entity', None, u'entity.file', 
None, u'notation')
Start element:
	u'root' {u'attr1': u'value1', u'attr2': 
u'value2\u1f40'}
NS decl:
	u'myns' u'http://www.python.org/namespace'
Start element:
	u'http://www.python.org/namespace!subelement' 
{}
Character data:
	u'Contents of subelements'
End element:
	u'http://www.python.org/namespace!subelement'
End of NS decl:
	u'myns'
Start element:
	u'sub2' {}
Start of CDATA section
Character data:
	u'contents of CDATA section'
End of CDATA section
End element:
	u'sub2'
External entity ref: (None, u'entity.file', None)
End element:
	u'root'
PI:
	u'xml-stylesheet' u'href="stylesheet.css"'
Comment:
	u' comment data '
Notation declared: (u'notation', None, 
u'notation.jpeg', None)
Unparsed entity decl:
	(u'unparsed_entity', None, u'entity.file', 
None, u'notation')
Start element:
	u'root' {u'attr1': u'value1', u'attr2': 
u'value2\u1f40'}
NS decl:
	u'myns' u'http://www.python.org/namespace'
Start element:
	u'http://www.python.org/namespace!subelement' 
{}
Character data:
	u'Contents of subelements'
End element:
	u'http://www.python.org/namespace!subelement'
End of NS decl:
	u'myns'
Start element:
	u'sub2' {}
Start of CDATA section
Character data:
	u'contents of CDATA section'
End of CDATA section
End element:
	u'sub2'
External entity ref: (None, u'entity.file', None)
End element:
	u'root'

Testing constructor for proper handling of 
namespace_separator values:
Legal values tested o.k.
Caught expected TypeError:
ParserCreate() argument 2 must be string or None, not 
int
Caught expected ValueError:
namespace_separator must be at most one character, 
omitted, or None
Failed to catch expected ValueError.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:52

Message:
Logged In: YES 
user_id=21627

Closed for lack of feedback; also irrelevant for Python 2.3,
as this has its expat copy included.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-18 18:52

Message:
Logged In: YES 
user_id=21627

What is the expat version you are using?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=519028&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 16:55:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 08:55:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-534347 ] Potential AV in vgetargskeywords
Message-ID: <E16qGho-0008KN-00@usw-sf-web2.sourceforge.net>

Bugs item #534347, was opened at 2002-03-24 07:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential AV in vgetargskeywords

Initial Comment:
If you are dumb enough to do what I just did, pass a 
dictionary with non-string keys to 
PyEval_CallObjectWithKeyWords, you may cause an access 
violation in Python (if the call ends up going through 
PyArg_ParseTupleAndKeywords).  The problem is in the 
section of vgetargskeywords which checks for 
extraneous keyword arguments: it does not check to 
make sure PyString_AsString(key) succeeded.  Attached 
is a simple patch.


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-03-27 07:55

Message:
Logged In: YES 
user_id=86307

I don't think calling PyErr_Clear is necessary given the 
current implementation; both PyErr_Clear and 
PyErr_SetString ultimately call PyErr_Restore, which clears 
the old error.

As for passing the error through, that might be a better 
choice.  I put in the PyErr_SetString to try to follow the 
behavior of PyEval_EvalCodeEx when it gets non-string keys 
in a keyword dict.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 03:40

Message:
Logged In: YES 
user_id=21627

I think you need to clear the previous exception which is
indicated by the NULL return value (or just let it trough as
is).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 17:16:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 09:16:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-518283 ] Menus and winfo_children() KeyError
Message-ID: <E16qH2M-00057z-00@usw-sf-web4.sourceforge.net>

Bugs item #518283, was opened at 2002-02-16 03:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518283&group_id=5470

Category: Tkinter
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthew Cowles (mdcowles)
Assigned to: Nobody/Anonymous (nobody)
Summary: Menus and winfo_children() KeyError

Initial Comment:
Sent to python-help

If a window has a menubar, sending winfo_children() to
the window produces a KeyError. I'll upload a small
example.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 18:16

Message:
Logged In: YES 
user_id=21627

Thanks for the report; this has been fixed in Tkinter.py 1.161.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518283&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 17:20:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 09:20:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-534347 ] Potential AV in vgetargskeywords
Message-ID: <E16qH67-0000BQ-00@usw-sf-web2.sourceforge.net>

Bugs item #534347, was opened at 2002-03-24 07:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Potential AV in vgetargskeywords

Initial Comment:
If you are dumb enough to do what I just did, pass a 
dictionary with non-string keys to 
PyEval_CallObjectWithKeyWords, you may cause an access 
violation in Python (if the call ends up going through 
PyArg_ParseTupleAndKeywords).  The problem is in the 
section of vgetargskeywords which checks for 
extraneous keyword arguments: it does not check to 
make sure PyString_AsString(key) succeeded.  Attached 
is a simple patch.


----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-03-27 08:20

Message:
Logged In: YES 
user_id=86307

On second thought, perhaps I didn't follow 
PyEval_EvalCodeEx closely enough.  PyString_AsString can 
succeed for some non-string types (unicode, etc.), but 
these keys would not work if passed to PyEval_EvalCodeEx.  
So attached is a second version of the patch which calls 
PyString_Check before calling PyString_AsString. 

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-03-27 07:55

Message:
Logged In: YES 
user_id=86307

I don't think calling PyErr_Clear is necessary given the 
current implementation; both PyErr_Clear and 
PyErr_SetString ultimately call PyErr_Restore, which clears 
the old error.

As for passing the error through, that might be a better 
choice.  I put in the PyErr_SetString to try to follow the 
behavior of PyEval_EvalCodeEx when it gets non-string keys 
in a keyword dict.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 03:40

Message:
Logged In: YES 
user_id=21627

I think you need to clear the previous exception which is
indicated by the NULL return value (or just let it trough as
is).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 18:05:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 10:05:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-516703 ] Tix:NoteBook add/delete/add page problem
Message-ID: <E16qHnU-0006FV-00@usw-sf-web3.sourceforge.net>

Bugs item #516703, was opened at 2002-02-13 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516703&group_id=5470

Category: Tkinter
>Group: Python 2.3
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Christoph Monzel (chris_mo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tix:NoteBook add/delete/add page problem

Initial Comment:
Problem: NoteBook add/delete/add page with the same 
name does not work. python2.2/Tix

Example Python Script for reproducing the Bug:

import Tix
import rlcompleter
root=Tix.Tk()
notebook=Tix.NoteBook(root, ipadx=3, ipady=3)
notebook.add('general', label="General", underline=0)
notebook.add('displaymode', label="Display mode", 
underline=0)
notebook.pack()
notebook.delete('general')
notebook.add('general', label="General", underline=0)
la=Tix.Label(notebook.general,text="hallo")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 
2261, in __init__
    Widget.__init__(self, master, 'label', cnf, kw)
  File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 
1756, in __init__
    self.tk.call(
TclError: bad window path name 
".135915860.nbframe.general"   

Tix seems nothing to know about the new page
>>> notebook.tk.call(notebook._w,'pages')
'displaymode'

Analysis:
in NoteBook.add() the new "same named" widget will
succesfully created in tk. But it will be immediatly 
removed, if the TixSubWidget is constructed

Solution:
In the Notebook class:
Do mark subwidget "destroy_physically=1". Also
for clearness delete entry from subwidget_list dict.
I dont't know if this is a fine or correct solution
but it works (for me)

Patch:
derrick:chris$ diff -u 
/usr/lib/python2.2/lib-tk/Tix.py Tix.py
--- /usr/lib/python2.2/lib-tk/Tix.py    Sun Nov  4 
01:45:36 2001
+++ Tix.py      Tue Feb 12 23:41:50 2002
@@ -828,12 +828,13 @@
     def add(self, name, cnf={}, **kw):
        apply(self.tk.call,
              (self._w, 'add', name) + 
self._options(cnf, kw))
-       self.subwidget_list[name] = 
TixSubWidget(self, name)
+       self.subwidget_list[name] = 
TixSubWidget(self, name, destroy_physically
        return self.subwidget_list[name]   

     def delete(self, name):
+       del self.subwidget_list[name]
        self.tk.call(self._w, 'delete', name) 
-
+       
     def page(self, name):
        return self.subwidget(name)
 


Tix.py Version
# $Id: Tix.py,v 1.4 2001/10/09 11:50:55 loewis Exp $

Tix Version
tix-8.1.3

Tcl/Tk-version
tcl8.3-8.3.3
tk8.3_8.3.3




----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:05

Message:
Logged In: YES 
user_id=21627

This is fixed in Tix.py 1.8. Notice that setting
destroy_physically is not the right thing: that way, the Tcl
widget won't be destroyed at all.

Instead, the problem was that the line

   self.subwidget_list[name] = TixSubWidget(self, name)

would first create the new subwidget, then remove the last
reference to the old subwidget. The __del__ of the old
subwidget would then destroy the Tcl widget. Since the old
widget and the new widget have the same name, this would
delete the new widget. The solution is to explicitly destroy
the subwidget in delete.

----------------------------------------------------------------------

Comment By: Christoph Monzel (chris_mo)
Date: 2002-02-13 00:31

Message:
Logged In: YES 
user_id=456854

Okay, this is my first bug report, and seems not a good
idea to paste patches into the text window :(



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516703&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 18:07:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 10:07:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-516703 ] Tix:NoteBook add/delete/add page problem
Message-ID: <E16qHp6-0006GR-00@usw-sf-web3.sourceforge.net>

Bugs item #516703, was opened at 2002-02-13 00:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516703&group_id=5470

Category: Tkinter
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christoph Monzel (chris_mo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tix:NoteBook add/delete/add page problem

Initial Comment:
Problem: NoteBook add/delete/add page with the same 
name does not work. python2.2/Tix

Example Python Script for reproducing the Bug:

import Tix
import rlcompleter
root=Tix.Tk()
notebook=Tix.NoteBook(root, ipadx=3, ipady=3)
notebook.add('general', label="General", underline=0)
notebook.add('displaymode', label="Display mode", 
underline=0)
notebook.pack()
notebook.delete('general')
notebook.add('general', label="General", underline=0)
la=Tix.Label(notebook.general,text="hallo")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 
2261, in __init__
    Widget.__init__(self, master, 'label', cnf, kw)
  File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 
1756, in __init__
    self.tk.call(
TclError: bad window path name 
".135915860.nbframe.general"   

Tix seems nothing to know about the new page
>>> notebook.tk.call(notebook._w,'pages')
'displaymode'

Analysis:
in NoteBook.add() the new "same named" widget will
succesfully created in tk. But it will be immediatly 
removed, if the TixSubWidget is constructed

Solution:
In the Notebook class:
Do mark subwidget "destroy_physically=1". Also
for clearness delete entry from subwidget_list dict.
I dont't know if this is a fine or correct solution
but it works (for me)

Patch:
derrick:chris$ diff -u 
/usr/lib/python2.2/lib-tk/Tix.py Tix.py
--- /usr/lib/python2.2/lib-tk/Tix.py    Sun Nov  4 
01:45:36 2001
+++ Tix.py      Tue Feb 12 23:41:50 2002
@@ -828,12 +828,13 @@
     def add(self, name, cnf={}, **kw):
        apply(self.tk.call,
              (self._w, 'add', name) + 
self._options(cnf, kw))
-       self.subwidget_list[name] = 
TixSubWidget(self, name)
+       self.subwidget_list[name] = 
TixSubWidget(self, name, destroy_physically
        return self.subwidget_list[name]   

     def delete(self, name):
+       del self.subwidget_list[name]
        self.tk.call(self._w, 'delete', name) 
-
+       
     def page(self, name):
        return self.subwidget(name)
 


Tix.py Version
# $Id: Tix.py,v 1.4 2001/10/09 11:50:55 loewis Exp $

Tix Version
tix-8.1.3

Tcl/Tk-version
tcl8.3-8.3.3
tk8.3_8.3.3




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:05

Message:
Logged In: YES 
user_id=21627

This is fixed in Tix.py 1.8. Notice that setting
destroy_physically is not the right thing: that way, the Tcl
widget won't be destroyed at all.

Instead, the problem was that the line

   self.subwidget_list[name] = TixSubWidget(self, name)

would first create the new subwidget, then remove the last
reference to the old subwidget. The __del__ of the old
subwidget would then destroy the Tcl widget. Since the old
widget and the new widget have the same name, this would
delete the new widget. The solution is to explicitly destroy
the subwidget in delete.

----------------------------------------------------------------------

Comment By: Christoph Monzel (chris_mo)
Date: 2002-02-13 00:31

Message:
Logged In: YES 
user_id=456854

Okay, this is my first bug report, and seems not a good
idea to paste patches into the text window :(



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516703&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 18:53:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 10:53:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-516412 ] Python gettext doesn't support libglade
Message-ID: <E16qIXz-0006qA-00@usw-sf-web3.sourceforge.net>

Bugs item #516412, was opened at 2002-02-12 14:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470

Category: Python Library
>Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christian Reis (kiko_async)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python gettext doesn't support libglade

Initial Comment:
Libglade is a library that parses XML and generates
GTK-based UIs in runtime. It is written in C and
supports a number of languages through bindings.

James Henstridge has maintained a set of bindings for
Python for some time now. These bindings work very
well, _except for internationalization_.

The reason seems now straightforward to me. Python's
gettext.py is a pure python implementation, and because
of it, bindtextdomain/textdomain are never called. This
causes any C module that uses gettext to not activate
the support, and not use translation because of it.

Using Martin's intl.so module things work great, but it
is a problem for us having to redistribute it with our
application. Any other suggestions to fix?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:53

Message:
Logged In: YES 
user_id=21627

This is fixed with

configure 1.291
configure.in 1.301
pyconfig.h.in 1.25
liblocale.tex 1.28
NEWS 1.369
_localemodule.c 2.29

Notice that applications that want to change the C library's
domain bindings will have to invoke locale.bindtextdomain; I
decided not to provide automatic forwarding from
gettext.bindtextdomain to locale.bindtextdomain, since the C
library and Python may have different message catalog
formats (e.g. on Solaris); this might confuse the C library.


----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-02-13 03:15

Message:
Logged In: YES 
user_id=146903

Some libraries (libglade in this case) translate some
messages on behalf of the application (libglade translates
messages in the input file using the default translation
domain, or some other domain specified by the programmer).

This is a case of wanting python's gettext module to
cooperate with the C level gettext library.

For libglade, this could be achieved by making the
gettext.bindtextdomain() and gettext.textdomain() calls to
call the equivalent C function in addition to what they do now.

For most messages in gtk+ itself, it will use dgettext() for
most messages already, so isn't a problem.  The exception to
this is places where it allows other libraries (or the app)
to register new stock items, which get translated with a
programmer specified domain.

As of gettext 0.10.40, there should be no license problems,
as the license for the libintl library was changed from GPL
to LGPL.

It should be a fairly simple to implement this; just needs a
patch :)


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-13 02:17

Message:
Logged In: YES 
user_id=21627

How does gtk invoke gettext? It sounds buggy in the respect
that it expects the textdomain to be set globally; a library
should not do that. Instead, the right thing (IMO) would be
if   gtk called dgettext, using an application-supplied
domain name. It would be then the matter of the Python gtk
wrapper to expose the GTK APIs for setting the text domain.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-02-12 14:52

Message:
Logged In: NO 

If what you want is a way to call bindtextdomain/textdomain
from Python, feel free to supply a patch or ask martin to
add intl.so to the distribution.

--Guido (@#$% SF always logs me out :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=516412&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 19:17:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 11:17:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qIv5-0006T8-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 20:32:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 12:32:06 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-516762 ] have a way to search backwards for re
Message-ID: <E16qK5W-0001B8-00@usw-sf-web2.sourceforge.net>

Feature Requests item #516762, was opened at 2002-02-13 04:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=516762&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Nobody/Anonymous (nobody)
Summary: have a way to search backwards for re

Initial Comment:
There doesn't seem to be any reasonable way to search
a string backwards for a regular expression, starting
from a given character position.  I notice that the
underlying C regular expression implemention supports
a direction flag.

I propose adding a direction flag to the search function
on match objects:

r = re.compile(...)
m = re.search(str, startpos=5000, endpos=-1, dir=-1)

would search in str for r, starting at
location 5000 and searching backwards through
location 0 (the beginning of the string).

This is useful in (for example) text editors where
you want to be able to search forwards or backwards,
or if you're parsing an html file and see a </table>
and want to find the matching <table>, etc.

phr


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 21:32

Message:
Logged In: YES 
user_id=21627

Moved to feature requests tracker.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=516762&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 20:34:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 12:34:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16qK7m-0001Ct-00@usw-sf-web2.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 06:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
>Assigned to: Martin v. Löwis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 08:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 18:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 18:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 20:36:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 12:36:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin
Message-ID: <E16qK9I-0001E7-00@usw-sf-web2.sourceforge.net>

Bugs item #497160, was opened at 2001-12-27 21:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470

Category: Build
Group: Python 2.2
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_commands assumes ls is in /bin

Initial Comment:
I got this test failure while building Python 2.2:
test test_commands failed -- Traceback (most recent
call last):
  File "./Lib/test/test_commands.py", line 43, in
test_getstatus
    self.assert_(re.match(pat, getstatus("/bin/ls"),
re.VERBOSE))
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

My ls happens to be somewhere other than /bin.  It would
be nice if the test used a different file, such as "/",
".", or even "./Lib/test/test_commands.py".

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-27 20:36

Message:
Logged In: YES 
user_id=6656

No attempt was made to fix this for 2.2.1c2.

I didn't make fixing little bugs in the tests a priority, 
sorry.

I don't think it's been fixed on the trunk.

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 21:50

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 07:12

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-commands.patch>
This regexp test is weaker than the original one, but seems to 
be still stronger than necessary.  If ls is broken here, we
don't care, because it isn't part of Python.  All wee need is
to be able to spawn a shell.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 14:55

Message:
Logged In: YES 
user_id=6380

Assigned to Fred Drake, who wrote the test suite.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 14:54

Message:
Logged In: YES 
user_id=6380

OK, reopening.

----------------------------------------------------------------------

Comment By: Sjoerd Mullender (sjoerd)
Date: 2001-12-29 11:55

Message:
Logged In: YES 
user_id=43607

This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed 
and which is still open.
The problem there is that /bin/ls *does* exist, but is a symlink.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 22:42

Message:
Logged In: YES 
user_id=6380

If the patch is so simple, why don't you provide it?

----------------------------------------------------------------------

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 22:20

Message:
Logged In: YES 
user_id=412110

The test suite already uses $PATH to *run* ls (as does other
software, which is why I don't get into a lot of trouble).
It merely uses /bin/ls as a filename to pass to ls so it can
check the output.  Any other filename will do just as well
here, and the fix is extremely simple; what's the benefit of
listing /bin/ls in particular that makes it worth risk
breaking on systems like this?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 21:56

Message:
Logged In: YES 
user_id=6380

I think you are going to get in a lot of trouble when
/bin/ls doesn't exist. It's not worth fixing the test suite
for this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 20:47:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 12:47:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qKKn-0001Or-00@usw-sf-web1.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Christian Tismer (tismer)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 20:59:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 12:59:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes.
Message-ID: <E16qKVt-0007XS-00@usw-sf-web4.sourceforge.net>

Bugs item #510868, was opened at 2002-01-30 20:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Sharad Satsangi (sharadinfozen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 2.7 make chokes.

Initial Comment:
I'm building python2.2 on a Solaris2.7 box, an Ultra-
10.

I get a segmentation fault error at 'xreadlines' when 
I try the make.

I am not sure why.

Logs of the configuration script & make are attached. 
(in one concatenated file, I could not tell how to 
upload more than one file).

Any help will be greatly appreciated.

thanks!
-sharad.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 21:59

Message:
Logged In: YES 
user_id=21627

Can you offer an account on this machine? I'd like to
investigate it "life".

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-04 23:02

Message:
Logged In: YES 
user_id=443851

I tried downgrading gcc to 2.95.3, however, it still craps 
out at the same place, and according to backtrace, it is 
still quitting in the same place.

I've attached the logs.

We've successfully built python on another box, keeping the 
project that was in jeopardy moving forward, however, I 
would still very much like to find out how to install 
python correctly on this problem box.

thanks,
-sharad.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 12:38

Message:
Logged In: YES 
user_id=21627

That looks very much like a miscompilation. Notice that
initreadline is supposed to pass a first string of
"readline" to InitModule4; in the gdb backtrace, we see an
empty string. Likewise, the invalid address comes from the
methods argument to InitModule4, fetching ml_name. These are
all static strings, compiled into an array (namely,
readline.c:readline_methods).

So I really recommend to downgrade the compiler (or use the
Sun system compiler if you have it); if you are interested
in a work-around, here are two options:
- build readline statically into the Python interpreter. Do
so by uncommenting the readline line in Modules/Setup
(adding libraries as necessary)
- do not build the readline module at all; do so by adding
'readline' into setup.py:disabled_module_list.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 23:15

Message:
Logged In: YES 
user_id=443851

I've done a full backtrace on it (see gdbout2), but I 
really don't know how to interpret the results.  From what 
I can tell, the problem lies in this area:
#1  0x20f00 in PyString_FromString (
    str=0x7e1138 <Address 0x7e1138 out of bounds>)
    at Objects/stringobject.c:112
#2  0xad7dc in PyDict_SetItemString (v=0x7e1138,
    key=0x7e1138 <Address 0x7e1138 out of bounds>, 
item=0x17d350)
    at Objects/dictobject.c:1879

Unfotunately, I can't tell what's going wrong in these 
source files, and when I tried 'p str' on the var 
referenced in line #1, I get: 
$1 = 0x7e1138 <Address 0x7e1138 out of bounds>
which does not explain much to me.


I have tried the package at SunFreeWare's site, but my 
developer needs the 'HTTPSConnection' from 'httplib', which 
apparently is _not_ built into the sunfreeware package.

So, any input, again, would be greatly appreciated.  

I realise you must be a busy guy, thanks for all of your 
help & patience!
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 21:26

Message:
Logged In: YES 
user_id=21627

Ok, gcc 3.0.3 itself could be a source of problems, but I
won't accuse that compiler prematurely (you might want to
try 2.95.x, though, if you have that readily available).

As for the gdb analysis: that it crashes is strlen is not
the problem; strlen is the innocent C library function that
computes the length of the string. Please invoke the command
"bt" when it crashes; that should tell you the backtrace
(i.e. where strlen is called from) - please report that.

If you want to investigate further: "up" brings you up a
stack-level, and "p varname" prints a variable.

This approach to debugging may take many more rounds, so I'd
understand if you are ready to give up (sunfreeware has
2.1.1 binaries). It's just that it builds fine for me (on
Solaris 8, using gcc 2.95.2), so I have no clue as to what
the problem might be. Did you pass any options to ./configure?

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 17:04

Message:
Logged In: YES 
user_id=443851

Thanks for the gdb tip, I've switched to the solaris7 pkg 
for gdb.  The version info for gcc does not explicitly list 
what flavor of Solaris it's built for, but the version 
number is 3.0.3, and it reads it's specs 
from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.7/3.0.3/specs, which leads me to believe that it's 
built for solaris7.  

Anywho, after some freaking around with env var's & gdb, I 
got the following output (see gdbout).  It leads me to 
believe that the problem is in /usr/lib/libc.so.1, but I'm 
not sure how to replace/update this lib, or even if it is 
indeed the source of my python misery.

Any input or guidance would be appreciated.

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 11:36

Message:
Logged In: YES 
user_id=21627

It would be good if you could analyse this with gdb further.
I recommend to obtain a more recent copy of gdb (e.g. gdb
5.0), in particular one compiled for your system (the one
you have is compiled for Solaris 2.4). You can get get
binaries from sunfreeware.com (although they don't have gdb
5 for Solaris 7; you might want to try the 4.18 that they do
have).

The important thing is that you need to run the setup.py
under gdb. To do this, please invoke the setup.py line
manually. I.e. if the makefile invoke

ENV1=val1 ENV2=val2 python-command python-options arguments

you will need to perform the following commands

ENV1=val1
ENV2=val2
export ENV1 ENV2
gdb python-command
run python-options arguments

As a side point, what is the exact gcc version that you are
usingq (gcc -v)? If that also is not a gcc for Solaris 7, I
recommend to re-install the compiler, or use the system
compiler.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-01-31 22:09

Message:
Logged In: YES 
user_id=443851

I did try gdb on the python binary, but got nothing 
interesting (you can see in the file gdbpyth).  

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-31 18:35

Message:
Logged In: YES 
user_id=21627

Can you attach to Python with gdb and see why it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 21:04:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 13:04:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qKac-0001YH-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Christian Tismer (tismer)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 21:55:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 13:55:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qLOY-0000ST-00@usw-sf-web3.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Christian Tismer (tismer)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 21:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 21:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 22:00:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 14:00:45 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-507262 ] GNU --option syntax not supported
Message-ID: <E16qLTJ-0008GR-00@usw-sf-web4.sourceforge.net>

Feature Requests item #507262, was opened at 2002-01-23 00:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Jari Aalto (jaalto)
Assigned to: Nobody/Anonymous (nobody)
Summary: GNU --option syntax not supported

Initial Comment:
It would be good if the python interpreter 
supported standard GNU --log style options as
well.

Jari

//root@W2KPICASSO /usr/bin $ python -V
Python 2.2
//root@W2KPICASSO /usr/bin $ python --help
Unknown option: --
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Try `python -h' for more information.
//root@W2KPICASSO /usr/bin $ python -h    
usage: python [option] ... [-c cmd | file | -] 
[arg] ...
Options and arguments (and corresponding environment 
variables):
-c cmd : program passed in as string (terminates 
option list)
-d     : debug output from parser (also PYTHONDEBUG=x)
-E     : ignore environment variables (such as 
PYTHONPATH)
-h     : print this help message and exit
-i     : inspect interactively after running script, 
(also PYTHONINSPECT=x)
         and force prompts, even if stdin does not 
appear to be a terminal
-O     : optimize generated bytecode (a tad; also 
PYTHONOPTIMIZE=x)
-OO    : remove doc-strings in addition to the -O 
optimizations
-Q arg : division options: -Qold (default), -Qwarn, -
Qwarnall, -Qnew
-S     : don't imply 'import site' on initialization
-t     : issue warnings about inconsistent tab usage (-
tt: issue errors)
-u     : unbuffered binary stdout and stderr (also 
PYTHONUNBUFFERED=x)
-U     : Unicode literals: treats '...' literals like 
u'...'
-v     : verbose (trace import statements) (also 
PYTHONVERBOSE=x)
-V     : print the Python version number and exit
-W arg : warning control (arg is 
action:message:category:module:lineno)
-x     : skip first line of source, allowing use of 
non-Unix forms of #!cmd
file   : program read from script file
-      : program read from stdin (default; interactive 
mode if a tty)
arg ...: arguments passed to program in sys.argv[1:]
Other environment variables:
PYTHONSTARTUP: file executed on interactive startup 
(no default)
PYTHONPATH   : ':'-separated list of directories 
prefixed to the
               default module search path.  The result 
is sys.path.
PYTHONHOME   : alternate <prefix> directory (or 
<prefix>:<exec_prefix>).
               The default module search path uses 
<prefix>/pythonX.X.
PYTHONCASEOK : ignore case in 'import' statements 
(Windows).


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 23:00

Message:
Logged In: YES 
user_id=21627

Moved to the feature requests tracker.

----------------------------------------------------------------------

Comment By: Jari Aalto (jaalto)
Date: 2002-03-10 09:02

Message:
Logged In: YES 
user_id=65014


Sorry for the typo: I meant "GNU 'long' style options",
it would be good if there were legible options like

-h  => --help

Although Python is not GNU program, the "--long" style
option usage is "de facto" accepted in almost everywhere.

I would see it a good addition to Python.




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-09 15:03

Message:
Logged In: YES 
user_id=6380

Rather than quoting the Python -h output (with which I am
quite familiar, thank you!), you could explain what --log is
supposed to do. What does it do and why do you want it? (BTW
Python is not GNU software.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=507262&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 22:03:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 14:03:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-501022 ] Python/Tkinter crashes
Message-ID: <E16qLWP-0008IT-00@usw-sf-web4.sourceforge.net>

Bugs item #501022, was opened at 2002-01-08 22:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470

Category: Tkinter
Group: Python 2.1.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: John W Lewis (lewisjwl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python/Tkinter crashes

Initial Comment:
Good morning

This issue was reported earlier, but I could not provide
a concrete example.

The following little program crashes under Windows 2000 Pro, but not on UNIX.
My PC has 2GB of memory and the program is using much less than that.
It appears to be exhausting some fixed resource (a heap?).

Microsoft will debug the problem if they can analyze the dump file 
to isolate the specific system calls which exhaust that resource.
Right now all they can tell is that the fault occurs somewhere in Tkinter.
They have asked me to provide the following:
* Dr Watson dump file
* MPS profile
* perfmon log

How should I proceed? How can I get a PC version of python
with a full symbol table for debugging?

Regards
John Lewis
jlewis9@csc.com
443-562-4945 cell


-----------------------------------------------------------------------------------
## PROGRAM: crash.py
## HISTORY: jw lewis, 1/8/01
## OBJECTIVE
##   Write a program which causes Tkinter to fail abnormally in Windows

from Tkinter import *

root = Tk()

log = open("log.txt","w")

## Force crash by generating too many PhotoImage objects
images = []
for i in xrange(0,10000):
    if i>9900:
        log.write( str(i)+"\n" )
        log.flush()
    image = PhotoImage()
    image.put("blue")
    images.append( image )
-----------------------------------------------------------------------------------

Resulting log.txt file

9901
9902
9903
...
9950
9951
9952
9953
9954
9955
9956
9957
9958
9959
CRASH

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 23:03

Message:
Logged In: YES 
user_id=21627

It seems that no further information will become available;
closing the report. 

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-08 22:36

Message:
Logged In: YES 
user_id=21627

As I mentioned before, my best guess is that it runs out of
bitmap handles.

Anyway, download the Python source code, and read the
document in PCbuild/readme.txt to find out how to generate
debugging information. You may want to build tcl/tk with
debugging as well, but I don't know how to do that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=501022&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 22:10:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 14:10:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-495672 ] xml.AttributesImpl: __setitem__ undef.
Message-ID: <E16qLcS-0008Nn-00@usw-sf-web4.sourceforge.net>

Bugs item #495672, was opened at 2001-12-21 00:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.AttributesImpl: __setitem__ undef.

Initial Comment:
[please CC 120343@bugs.debian.org on replies; the 
complete report can be seen at 
http://bugs.debian.org/120343]

xml.sax.xmlreader.AttributesImpl does not have a 
__setitem__ defined.
The definition is trivial (or AttributesImpl could be 
written to extend
UserDict), but its lack is a minor annoyance when 
writing an XML filter.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 23:10

Message:
Logged In: YES 
user_id=21627

Closing as not-a-bug.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-12-22 16:13

Message:
Logged In: YES 
user_id=21627

Why is this a bug? The Attributes interface in SAX is
inherently read-only, both in Java and in Python. For a
filter, write a new dictionary containing all the values
that you want to forward, and create an AttributesImpl
instance from this dictionary.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495672&group_id=5470


From noreply@sourceforge.net  Wed Mar 27 22:18:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 14:18:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qLkb-0002Tk-00@usw-sf-web1.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Christian Tismer (tismer)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 22:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 21:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 21:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 00:02:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 16:02:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16qNNM-0001DJ-00@usw-sf-web4.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 17:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Mike Coleman (mkc)
Date: 2002-03-27 18:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 15:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 00:06:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 16:06:18 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qNQo-0003sn-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 00:35:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 16:35:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qNsn-0004Bg-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 01:17:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 17:17:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qOXk-0004Nw-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Christian Tismer (tismer)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 01:20:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 17:20:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qOao-0002gj-00@usw-sf-web3.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 01:44:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 17:44:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-444129 ] python20 dll not found
Message-ID: <E16qOxv-0004gM-00@usw-sf-web2.sourceforge.net>

Bugs item #444129, was opened at 2001-07-25 01:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470

Category: Windows
Group: Irreproducible
>Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: python20 dll not found

Initial Comment:
after upgrading from 2.0 to 2.1 then to 2.1.1 getting 
error that cant find python20.dll. I completely 
removed all traces of python and did a fresh install 
even modified the registry and removed all instances 
of python and pywin. It is important to note that I 
also removed an re-installed win32all and it failed to 
completely install because this error. Another note 
though python will still run after the error is given 
the win32 extensions fail to load. I am running on 
japaneese version of win2000 but had the same problem 
on the english version(the steps mentioned fixed the 
problem on english version).

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 12:44

Message:
Logged In: YES 
user_id=14198

This is stale, and never since reported.  I suspect a
problem with the specific win32all build used.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-07-30 03:02

Message:
Logged In: YES 
user_id=14198

I am reading this, but still travelling.  I have no idea 
off the top of my head, but suspect that Tim's latest "leap-
frog" idea could explain it.  I will check this out when I 
return.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-28 11:33

Message:
Logged In: YES 
user_id=6380

I wouldn't be surprised if it had something to do with this
kind of leapfrog installation sequence:

1. install Python 2.0
2. install win32all for Python 2.0
3. install Python 2.1
4. uninstall Python 2.0

But there are so many variations...  Mark, are you reading
this?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-28 10:34

Message:
Logged In: NO 

Well, I guess this is the end of this saga as far as I am 
concerned.  I re-installed Windows 2000, and everything 
worked fine.  We could conclude that it was Windows 2000, 
but could it be something in the win32all or a combination 
of the operating system AND win32all????

Anyway, thanks to all of you again for your help.  If you 
look into this any further and find out anything new, I 
would love to be told what it was.

Thanks again!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-27 05:20

Message:
Logged In: NO 

That sounds good to me.  I will re-install Windows and try 
to install python 2.1 anew..........will let you know what 
happens.  It should be interesting.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-27 01:32

Message:
Logged In: YES 
user_id=31435

I'm reopening this, at least until MarkH has a chance to 
look at it.  While some Windows Mysteries never get solved, 
you can't tell which those are in advance <wink>.

Anonymous, I also would like to know what's going on, but 
you have a unique problem (never reported before), and one 
I can't reproduce.  But my experience w/ win32all is 
trivial.  That's why I want MarkH (win32all's author) to 
see this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 01:13

Message:
Logged In: YES 
user_id=6380

Bugs of this nature almost *always* end up being caused by
some local bizarrity of the Windows configuration, not by
something the Python installer could have prevented.  The
fact that others in your company have the same problem (but
no-one outside your company has reported this) suggests that
it could be some kind of network management problem.

Good luck!

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-27 01:07

Message:
Logged In: NO 

True, we may have screwed something up, but this is not 
what caused the problem in the first place.  In other 
words, there is a bug somewhere that should be fixed.  The 
fact that we may have screwed something up in trying to 
resolve it is not only irrelevant but it also does not mean 
the bug is gone.  Others in my company have had the same 
problem but were able to get around the bug.  Sure, close 
the bug report; we will start from scratch and, well, 
hopefully the mysterious bug will not come up again.........
Nevertheless, a big THANK YOU for your gracious 
intervention and attempts at solving this.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-27 00:57

Message:
Logged In: YES 
user_id=6380

It sounds like you have screwed something over by your
manual interventions.  I suggest that we close this bug
report and you reinstall Windows.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-27 00:52

Message:
Logged In: NO 

No we do not use a PYTHONSTARTUP file.  Furthermore, I 
figured I would quit tryint to use 2.1 and go with 2.0. 
Well, guess what, when I try to use 2.0, it says it cannot 
find python21.dll.  But when I try to use 2.1 (the reason 
to write to you guys), it says it cannot find the 
python20.dll ???????????????????????????????????
Note that I have manually deleted everythinng, checked the 
registers, etc, etc, etc.  But obviously, something is 
hidden somewhere or there is something else going on.  I, 
too, think that it may have to do with the win32 extension, 
but the whole thing is a huge mystery.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-26 03:41

Message:
Logged In: YES 
user_id=31435

Assigned to Mark:  can you make sense of this?  I have to 
figure it has *something* to do with win32all, because this 
is the only report of its kind, and the -v output below 
shows that the base distribution is acting normally in all 
respects, including getting to the interactive prompt 
without trouble.

Anonymous, do you use a PYTHONSTARTUP file?  I asked 
before, but didn't hear back.  That's the only way I know 
of in the std distribution to execute some Python code at 
startup that doesn't get mentioned in the -v outpout.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-26 02:49

Message:
Logged In: NO 

Here is the exact output displayed upon executing "python -
v"

E:\Python21>python -v
# E:\Python21\lib\site.pyc matches E:\Python21\lib\site.py
import site # precompiled from E:\Python21\lib\site.pyc
# E:\Python21\lib\os.pyc matches E:\Python21\lib\os.py
import os # precompiled from E:\Python21\lib\os.pyc
import nt # builtin
# E:\Python21\lib\ntpath.pyc matches E:\Python21
\lib\ntpath.py
import ntpath # precompiled from E:\Python21\lib\ntpath.pyc
# E:\Python21\lib\stat.pyc matches E:\Python21\lib\stat.py
import stat # precompiled from E:\Python21\lib\stat.pyc
# E:\Python21\lib\UserDict.pyc matches E:\Python21
\lib\UserDict.py
import UserDict # precompiled from E:\Python21
\lib\UserDict.pyc
Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
>>>


Here is the additional error that appears displayed in a 
Windows dialog box.  I
have not typed it in "exactly" as it appears.  The dots 
(...........) below represent
a bunch of lines with directory paths:

Dialog Box Title: Dynamic Library python20.dll path not 
found

============================================================
Dynamic Library python20.dll path not found.
e:\su5j\security\test\bin...................................
............................................................
..........
............................................................
............................................................
...............................
e:\Program Files\Microsoft Visual Studio\Common\msdev98
\BIN\;T:\tools\bin;
c:\ATF
============================================================


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-25 05:12

Message:
Logged In: YES 
user_id=31435

I can't reproduce this on my system -- I see no problems at 
all.  Can you capture the full output from running python -
v and attach it to this report?  I know exactly what's on 
my box, but can only guess about what's on yours.  There 
are lots of clues in -v output that would help me. 
*Somehow* you're picking up an obsolete component, but 
there are no such components in the PythonLabs distribution.

Note that "I then uninstalled 2.0" will cause registry 
entries to get restored to what they were at the time you 
first installed 2.0; that will wipe out the registry 
entries you created if you installed 2.1.1 before 
uninstalling 2.0.  Anything relying on the registry *may* 
get screwed by that.  Our (PythonLabs) distribution doesn't 
use the registry for much, but win32all may.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-25 04:14

Message:
Logged In: NO 

Okay lets get more specific after installing 2.1.1 on top 
of 2.0 it worked I then uninstalled 2.0 and the error is 
back "python20.dll not found". I ran with -v option and the 
last lib to load before the error is UserDict. If I install 
2.0 then 2.1.1 I seem to be ok with python then but if I 
try to install win32all it complains and fails stating 
incompatible dll message. 
Starting over I have uninstalled everything and re-
installed 2.1.1 and have the same problem.
the command I am running is...
c:\python21\python.exe -v

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-25 03:35

Message:
Logged In: NO 

As of my last attempt I was running nothing but BeOpen 
pyhton 2.1.1 (no third party libraries)on a clean system. 
The error occurs when I run python from the command line or 
IDLE. I rolled back to 2.0 then installed 2.1.1 on top of 
it just now and it seemed to fix python. I then installed 
win32all 140 and the install script throws a similar error 
saying "module use of python20.dll conflicts with this 
version of python".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-25 03:07

Message:
Logged In: YES 
user_id=31435

Then we need more specific information from you.  I've 
never heard of this and find it difficult to believe that 
anything in the std Python 2.1 distribution requires 
python20.dll.  I just removed all traces of all Pythons 
from my Win2K box, installed a fresh 2.1.1, and ran the std 
test suite to completion without any problems.

Exactly what do you do that triggers a msg about 
python20.dll?  If I can't reproduce it (and so far I 
can't), all we can do is guess.

Do you perhaps have your own customizations in a 
PYTHONSTARTUP file that may be trying to access obsolete 
stuff?

Have you tried running Python with -v to get a trace of 
what it's trying to import?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-07-25 03:00

Message:
Logged In: YES 
user_id=6380

Sorry to butt in...  Are you perhaps trying to use a third
party extension like PIL or Numeric Python?  Or your own? 
Extensions built for one Python version won't work with
another.

Can you tell us exactly what you did that gave the error
message?  Preferably with the path to the executable that
you are trying to run that gives the exception.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-25 02:54

Message:
Logged In: NO 

I am in fact not using the wrong version of win32all, the 
problem occurs prior to the install of the extensions. And 
it is correct that the 2.0 dll's are not installed and 
python2.1.1 (or 2.1) is complaining about it. I originaly 
thought the same thing so I removed win32all and 
python2.1.1 unloaded the dll's and re-installed 2.1.1 prior 
to re-installing win32all I got the same errors.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-07-25 02:34

Message:
Logged In: YES 
user_id=31435

It sounds like you're trying to use Python 2.1.1 with a 
version of win32all built for 2.0.  If so, you can't do 
that -- Python 2.1.x supplies python21.dll, not 
python20.dll.

Go to ActiveState's site and either install ActivePython 
from them (which comes with a matched set of components), 
or get build 140 of win32all.exe from them (which was built 
to work with Python 2.1 -- but won't work with Python 2.0).

Feel free to reopen this bug report if that doesn't solve 
it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=444129&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 02:00:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 18:00:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-432501 ] Problem with urllib and proxies / Win32
Message-ID: <E16qPCq-0002Oc-00@usw-sf-web4.sourceforge.net>

Bugs item #432501, was opened at 2001-06-13 04:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432501&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Mark Hammond (mhammond)
Summary: Problem with urllib and proxies / Win32

Initial Comment:
There's a problem with urllib on Windows. Here's a
quote which relates to the problem:

"""
In the newest version of the urllib.   They added a
section which pulls the http web_proxy from the
windows NT registry.         Unfortunately they did not
think to check for 127.0.0.1 and remove it from
the proxy list and they also did not handle (no proxy
addresses).  As a result the new library reads the
proxy settings from the Windows NT Registry for IE and
attempts to use them.
"""

Any thoughts on how to solve this ?


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 12:59

Message:
Logged In: YES 
user_id=14198

This patch appears to have been addressed in checkin 1.129
of urllib.py.  Checkin message, by tim_one, is:

SF patch #403640: incomplete proxy handling in URLLIB
Look specific to Windows.  Don't know whether it works.


----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-06-13 17:38

Message:
Logged In: YES 
user_id=14198

Looking at the code, I suspect "blah_proxy" will disable 
the registry.  This will setup the scheme "blah://" to use 
a proxy, and avoid the registry code completely.  
As "blah://" is invalid, http etc requests should work fine.

While I agree in general with the fact that localhost 
should never be proxied, that makes this bug no longer 
Window specific, and not related to the IE code at all.  
Hence I am probably not the best person to have this 
assigned to - if you want it fixed that is :)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-06-13 17:28

Message:
Logged In: YES 
user_id=38388

Well the point is that if you have IE configured to use a
proxy then urllib will automagically use it for all
requests. This is obviously not ideal for certain requests
like one to the localhost.

Looking at the code I cannot find any way to switch off
proxies by using environment variables (ok, you can specify
"http_proxy=",
but that will only result in an error that the proxy is not
found).

So in the end, I think this is a bug in the sense that you
cannot turn proxy handling off and a feature request in the
sense that it should be possible to turn it off ;-)

IMHO, the localhost and 127.0.0.1 should always be excluded
from the proxy handling.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-06-13 16:17

Message:
Logged In: YES 
user_id=14198

This is not a problem with the win32 proxy detection code, 
but with urllib in general.

urllib itself does not handle the concept of "proxy exclude 
list", and nor does it handle the localhost case - if a 
proxy is configured, it uses it.

So either you are after an enhancement to urllib to allow 
certain addresses to bypass the proxy, or a technique to 
allow the registry to be ignored.  I believe the latter can 
be handled by setting "ignored_proxy=something" in the 
environment.

Can you clarify exactly what you want here?  If it is the 
urllib enhancement then I am not the best person for this - 
I don't have a proxy server available, and don't have much 
code that uses urllib.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=432501&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 02:02:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 18:02:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-536017 ] threading.Lock().acquire bug
Message-ID: <E16qPFO-0004sH-00@usw-sf-web2.sourceforge.net>

Bugs item #536017, was opened at 2002-03-28 13:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Fiona Lim (fionalim)
Assigned to: Nobody/Anonymous (nobody)
Summary: threading.Lock().acquire bug

Initial Comment:
According to the online documentation for threading
Lock objects, setting blocking=0 will produce a
non-blocking call.
But trying it in the command line causes the execution
to hang.
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(blocking=0)
>>> lock.acquire(blocking=0)
[blocks]

----------------------------------
internal documentation claims that the keyword is wait,
but using wait produces the same problem:

>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire.__doc__
'acquire([wait]) -> None or
Boolean\n(PyThread_acquire_lock() is an obsolete
synonym)\n\nLock the lock.  Without argument, this
blocks if the lock is already\nlocked (even by the same
thread), waiting for another thread to release\nthe
lock, and return None when the lock is acquired.\nWith
a Boolean argument, this will only block if the
argument is true,\nand the return value reflects
whether the lock is acquired.\nThe blocking operation
is not interruptible.'
>>> lock.acquire(wait=0)
>>> lock.acquire(wait=0)
[blocks]

---------------------------------
Not using a keyword works fine:
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(0)
1
>>> lock.acquire(0)
0
>>> 



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 02:05:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 18:05:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-478339 ] Linking/compiling with DEBUG
Message-ID: <E16qPIN-0002SN-00@usw-sf-web4.sourceforge.net>

Bugs item #478339, was opened at 2001-11-06 02:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478339&group_id=5470

Category: Windows
Group: Python 2.1.1
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: Linking/compiling with DEBUG

Initial Comment:
I have an embedded use of the Python interpreter. I
want to compile and link the encapsulating application with
and without DEBUG. I have disabled the use of the
pragma in config.h to always use the library specified
in the link statement, which is always the standard
python library. I have ensured that all invocations of
Python.h undefine the DEBUG symbol before including them.

Compiling the application without debug: works fine if
you link non-debug. However, linking with debug causes
some change in the way python modules are looked up and
I'm getting undefined local modules. I have checked the
PYTHONPATH environment variable and it is correct, and
the .py module exists in the correct directory. (This
is a common scenario where some libraries are compiled
without DEBUG, some with DEBUG, and then the whole
application linked DEBUG.)

Compiling the application with debug: Link errors
result. Undefined -- _Py_RefTotal, _Py_Dealloc,
_PyInitModule4TraceRefs.

Python is making too many hidden assumptions about the
build environment when it is being used embedded. This
is a critical problem as it makes it impossible to
build the encapsulating application for debug purposes.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 13:05

Message:
Logged In: YES 
user_id=14198

I believe there is no intention to "fix" this - it is by
design.  Even if we overcome the memory API issues, the fact
we pass FILE * pointers around is still going to be a
problem for some users.

Please reopen if you feel this is wrong.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-13 20:09

Message:
Logged In: YES 
user_id=21627

MS doesn't document it as a complete list; I still believe
it is a complete list. Of course, you have no reason to
trust me more than you trust Microsoft :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-13 15:52

Message:
Logged In: YES 
user_id=31435

Martin, where does MS document "all known problems with 
combining CRTs"?  The KB article you referenced before 
(Q140584) says "There are many ways to get into trouble 
with two CRTs. Here are just a few:", and then lists the 
same three specific examples that have been brought up in 
this bug report.  There's not a clue there about what the 
rest of the many ways may be.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-13 01:18

Message:
Logged In: NO 

(Not anonymous: Jeff Kotula, Vital Images, Inc.)

"Bug" is probably not the right classification. I believe
it is a weakness in the configuration management though.

Here's the problem: As a client of the C API, I want to
be able to create a static library that is compiled
with DEBUG and/or _DEBUG and be able to select either
the debug or non-debug version of the python library
independently. This helps me stay as close as possible to
production-level configuration even when debugging some
parts of the system.

>From your preceding discussion it sounds like the only
real barrier to this is the coupling of _DEBUG to Py_DEBUG.
If this is the case, it should be a small matter to
decouple the two. Changing the layout of objects could also
be avoided simply by always including the reference counting
field -- would it be that big of a percentage increase in
object size?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-12 08:23

Message:
Logged In: YES 
user_id=21627

Why does the linker report no error if expat.dll is
integrated into a debug build? Because the conflict is
detected only for object files compiled with different
settings; the linker doesn't look into DLLs to see what CRT
they use.

I believe MS documented all known problems with combining
CRTs; this is an issue that occurs in many projects, and all
aspects are well-understood. Since pyexpat doesn't export
any CRT objects created by expat, there is no problem with
using expat.dll in a debug build.

Anonymous, given all this information, do you still think
there is a bug in Python? If so, can you please explain from
scratch what this problem is (stating only what you believe
to be facts)? If not, I propose to close this report as
"Won't fix".

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-12 06:49

Message:
Logged In: YES 
user_id=31435

Martin, the MS docs also say the linker generates a warning 
if you mix CRT types -- but it doesn't for mixing debug 
Python with expat or Tcl/Tk.  I don't always believe 
everything in the MS docs <wink>.  But, Mark, I do believe 
them when they say you're on thin ice, and they really 
don't document the ways in which mixing CRTs can be 
disastrous (they give three specific examples, "just a few" 
of "many [unspecified] ways to get into trouble").

Mark, I like _d fine!  It's better than MS's plain "d" 
convention (which I've seen other projects mimic), and so 
long as there *is* a reason that mixing debug and release 
builds can be catastrophic, it's Good to make it painfully 
obvious that something potentially catastrophic is going on 
(note that Anonymous starting getting in trouble when 
he "disabled the use of the pragma in config.h" -- we spent 
most of this bug report trying to convince him the pragma 
wasn't there just to irritate him <wink>).

M and M, I don't *know* that expat.dll and Tcl/Tk work fine 
with a debug Python.  All I've ever done with expat.dll 
then is run our test suite, and that simply doesn't crash; 
and I probably haven't run any Tcl/Tk scripts under a debug 
Python in years.

Mark, I suspect debug Python builds are extremely rare on 
Unix, even among Python developers.  For example, for more 
than a year, I believe I'm the only one who has found test-
suite failures specific to the debug build.

But "compile for debugging" to Unixoids usually means some 
combination of not defining NDEBUG, retaining symbol info, 
and/or cranking down optimization.  The Unix libraries 
don't care about that stuff -- there's nothing there as 
Draconian as the MS-specific _DEBUG effect on libraries.

Martin, It Hurts to tell people not to use _DEBUG on 
Windows:  as a prime example, the MS _DEBUG malloc+free are 
indispensable debugging tools, and indeed have caught bugs 
in Python that escaped even efence.  Users want that for 
their code too.

I don't know where this leaves us.  Probably right where we 
started, except we know better that we're lost <wink>.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-12 01:18

Message:
Logged In: YES 
user_id=21627

On Linux, it is common to include debug information into
every  library and executable; in particular, it is common
to install python with debugging information. This is
possible since debugging information can be combined with
optimization almost seamless in gcc (distributors often
strip the debugging information, though).

So you use Py_DEBUG *only* when you want to do the refcount
debugging. You have to configure --with-pydebug for that,
and you never do that in the wild. *If* you would install a
pydebug binary, you would use a different --prefix, so that
it would not interfere with the standard installation.
Depending on which pyconfig.h extensions pick up, they would
then be suitable for use with one or the other installation.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-11-11 21:37

Message:
Logged In: YES 
user_id=14198

*sigh* - forgot that the object layout changed :(

Re malloc issues: they are indeed still a problem - but 
Python will not *force* you to do this.  It used to be the 
case that an extension module would malloc an object, and 
whatever module did the final Py_DECREF (often the core) 
would perform the free().  I believe this is no longer 
true.  It *is* still true with FILE objects and the 
tp_print slot IIRC.

My point with the "_d" was that iff we can get things 
working so that the standard Python extensions 
are "safe", "_d" need not imply anything other than "the 
preferred extension for debug builds of the core" - and 
even that is only for b/w compat and convenience reasons.

How has Linux survived so long?  I assume Py_DEBUG builds 
are simply never made in the "wild".

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-11 21:27

Message:
Logged In: YES 
user_id=21627

I thought the problem with memory blocks still exists: If
you malloc with the debug CRT, and free with the nodebug
CRT, you get a leak. At least Q140584 claims the problem
still exists in 6.0sp5. In addition to memory and files,
they also notice that setting the locale in one CRT doesn't
affect the other.

I still cannot tell whether Anonymous builds a DLL wrapper
or a static library around pythonxy.dll.If it was a DLL, it
would be indeed equivalent to the pyexpat case. However, in
that case, linking Python wouldn't matter at all to the
clients of his or her DLL, since the reference to
pythonxy.dll/pythonxy_d.dll would be only in the wrapper DLL.

Re: decoupling _DEBUG and Py_DEBUG. How exactly would that
work? Would a _d extension imply _DEBUG, or Py_DEBUG, or
would we stop using _d? 

If it would imply _DEBUG, I cannot understand Mark's comment
"Individual extensions would be responsible for setting
Py_DEBUG via their makefiles in debug builds.  This should
be stable." You have to use Py_DEBUG consistently throughout
all modules because it changes the struct _object layout.
Mixing them certainly isn't stable.

Perhaps we could try to completely avoid changing
PyObject_HEAD depending on Py_TRACE_REFS, and make it a type
flag instead. In that case, you could, at run-time, mix
objects that do trace_refs, and objects that don't.




----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-11-11 20:15

Message:
Logged In: YES 
user_id=14198

The problem only occurs when the 2 DLLs must cooperate WRT 
CRT resources.  Eg, if a "FILE *" was ever passed and used 
across the expat->Python boundary, or a memory block 
allocated in one to be freed in the other, then we would be 
in the same situation.  This probably doesn't happen for 
expat and Tk.  For Python and its extension modules (and 
even embedders), it may.

IIRC, the problem with memory blocks was solved some time 
ago, leaving FILE* the only real problem.  File objects are 
used in only 1 or 2 cases, and these could be solved by 
moving to "PyFile_Write()" style APIs.

So, I guess I could agree a good solution is to ensure that 
Python C API does not require CRT resource sharing, and 
that Py_DEBUG is defined independently of _DEBUG or DEBUG.  
Individual extensions would be responsible for setting 
Py_DEBUG via their makefiles in debug builds.  This should 
be stable.

This would blur the _d convention.  I quite like it, but I 
agree it is a PITA for many people.  We could try giving 
pythonxx_d.dll the ability to load non _d versions, in the 
hope that the extensions have been "fixed" so they don't 
directly share the CRT.

Tim - never quite understood your feelings on _d - what are 
your thoughts?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-11 17:15

Message:
Logged In: YES 
user_id=31435

Martin and Mark, I want to play devil's advocate here just 
a bit:  How do we get away with, e.g., using expat.dll in 
Windows Python?  That is, we use the same expat.dll with 
the release and debug Python builds.  Nothing bad happens 
that I've seen, and we don't get warnings about mixing CRT 
types either.  IOW, we use expat.dll the way Anonymous 
would like to use the Python DLL.  How do we get away with 
that?

If that one is easy <wink>, ee don't use different versions 
of the Tcl/Tk libraries either.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-10 21:13

Message:
Logged In: YES 
user_id=21627

The second rule should read

Linking with python_d -> compile client code with _DEBUG
since Python does not care whether DEBUG is defined or not;
it only cares about _DEBUG (i.e. /MDd, as you point out).

Furthermore, the second dependcy is also thanks to
Microsoft: If you compile your library with /MDd, you must
also compile all client code with /MDd, see MSKB Q140584).
Python currently supports two configurations on Windows:
1. Neither of _DEBUG, Py_DEBUG is defined; link with
pythonxy.dll and msvcrt.dll (i.e. /MD); extensions end with
.pyd or .dll
2. Both _DEBUG, Py_DEBUG are defined, link with
pythonxy_d.dll and msvcrtd.dll, extensions end with _d.pyd
or _d.dll.

It would be possible to create a third configuration:
_DEBUG is defined, but Py_DEBUG isn't. Link with a no-debug
pythonxy.dll, but with msvcrtd.dll. You couldn't use the
existing pythonxy.dll and existing extension modules, since
those already link with msvcrt.dll. Adding such a
configuration would increase the mess, so it won't happen.

I'd advise you to pursue a fourth configuration: Do not use
the debug CRT (i.e. compile with /MD instead of /MDd), even
if you compile your own library for debugging. With that
configuration, you can use the standard Python distribution
with no changes.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-10 06:30

Message:
Logged In: NO 

Turns out the _DEBUG is defined when using the /MDd
compiler option.

We have painstakingly worked out our build system to
deal with the library conflicts you mention. If I
understand what you're saying, these are the rules:

Linking with debug CRT -> link with python_d
Linking with python_d -> compile client code with DEBUG

The first rule is thanks to MS. The second rule is to
get internal object layouts to match up.

Is this right?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-10 05:17

Message:
Logged In: YES 
user_id=21627

I'm glad the PYTHONPATH issue is resolved.

On the _DEBUG issue: Somebody *must* be defining _DEBUG
somewhere, or else the #ifdef would not trigger. Please open
the MSVC++ project file of your project (the .dsp file) in a
text editor, and search for _DEBUG. 

If you cannot find it there, please try to activate full
command line printing in your build process, so that you see
what options are passed to the compiler. 

If you are absolutely sure that _DEBUG is not passed in the
command line, it must be defined in one of the header files.
In this case, please put the #ifdef _DEBUG block of the
previous test after each #include, e.g. in a form

#include <stdio.h>
#ifdef _DEBUG
#error After stdio.h
#endif

#include <nextfile.h>
#ifdef _DEBUG
#error After nextfile.h
#endif

I'm sure there are better ways to find out where _DEBUG is
defined; don't hesitate to apply them if you are aware of any.

Once you found the location of _DEBUG, you may remove it to
be able to use the standard Python .DLL. 

Please make sure you understand Mark's comment on CRTs,
though: Many problems will occur if you mix the debug and
the nodebug version of the MSVC libraries (e.g. msvcrt.dll
and msvcrtd.dll). Please see the Microsoft documentation for
details: If you use pythonxy.dll, you absolutely *must* make
sure that you do not link the debug versions of the CRT,
even when performing a debug build. Unfortunately, you won't
get a compilation error if you do not follow this guideline;
instead, very hard-to-debug problems will occur. You can use
depends.exe on the final executable to analyse the set of
libraries used.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-10 03:16

Message:
Logged In: NO 

Compiling without debug worked fine with the additional
#ifdefs. Compiling with DEBUG resulted in the _DEBUG
message and the Py_Debug message.


sys.path seems to be ok now in all configurations. One
of the (many) experimental changes to the build I did
must have bypassed the problem.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-10 02:51

Message:
Logged In: YES 
user_id=21627

In your code that includes Python.h, can you please add the
lines

#ifdef _DEBUG
#error You must not define _DEBUG
#endif
#ifdef Py_DEBUG
#error For some reason Py_DEBUG is still defined
#endif

immediately after the
#include <Python.h>

line? Then please compile your library with DEBUG, and
report whether it compiles correctly; if not, please report
the errors it gives.

Furthermore, could you please evaluate the string

"import sys;print sys.path"

in your embedded code and report the exact output that this
gives when running with and without DEBUG?

Without the results of these specific experiments, I do not
think we can help much.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-10 02:16

Message:
Logged In: NO 

I guess I'm not making myself very clear. Let me try again...

I have a library that completely encapsulates all use of
Python.h from my clients. I need to be able to debug this
library by compiling it with DEBUG. I do not want to use
the debug Python library. Unfortunately, just compiling
the Python headers with DEBUG seems to change the object
layout and require the use of the debug library.

BTW, the sys.path values include my PYTHONPATH values when
I link non-debug, and they are the default relative path
values when I link with debug. I know the code looks like
it doesn't ignore PYTHONPATH (I've looked through
getpathp.c too) but something is screwing up sys.path.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2001-11-09 12:09

Message:
Logged In: YES 
user_id=14198

There is not much I can add here.  I understand and 
appreciate your concerns.  However, as Tim and Martin have 
stated, something is missing from the puzzle.  PYTHONPATH 
is *not* ignored in debug builds.

The reason for the _d is 2-fold:
* As Martin said, the object layout may change.
* The Python core and extensions sometimes share CRT 
objects - notably file handles, and in some cases memory 
blocks.  It is critical that these come from the same CRT.

I could possibly agree that the "_d" convention is dumb and 
should be dropped.  However, it is unclear to me that this 
bug can be simply summarised as this.  This is probably 
because it is unclear to me how this bug can be summarised 
at all :)

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 10:28

Message:
Logged In: YES 
user_id=21627

AFAICT, PYTHONPATH is *not* ignored when running a debug
build. If you think it is, please run the debug and the
nodebug interpreter (i.e. python.exe and python_d.exe), and
report the values of sys.path for either case.

More likely, the cause of your problems is that the import
code looks for different DLL name *in sys.path*. I.e. when
you do 
import foo
in a nodebug build, it will try to find foo.pyd or foo.dll.
In a debug build, it will try to find foo_d.pyd or
foo_d.dll. So if you only have foo.pyd, then importing foo
will fail if Python was compiled with _DEBUG. 

Again, this is by design: foo.pyd might crash the debug
interpreter, since the object layout is different.

If you merely want to single-step through the Python
runtime, without making use of the Py_DEBUG features, you
should build the release version of Python, but activate the
generation of debug symbols.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-09 07:03

Message:
Logged In: NO 

You'll have to excuse the editorializing: I've found working
with the C API immensely frustrating in a variety of ways,
and then to have my empirical observations dismissed...

Let me step back and explain where I am right now.

I've built the 2.1 debug version of the python library using
the source distribution. When doing a final link without
debug (regardless of how all my client code was compiled)
I use the non-debug version of the Python library. When
doing a final link with debug (again, regardless of how all
of my client code is compiled) I use the debug version of
the python library. To get the latter scenario to work, I
edit the registry -- as well as the PYTHONPATH -- before
initializing python through the C API. For these two
cases, my unit tests run correctly to completion.

However, this means that our developers must compile the
library I wrote that wraps up the Python C API to match
how they are going to link it. I would like to find a way
around this constraint so that any combination of compiling
and linking my wrapper library works correctly.

(Let me also mention that I am aware that you are all
volunteers and I do appreciate your efforts. I am hopeful
that by resolving issues such as this Python can be made
more easy to use in a wider variety of circumstances.)

Thanks.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-09 06:49

Message:
Logged In: YES 
user_id=31435

Anonymous, editorializing doesn't really help.  I 
understand that you want Python to work in a way other than 
it does, and repeating that isn't necessary.  I'm hoping 
Mark Hammond will comment on that.

In the meantime, I'm trying to determine why you're seeing 
the symptoms you are seeing.  I believe you're seeing them, 
but your analysis doesn't make sense, therefore something 
is going on you haven't told us about.  What *should* 
happen in your ideal world isn't relevant to determining 
what's actually happening.  Take this one step at a time, 
please.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-09 06:20

Message:
Logged In: NO 

It's not a question of *believing* that PYTHONPATH is
ignored: that is the observed behavior! (I am using
2.1.1.)

Whether I compile my client code with debug or not should
have nothing to do with what Python library I include.
(Note that I'm talking about *my* client code, not
compiling Python itself.) The Python #includes should not
be selecting a library for me, but should let me specify it
in my build environment. This is the way virtually every
3rd-party library is set up for both Windows and *nix
systems and the way I expected Python to behave. Whether
or not Windows defines _DEBUG shouldn't matter either --
I should have independent control. (I even when to the
lengths of undeffing DEBUG, _DEBUG, and Py_Debug prior to
including any Python headers -- still didn't help.)

Keep in mind that Python is not the core of my application.
It doesn't control the main loop. In fact I entirely
encapsulate the C API to Python so that my clients can
define commands without ever having to include Python.h
themselves. Python is just one piece of a very large system
(and a replacable piece at that) and can't dictate build
or compile requirements.

I'll check the system libraries, but I'm pretty sure they
are the multithreaded versions. (I think I'd be seeing
different symptoms if I had the wrong system libraries.)
Unfortunately, I can't send you samples due to
confidentiality concerns. Rest assured, however, that
I am describing the problems accurately.

Try it yourself! Uninstall python, just retaining the
normal link libraries and dlls and the headers. Now build
an application using just the C API. Not as simple as it
sounds (or is with competing tools such as Tcl).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-09 06:19

Message:
Logged In: NO 

It's not a question of *believing* that PYTHONPATH is
ignored: that is the observed behavior! (I am using
2.1.1.)

Whether I compile my client code with debug or not should
have nothing to do with what Python library I include.
(Note that I'm talking about *my* client code, not
compiling Python itself.) The Python #includes should not
be selecting a library for me, but should let me specify it
in my build environment. This is the way virtually every
3rd-party library is set up for both Windows and *nix
systems and the way I expected Python to behave. Whether
or not Windows defines _DEBUG shouldn't matter either --
I should have independent control. (I even when to the
lengths of undeffing DEBUG, _DEBUG, and Py_Debug prior to
including any Python headers -- still didn't help.)

Keep in mind that Python is not the core of my application.
It doesn't control the main loop. In fact I entirely
encapsulate the C API to Python so that my clients can
define commands without ever having to include Python.h
themselves. Python is just one piece of a very large system
(and a replacable piece at that) and can't dictate build
or compile requirements.

I'll check the system libraries, but I'm pretty sure they
are the multithreaded versions. (I think I'd be seeing
different symptoms if I had the wrong system libraries.)
Unfortunately, I can't send you samples due to
confidentiality concerns. Rest assured, however, that
I am describing the problems accurately.

Try it yourself! Uninstall python, just retaining the
normal link libraries and dlls and the headers. Now build
an application using just the C API. Not as simple as it
sounds (or is with competing tools such as Tcl).


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-09 04:48

Message:
Logged In: YES 
user_id=31435

Well, Martin is right, you know:  if you're not defining 
_DEBUG, and not letting MSVC define it either, then neither 
will pyconfig.h define Py_DEBUG, and it gets harder and 
harder to believe that what you're reporting is the full 
truth.

Perhaps you could attach a tiny example, along with the 
MSVC project file, or Makefile, you use.  It may well be 
academic, though, as it's *normal* for _DEBUG to get 
defined under MSVC in a debug build (and whether or not you 
add it explicitly -- as Martin implied, you would have had 
to explicitly remove _DEBUG from the MSVC auto-generated 
list of preprocesser debug-build #defines).

In answer to one of your earlier questions, PYTHONPATH is 
not ignored after a debug link.  I understand that you 
believe it is, but I expect that's another illusion due to 
something you haven't told us-- or not discovered --yet.  
Perhaps you're linking with the wrong system libraries?  
Python requires the multithreaded libraries.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 04:33

Message:
Logged In: YES 
user_id=21627

What Python version are you using? You mentioned that you've
changed the pragma in config.h; atleast since Python 1.5.2,
this macro depends on _DEBUG, not on DEBUG. So if you didn't
define _DEBUG, you wouldn't need to change the pragma.Python
never changes its behaviour based on whether DEBUG is
defined, AFAICT.

Please check the project settings for the debug target in
your application again.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-09 04:22

Message:
Logged In: NO 

The only debug-type symbol I am defining when compiling my
code is DEBUG. I'm not deliberately defining _DEBUG or
Py_Debug.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-09 04:09

Message:
Logged In: YES 
user_id=21627

AFAICT, even on Windows, defining DEBUG does not change
anything whatsoever. It is only when you define _DEBUG that
things start to change.

I'm not sure whether this is a bug or a feature: If you just
want to enable debugging in your application, just don't
define _DEBUG. Notice that MSVC does that for you unless you
tell it not to. AFAICT, _DEBUG is what Microsoft uses in the
libraries to indicate "enable all debugging code that you
have". So Python enables Py_DEBUG.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-09 03:43

Message:
Logged In: YES 
user_id=31435

Changed Category to Windows, since I'm almost certain 
that's the missing info here.

Assigned to MarkH hoping he has a slick <wink> reply.  This 
kind of complaint comes up rarely but regularly, and I'm 
never sure what to say:  since I build Python from source, 
and always did, our Windows debug scheme is fine by me.  
But what are pure end-users expected to do?

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-09 01:10

Message:
Logged In: NO 

I'm not recompiling the Python libraries. I am only
recompiling my personal libraries which use the Python
C API. I want to be able to compile my libraries with
debug and use the standard Python library.

This is not a "flawed" approach. It is extremely common
when using 3rd-party libraries to do this. Python should
be using a separate #define for its ref-counting debug
stuff so that clients can use the standard library and
still debug their own stuff.

Refer to my second comment regarding the use of PYTHONPATH
for another example of non-transparent substitution of
the debug and non-debug libraries.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-11-08 09:11

Message:
Logged In: YES 
user_id=21627

I cannot understand what bug you are reporting. Of the
things you report, which of them did you not expect?

For example, that Py_RefTotal is undefined when you compile
with DEBUG, but link with the no-debug library is not a bug,
but by design: those functions are used in every debug
module, but available only in the debug library.

Your complete compilation approach is flawed: If you compile
with pydebug, you absolutely *must* link with the debug
library: the object layout of every object will change, so
crashes are likely if you link with the wrong library.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-11-06 04:29

Message:
Logged In: NO 

More info: I've now narrowed it down to the fact that when
the final link is done with debug, the PYTHONPATH
environment variable is ignored altogether. In my case, I
cannot rely on the registry being set up for Python, and the
system is resorting to the default relative path names
(which, in my case, are of no use).

How does the behavior of the (non-debug) python library know
to change based on the final link? And why is PYTHONPATH
ignored if it is linked in debug?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=478339&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 02:15:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 18:15:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qPRt-0002YO-00@usw-sf-web4.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 03:31:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 19:31:40 -0800
Subject: [Python-bugs-list] [ python-Bugs-536017 ] threading.Lock().acquire bug
Message-ID: <E16qQdY-0005nY-00@usw-sf-web2.sourceforge.net>

Bugs item #536017, was opened at 2002-03-27 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470

>Category: Documentation
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Fiona Lim (fionalim)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: threading.Lock().acquire bug

Initial Comment:
According to the online documentation for threading
Lock objects, setting blocking=0 will produce a
non-blocking call.
But trying it in the command line causes the execution
to hang.
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(blocking=0)
>>> lock.acquire(blocking=0)
[blocks]

----------------------------------
internal documentation claims that the keyword is wait,
but using wait produces the same problem:

>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire.__doc__
'acquire([wait]) -> None or
Boolean\n(PyThread_acquire_lock() is an obsolete
synonym)\n\nLock the lock.  Without argument, this
blocks if the lock is already\nlocked (even by the same
thread), waiting for another thread to release\nthe
lock, and return None when the lock is acquired.\nWith
a Boolean argument, this will only block if the
argument is true,\nand the return value reflects
whether the lock is acquired.\nThe blocking operation
is not interruptible.'
>>> lock.acquire(wait=0)
>>> lock.acquire(wait=0)
[blocks]

---------------------------------
Not using a keyword works fine:
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(0)
1
>>> lock.acquire(0)
0
>>> 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-27 22:31

Message:
Logged In: YES 
user_id=31435

Changed to docs and assigned to Fred for comment.  Any idea 
how we can make this clearer?  The docs don't claim this 
accepts a keyword argument, and lots of C functions simply 
ignore any keyword arguments that may be given.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 03:37:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 19:37:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-481284 ] GetFileSecurity returns wrong SID
Message-ID: <E16qQin-0005ze-00@usw-sf-web1.sourceforge.net>

Bugs item #481284, was opened at 2001-11-14 00:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470

Category: Windows
Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Ruben Marquez (rrm1)
Assigned to: Mark Hammond (mhammond)
Summary: GetFileSecurity returns wrong SID

Initial Comment:
The following code printes PySID:S-1-0x008014000000 for
every file on any machine, independent of the real 
ower of the file:

for f in glob.glob("d:/*.*"):
    try:
        o =
win32security.GetFileSecurity
(f,win32security.OWNER_SECURITY_INFORMATION)
        s = win32security.SID(o)
        print str(s),
    except:
        print "n/a",
    print "   ",f

----------
Interestingly,

def prsid(name):
    import string
    print string.rjust(name,20),
    try:
        sid,box,what=win32security.LookupAccountName
(None,name)
        print str(sid),box,what
    except:
        print "oops"

Works well, so it doesn't seem to be a problem with 
PySIDs.

Thanks for your help in resolving this.

P.S.: (Discussed in http://groups.google.com/groups?
hl=en&th=b808d773d7ba0fee)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 14:37

Message:
Logged In: YES 
user_id=14198

This is not a bug.  The SID() function does not take a
SECURITY_DESCRIPTOR.  The fact it *seems* to is an artifact
of a SECURITY_DESCRIPTOR implementing the buffer protocol,
and the fact that SID() can be constructed with a buffer
assumed to be valid SID bits.  Thus, your code is attempting
to create a SID from the bits in the SECURITY_DESCRIPTOR.

The code should change to:
    o =
win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION)
    s = o.GetSecurityDescriptorOwner()

s is not the SID of the owner of the file.  There is also
GetSecurityDescriptorGroup(), etc.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-11-14 03:00

Message:
Logged In: YES 
user_id=31435

Reassigned to MarkH, as this is in the Win32 extensions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=481284&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 03:43:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 19:43:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16qQpS-0005v7-00@usw-sf-web2.sourceforge.net>

Bugs item #503031, was opened at 2002-01-14 05:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Mark Hammond (mhammond)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 14:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-17 04:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-17 02:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-17 00:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 07:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-16 07:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 07:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-16 06:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 05:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-16 04:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 00:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 15:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 09:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 08:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 05:48:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 27 Mar 2002 21:48:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16qSln-0005Py-00@usw-sf-web3.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Mark Hammond (mhammond)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 10:17:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 02:17:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qWyV-0007Nx-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 10:33:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 02:33:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-536017 ] threading.Lock().acquire bug
Message-ID: <E16qXDn-0007ZB-00@usw-sf-web4.sourceforge.net>

Bugs item #536017, was opened at 2002-03-28 03:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470

Category: Documentation
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Fiona Lim (fionalim)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: threading.Lock().acquire bug

Initial Comment:
According to the online documentation for threading
Lock objects, setting blocking=0 will produce a
non-blocking call.
But trying it in the command line causes the execution
to hang.
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(blocking=0)
>>> lock.acquire(blocking=0)
[blocks]

----------------------------------
internal documentation claims that the keyword is wait,
but using wait produces the same problem:

>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire.__doc__
'acquire([wait]) -> None or
Boolean\n(PyThread_acquire_lock() is an obsolete
synonym)\n\nLock the lock.  Without argument, this
blocks if the lock is already\nlocked (even by the same
thread), waiting for another thread to release\nthe
lock, and return None when the lock is acquired.\nWith
a Boolean argument, this will only block if the
argument is true,\nand the return value reflects
whether the lock is acquired.\nThe blocking operation
is not interruptible.'
>>> lock.acquire(wait=0)
>>> lock.acquire(wait=0)
[blocks]

---------------------------------
Not using a keyword works fine:
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(0)
1
>>> lock.acquire(0)
0
>>> 



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:33

Message:
Logged In: YES 
user_id=21627

This is fixed in Python 2.2; it will raise an exception
"acquire() takes no keyword arguments". That should make it
immediately clear how to read the documentation.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 04:31

Message:
Logged In: YES 
user_id=31435

Changed to docs and assigned to Fred for comment.  Any idea 
how we can make this clearer?  The docs don't claim this 
accepts a keyword argument, and lots of C functions simply 
ignore any keyword arguments that may be given.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 13:10:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 05:10:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qZfv-0000uZ-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 13:13:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 05:13:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qZib-0000wb-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 14:10:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 06:10:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qabO-0002Nm-00@usw-sf-web3.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 14:20:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 06:20:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qalY-0004IR-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-03-28 15:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 15:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 03:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 02:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 23:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 22:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 22:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 14:20:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 06:20:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qalg-0004Ie-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 21:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Christian Tismer (tismer)
Date: 2002-03-28 15:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 15:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 15:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 03:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 02:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 23:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 22:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 22:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 15:33:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 07:33:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-515336 ] Method assignment inconsistency
Message-ID: <E16qbtp-00059r-00@usw-sf-web2.sourceforge.net>

Bugs item #515336, was opened at 2002-02-09 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515336&group_id=5470

Category: Type/class unification
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Oren Tirosh (oren-sf)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Method assignment inconsistency

Initial Comment:
Python code and builtin functions don't have a 
consistent view of new style objects when method 
attributes are assigned:

class A(object):
   def __repr__(self):
      return 'abc'

a = A()
a.__repr__ = lambda:'123'

Result: repr(a) != a.__repr__()

The repr() function sees the original __repr__ method 
but reading the __repr__ attribute returns the 
assigned function.  With classic objects both cases 
use the assigned method.




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 10:33

Message:
Logged In: YES 
user_id=6380

I'm going to reject this bug as "won't fix".  I specifically
put code in the new classes to create this behavior.  It's
partly a
performance hack: many operations become much slower if they
have to
check the instance __dict__ first.  But I also believe it's
poor
style to override a system operation on the instance rather
than on
the class.  If you want to be able to override behavior per
instance,
use this:

  class A(object):
    def __repr__(self):
      return self.repr()
    def repr(self):
      return 'abc'

  a = A()
  a.repr = lambda: '123'
  assert repr(a) == a.__repr__() == '123'


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515336&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 15:38:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 07:38:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qbyd-0005DZ-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 15:58:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 07:58:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qcHu-0003fi-00@usw-sf-web3.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 15:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 14:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 14:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 02:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 01:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 22:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 21:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 21:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:02:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:02:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qcLo-0005Up-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:28:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:28:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qclg-0005t0-00@usw-sf-web1.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:37:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:37:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes.
Message-ID: <E16qcta-0003Fg-00@usw-sf-web4.sourceforge.net>

Bugs item #510868, was opened at 2002-01-30 14:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Sharad Satsangi (sharadinfozen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 2.7 make chokes.

Initial Comment:
I'm building python2.2 on a Solaris2.7 box, an Ultra-
10.

I get a segmentation fault error at 'xreadlines' when 
I try the make.

I am not sure why.

Logs of the configuration script & make are attached. 
(in one concatenated file, I could not tell how to 
upload more than one file).

Any help will be greatly appreciated.

thanks!
-sharad.


----------------------------------------------------------------------

>Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-03-28 11:37

Message:
Logged In: YES 
user_id=443851

Thanks for the followup, but due to the nature of the 
project this box is involved in, and my company's policies, 
I would get in serious poo-poo if I let you in.

I think we will just have to concede on this, and move on.

thanks again.
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 15:59

Message:
Logged In: YES 
user_id=21627

Can you offer an account on this machine? I'd like to
investigate it "life".

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-04 17:02

Message:
Logged In: YES 
user_id=443851

I tried downgrading gcc to 2.95.3, however, it still craps 
out at the same place, and according to backtrace, it is 
still quitting in the same place.

I've attached the logs.

We've successfully built python on another box, keeping the 
project that was in jeopardy moving forward, however, I 
would still very much like to find out how to install 
python correctly on this problem box.

thanks,
-sharad.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 06:38

Message:
Logged In: YES 
user_id=21627

That looks very much like a miscompilation. Notice that
initreadline is supposed to pass a first string of
"readline" to InitModule4; in the gdb backtrace, we see an
empty string. Likewise, the invalid address comes from the
methods argument to InitModule4, fetching ml_name. These are
all static strings, compiled into an array (namely,
readline.c:readline_methods).

So I really recommend to downgrade the compiler (or use the
Sun system compiler if you have it); if you are interested
in a work-around, here are two options:
- build readline statically into the Python interpreter. Do
so by uncommenting the readline line in Modules/Setup
(adding libraries as necessary)
- do not build the readline module at all; do so by adding
'readline' into setup.py:disabled_module_list.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 17:15

Message:
Logged In: YES 
user_id=443851

I've done a full backtrace on it (see gdbout2), but I 
really don't know how to interpret the results.  From what 
I can tell, the problem lies in this area:
#1  0x20f00 in PyString_FromString (
    str=0x7e1138 <Address 0x7e1138 out of bounds>)
    at Objects/stringobject.c:112
#2  0xad7dc in PyDict_SetItemString (v=0x7e1138,
    key=0x7e1138 <Address 0x7e1138 out of bounds>, 
item=0x17d350)
    at Objects/dictobject.c:1879

Unfotunately, I can't tell what's going wrong in these 
source files, and when I tried 'p str' on the var 
referenced in line #1, I get: 
$1 = 0x7e1138 <Address 0x7e1138 out of bounds>
which does not explain much to me.


I have tried the package at SunFreeWare's site, but my 
developer needs the 'HTTPSConnection' from 'httplib', which 
apparently is _not_ built into the sunfreeware package.

So, any input, again, would be greatly appreciated.  

I realise you must be a busy guy, thanks for all of your 
help & patience!
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 15:26

Message:
Logged In: YES 
user_id=21627

Ok, gcc 3.0.3 itself could be a source of problems, but I
won't accuse that compiler prematurely (you might want to
try 2.95.x, though, if you have that readily available).

As for the gdb analysis: that it crashes is strlen is not
the problem; strlen is the innocent C library function that
computes the length of the string. Please invoke the command
"bt" when it crashes; that should tell you the backtrace
(i.e. where strlen is called from) - please report that.

If you want to investigate further: "up" brings you up a
stack-level, and "p varname" prints a variable.

This approach to debugging may take many more rounds, so I'd
understand if you are ready to give up (sunfreeware has
2.1.1 binaries). It's just that it builds fine for me (on
Solaris 8, using gcc 2.95.2), so I have no clue as to what
the problem might be. Did you pass any options to ./configure?

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 11:04

Message:
Logged In: YES 
user_id=443851

Thanks for the gdb tip, I've switched to the solaris7 pkg 
for gdb.  The version info for gcc does not explicitly list 
what flavor of Solaris it's built for, but the version 
number is 3.0.3, and it reads it's specs 
from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.7/3.0.3/specs, which leads me to believe that it's 
built for solaris7.  

Anywho, after some freaking around with env var's & gdb, I 
got the following output (see gdbout).  It leads me to 
believe that the problem is in /usr/lib/libc.so.1, but I'm 
not sure how to replace/update this lib, or even if it is 
indeed the source of my python misery.

Any input or guidance would be appreciated.

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 05:36

Message:
Logged In: YES 
user_id=21627

It would be good if you could analyse this with gdb further.
I recommend to obtain a more recent copy of gdb (e.g. gdb
5.0), in particular one compiled for your system (the one
you have is compiled for Solaris 2.4). You can get get
binaries from sunfreeware.com (although they don't have gdb
5 for Solaris 7; you might want to try the 4.18 that they do
have).

The important thing is that you need to run the setup.py
under gdb. To do this, please invoke the setup.py line
manually. I.e. if the makefile invoke

ENV1=val1 ENV2=val2 python-command python-options arguments

you will need to perform the following commands

ENV1=val1
ENV2=val2
export ENV1 ENV2
gdb python-command
run python-options arguments

As a side point, what is the exact gcc version that you are
usingq (gcc -v)? If that also is not a gcc for Solaris 7, I
recommend to re-install the compiler, or use the system
compiler.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-01-31 16:09

Message:
Logged In: YES 
user_id=443851

I did try gdb on the python binary, but got nothing 
interesting (you can see in the file gdbpyth).  

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-31 12:35

Message:
Logged In: YES 
user_id=21627

Can you attach to Python with gdb and see why it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:42:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:42:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qcyZ-0005x6-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:43:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:43:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-510868 ] Solaris 2.7 make chokes.
Message-ID: <E16qd02-0005yK-00@usw-sf-web2.sourceforge.net>

Bugs item #510868, was opened at 2002-01-30 20:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470

Category: Installation
Group: Python 2.2
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Sharad Satsangi (sharadinfozen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris 2.7 make chokes.

Initial Comment:
I'm building python2.2 on a Solaris2.7 box, an Ultra-
10.

I get a segmentation fault error at 'xreadlines' when 
I try the make.

I am not sure why.

Logs of the configuration script & make are attached. 
(in one concatenated file, I could not tell how to 
upload more than one file).

Any help will be greatly appreciated.

thanks!
-sharad.


----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=21627

Ok, closing it as not-reproducable.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=443851

Thanks for the followup, but due to the nature of the 
project this box is involved in, and my company's policies, 
I would get in serious poo-poo if I let you in.

I think we will just have to concede on this, and move on.

thanks again.
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 21:59

Message:
Logged In: YES 
user_id=21627

Can you offer an account on this machine? I'd like to
investigate it "life".

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-04 23:02

Message:
Logged In: YES 
user_id=443851

I tried downgrading gcc to 2.95.3, however, it still craps 
out at the same place, and according to backtrace, it is 
still quitting in the same place.

I've attached the logs.

We've successfully built python on another box, keeping the 
project that was in jeopardy moving forward, however, I 
would still very much like to find out how to install 
python correctly on this problem box.

thanks,
-sharad.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-02 12:38

Message:
Logged In: YES 
user_id=21627

That looks very much like a miscompilation. Notice that
initreadline is supposed to pass a first string of
"readline" to InitModule4; in the gdb backtrace, we see an
empty string. Likewise, the invalid address comes from the
methods argument to InitModule4, fetching ml_name. These are
all static strings, compiled into an array (namely,
readline.c:readline_methods).

So I really recommend to downgrade the compiler (or use the
Sun system compiler if you have it); if you are interested
in a work-around, here are two options:
- build readline statically into the Python interpreter. Do
so by uncommenting the readline line in Modules/Setup
(adding libraries as necessary)
- do not build the readline module at all; do so by adding
'readline' into setup.py:disabled_module_list.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 23:15

Message:
Logged In: YES 
user_id=443851

I've done a full backtrace on it (see gdbout2), but I 
really don't know how to interpret the results.  From what 
I can tell, the problem lies in this area:
#1  0x20f00 in PyString_FromString (
    str=0x7e1138 <Address 0x7e1138 out of bounds>)
    at Objects/stringobject.c:112
#2  0xad7dc in PyDict_SetItemString (v=0x7e1138,
    key=0x7e1138 <Address 0x7e1138 out of bounds>, 
item=0x17d350)
    at Objects/dictobject.c:1879

Unfotunately, I can't tell what's going wrong in these 
source files, and when I tried 'p str' on the var 
referenced in line #1, I get: 
$1 = 0x7e1138 <Address 0x7e1138 out of bounds>
which does not explain much to me.


I have tried the package at SunFreeWare's site, but my 
developer needs the 'HTTPSConnection' from 'httplib', which 
apparently is _not_ built into the sunfreeware package.

So, any input, again, would be greatly appreciated.  

I realise you must be a busy guy, thanks for all of your 
help & patience!
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 21:26

Message:
Logged In: YES 
user_id=21627

Ok, gcc 3.0.3 itself could be a source of problems, but I
won't accuse that compiler prematurely (you might want to
try 2.95.x, though, if you have that readily available).

As for the gdb analysis: that it crashes is strlen is not
the problem; strlen is the innocent C library function that
computes the length of the string. Please invoke the command
"bt" when it crashes; that should tell you the backtrace
(i.e. where strlen is called from) - please report that.

If you want to investigate further: "up" brings you up a
stack-level, and "p varname" prints a variable.

This approach to debugging may take many more rounds, so I'd
understand if you are ready to give up (sunfreeware has
2.1.1 binaries). It's just that it builds fine for me (on
Solaris 8, using gcc 2.95.2), so I have no clue as to what
the problem might be. Did you pass any options to ./configure?

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-02-01 17:04

Message:
Logged In: YES 
user_id=443851

Thanks for the gdb tip, I've switched to the solaris7 pkg 
for gdb.  The version info for gcc does not explicitly list 
what flavor of Solaris it's built for, but the version 
number is 3.0.3, and it reads it's specs 
from /usr/local/lib/gcc-lib/sparc-sun-
solaris2.7/3.0.3/specs, which leads me to believe that it's 
built for solaris7.  

Anywho, after some freaking around with env var's & gdb, I 
got the following output (see gdbout).  It leads me to 
believe that the problem is in /usr/lib/libc.so.1, but I'm 
not sure how to replace/update this lib, or even if it is 
indeed the source of my python misery.

Any input or guidance would be appreciated.

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-01 11:36

Message:
Logged In: YES 
user_id=21627

It would be good if you could analyse this with gdb further.
I recommend to obtain a more recent copy of gdb (e.g. gdb
5.0), in particular one compiled for your system (the one
you have is compiled for Solaris 2.4). You can get get
binaries from sunfreeware.com (although they don't have gdb
5 for Solaris 7; you might want to try the 4.18 that they do
have).

The important thing is that you need to run the setup.py
under gdb. To do this, please invoke the setup.py line
manually. I.e. if the makefile invoke

ENV1=val1 ENV2=val2 python-command python-options arguments

you will need to perform the following commands

ENV1=val1
ENV2=val2
export ENV1 ENV2
gdb python-command
run python-options arguments

As a side point, what is the exact gcc version that you are
usingq (gcc -v)? If that also is not a gcc for Solaris 7, I
recommend to re-install the compiler, or use the system
compiler.

----------------------------------------------------------------------

Comment By: Sharad Satsangi (sharadinfozen)
Date: 2002-01-31 22:09

Message:
Logged In: YES 
user_id=443851

I did try gdb on the python binary, but got nothing 
interesting (you can see in the file gdbpyth).  

thanks,
-sharad.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-01-31 18:35

Message:
Logged In: YES 
user_id=21627

Can you attach to Python with gdb and see why it crashes?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=510868&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:47:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:47:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16qd3w-00066z-00@usw-sf-web1.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 10:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

>Comment By: Tom Epperly (tepperly)
Date: 2002-03-28 08:47

Message:
Logged In: YES 
user_id=94539

I apologize for filing this bug. It turns out that it was a
misunderstanding between me and a user who filed a bug report
against my software project.  He was building his .so in a
non-standard way (from a Python perspective) that caused a
symbol conflict.  Basically, he was putting a whole bunch of
extension modules in a single .so.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 04:32

Message:
Logged In: YES 
user_id=21627

I can't see why this gives a conflict. When Python loads the
module, it requests the symbol specifically from the shared
library it just loaded. What operating system are you using?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-26 05:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:48:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:48:28 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16qd4e-00067i-00@usw-sf-web1.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 10:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-03-28 08:47

Message:
Logged In: YES 
user_id=94539

I apologize for filing this bug. It turns out that it was a
misunderstanding between me and a user who filed a bug report
against my software project.  He was building his .so in a
non-standard way (from a Python perspective) that caused a
symbol conflict.  Basically, he was putting a whole bunch of
extension modules in a single .so.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 04:32

Message:
Logged In: YES 
user_id=21627

I can't see why this gives a conflict. When Python loads the
module, it requests the symbol specifically from the shared
library it just loaded. What operating system are you using?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-26 05:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:56:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:56:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16qdC8-0003U3-00@usw-sf-web4.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 13:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

Comment By: Matthew G. Knepley (knepley)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=58554

I filed this bug with Tom. I would like to get all the Python stubs for single package in his IDL in one shared object. However, each interface/class is a module in order to handle static methods, etc. Therefore, I end up making links from each small .so to one big one since this is much easier to build. I wanted a way t odictate the form of the global symbol which is necessary to load the module.
  I don't think would be too hard, but it is more of a 2.3/3.0 candidate. I got the source and am trying to work through it myself before offering a suggestion to python-dev.

----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-03-28 11:47

Message:
Logged In: YES 
user_id=94539

I apologize for filing this bug. It turns out that it was a
misunderstanding between me and a user who filed a bug report
against my software project.  He was building his .so in a
non-standard way (from a Python perspective) that caused a
symbol conflict.  Basically, he was putting a whole bunch of
extension modules in a single .so.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:32

Message:
Logged In: YES 
user_id=21627

I can't see why this gives a conflict. When Python loads the
module, it requests the symbol specifically from the shared
library it just loaded. What operating system are you using?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-26 08:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 16:56:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 08:56:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qdCt-0003UD-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 17:20:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 09:20:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qdZt-0006Ok-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 18:21:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 10:21:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qeX7-0004TM-00@usw-sf-web4.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 19:32:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 11:32:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qfdh-0006BW-00@usw-sf-web3.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 14:32

Message:
Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 20:03:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 12:03:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-536449 ] pydoc getopt fails
Message-ID: <E16qg7E-0008FK-00@usw-sf-web2.sourceforge.net>

Bugs item #536449, was opened at 2002-03-28 20:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536449&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc getopt fails

Initial Comment:
slothrop:~> pydoc getopt
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 4, in ?
    pydoc.cli()
  File "/usr/local/lib/python2.3/pydoc.py", line 2077,
in cli
    doc(arg)
  File "/usr/local/lib/python2.3/pydoc.py", line 1341,
in doc
    pager(title % (desc + suffix) + '\n\n' +
text.document(thing, name))
  File "/usr/local/lib/python2.3/pydoc.py", line 267,
in document
    if inspect.ismodule(object): return
apply(self.docmodule, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 961,
in docmodule
    contents.append(self.document(value, key, name))
  File "/usr/local/lib/python2.3/pydoc.py", line 268,
in document
    if inspect.isclass(object): return
apply(self.docclass, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1093,
in docclass
    lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1035,
in spill
    name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 269,
in document
    if inspect.isroutine(object): return
apply(self.docroutine, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1154,
in docroutine
    doc = getdoc(object) or ''
  File "/usr/local/lib/python2.3/pydoc.py", line 66, in
getdoc
    result = inspect.getdoc(object) or
inspect.getcomments(object)
  File "/usr/local/lib/python2.3/inspect.py", line 420,
in getcomments
    try: lines, lnum = findsource(object)
  File "/usr/local/lib/python2.3/inspect.py", line 384,
in findsource
    file = getsourcefile(object) or getfile(object)
  File "/usr/local/lib/python2.3/inspect.py", line 329,
in getsourcefile
    filename = getfile(object)
  File "/usr/local/lib/python2.3/inspect.py", line 309,
in getfile
    raise TypeError, 'arg is not a module, class,
method, ' \
TypeError: arg is not a module, class, method,
function, traceback, frame, or code object


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536449&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 20:44:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 12:44:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qgkt-0000HF-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
>Status: Closed
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 15:44

Message:
Logged In: YES 
user_id=6380

Closing this; fixes have been checked in.

Maybe someone (Tim?) can check in the test case? Only the
trunk seems sufficient.

Christian: no need for a new trashcan IMO.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 14:32

Message:
Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 20:49:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 12:49:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-430160 ] CGIHTTPServer.py POST bug using IE
Message-ID: <E16qgqH-0000L9-00@usw-sf-web2.sourceforge.net>

Bugs item #430160, was opened at 2001-06-04 20:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470

Category: Windows
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Altis (kasplat)
Assigned to: Nobody/Anonymous (nobody)
Summary: CGIHTTPServer.py POST bug using IE

Initial Comment:
>From the readme included in the zip:
This set of files shows a bug that occurs when doing 
POST requests via the CGIHTTPServer.py module in 
Python 2.1 The testpost.html file when accessed via 
Internet Explorer 5.5 from webserver.py should show 
this bug. On short POST requests IE will end up doing 
a second POST and then displaying an error message 
while longer POSTs will be followed by a second POST 
and then a GET.

The problem appears to be specific to the interaction 
of IE and the handling of windows sockets in Python in 
the CGIHTTPServer.py module which relies on 
BaseHTTPServer.py, SocketServer.py...

posttestwebserver.py is currently setup to use 
C:\tmp\testpost as the document root, so either move 
the "testpost" folder to C:\tmp or change the 
directory to wherever the testpost folder is located. 
Start the server using the .bat file and bring 
up .html page with something like:
  http://localhost/testpost.html

The bug should occur when you try:
  Test short CGI response with POST
or
  Test long CGI response with POST

The other requests should work fine. The bug will 
occur regardless of whether IE is set to use HTTP/1.0 
or HTTP/1.1. The bug doesn't appear to occur when 
going through a simple proxy. You can also get the bug 
to occur using a remote IE client (either on a LAN or 
over the Net). In addition, it doesn't appear to 
matter whether running with unbuffered binary pipes 
(python -u) or not. I also tested against my modified 
CGIHTTPServer.py See the bug I posted at:
http://sourceforge.net/tracker/?
func=detail&atid=105470&aid=427345&group_id=5470

My configuration:
Windows 2000 Pro, SP2
AMD 1.2GHz
256MB RAM
ActiveStatet Python 2.1 (build 210)
Internet Explorer 5.5 (5.50.4522.1800)

ka
---
Mark Lutz said:
"FWIW, I noticed today (in between lecturing a class) 
that on Windows, Python actually uses a special Python-
coded socket.py library module, not the standard C-
coded socket extension module.  socket.py lives in the 
library directory; it does unique things for closes 
and deletes that may not make sense in all cases 
(e.g., the makefile call generates a class instance, 
not a true file object).  It may also be trying to 
close the underlying socket twice.  I don't have"


----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 15:49

Message:
Logged In: YES 
user_id=247536

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Steve Holden (holdenweb)
Date: 2001-07-17 07:28

Message:
Logged In: YES 
user_id=88157

Please note that I have observed this behavior on Windows
98 using Python 2.0 (#8, Mar  7 2001, 16:04:37) [MSC 32 bit 
(Intel)] using the same build of IE, so it is not a Win2k-
specific problem.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=430160&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 20:57:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 12:57:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-536469 ] module array:  C type descriptions wrong
Message-ID: <E16qgxs-0000Qq-00@usw-sf-web2.sourceforge.net>

Bugs item #536469, was opened at 2002-03-28 20:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536469&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Histed (histed)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: module array:  C type descriptions wrong

Initial Comment:
The C types corresponding to the 'array' type codes
seem to be documented incorrectly.

See:
http://www.python.org/doc/current/lib/module-array.html

All C integer types are listed as 'int' or 'unsigned
int'.  I'm guessing from the sizes and the C standard
that these should be 'char', 'short', 'int', and 'long'.

This agrees with what the Python Essential reference
has to say (Beazley, p127)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536469&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 21:08:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 13:08:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qh7s-0006QO-00@usw-sf-web4.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 21:21:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 13:21:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E16qhLD-0006Zi-00@usw-sf-web4.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 13: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: Nobody/Anonymous (nobody)
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: Matthew King (kyrrigle)
Date: 2002-03-28 16:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 11:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 09: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 08: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 15: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 12: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 Mar 28 22:10:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:10:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qi6E-0001Fb-00@usw-sf-web2.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:10

Message:
Logged In: YES 
user_id=31435

Just noting that I added a test case to test_gc.py in the 
trunk.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 15:44

Message:
Logged In: YES 
user_id=6380

Closing this; fixes have been checked in.

Maybe someone (Tim?) can check in the test case? Only the
trunk seems sufficient.

Christian: no need for a new trashcan IMO.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 14:32

Message:
Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 22:34:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:34:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-416288 ] infrequent memory leak in pyexpat
Message-ID: <E16qiTS-0007NQ-00@usw-sf-web4.sourceforge.net>

Bugs item #416288, was opened at 2001-04-15 13: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: Guido van Rossum (gvanrossum)
Date: 2002-03-28 17:34

Message:
Logged In: YES 
user_id=6380

Hm, the 'N' format code looks really scary. Can't it end up
DECREF'ing an object too many times if something fails?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-09 07: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  Thu Mar 28 22:37:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:37:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16qiW0-0007P5-00@usw-sf-web4.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 23:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

>Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 22:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:23

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 22:43:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:43:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qicE-0008Kw-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 22:48:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:48:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16qigz-0001mK-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

----------------------------------------------------------------------

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 22:49:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:49:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-536516 ] Docs for "es" and "et" confusing
Message-ID: <E16qihZ-0001mp-00@usw-sf-web1.sourceforge.net>

Bugs item #536516, was opened at 2002-03-28 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536516&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: Docs for "es" and "et" confusing

Initial Comment:
The extending/embedding manual seems to contain
confusing docs for the PyArg_Parse* format codes "es"
and "es#". For example, the description for "es" states
that it reads one variable (the encoding) and writes
two variables; but in fact, it appears that it writes
only one variable (the buffer). The number of variables
written is consistently one too large.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536516&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 23:03:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 15:03:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qivL-0001rI-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 22:58:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 14:58:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qiqq-0007eP-00@usw-sf-web4.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 22:58

Message:
Logged In: YES 
user_id=35752

I'm working on the trashcan code fix right now (use gc_prev
instead of ob_type).  I was going to check it in but an
interpreter built --without-cycle-gc and with Py_DEBUG
defined crashes.  I don't know if our recent changes broke
things of if --without-cycle-gc has been broken for a while.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 22:10

Message:
Logged In: YES 
user_id=31435

Just noting that I added a test case to test_gc.py in the 
trunk.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 20:44

Message:
Logged In: YES 
user_id=6380

Closing this; fixes have been checked in.

Maybe someone (Tim?) can check in the test case? Only the
trunk seems sufficient.

Christian: no need for a new trashcan IMO.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 19:32

Message:
Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 18:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 16:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 15:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 14:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 14:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 02:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 01:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 22:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 21:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 21:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Thu Mar 28 23:20:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 15:20:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-416288 ] infrequent memory leak in pyexpat
Message-ID: <E16qjBu-0000Ii-00@usw-sf-web3.sourceforge.net>

Bugs item #416288, was opened at 2001-04-15 19: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: 2002-03-29 00:20

Message:
Logged In: YES 
user_id=21627

No, currently, it can only leak: the argument being passed
will have an extra ref count, which supposedly will be
consumed by the tuple. If something fails, some of the N
arguments will have been stored in the
tuple-under-construction, and will be released when the
tuple is released. 'N' arguments not yet consumed will leak.

Processing should continue in case of an error, and DECREF
all N arguments.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 23:34

Message:
Logged In: YES 
user_id=6380

Hm, the 'N' format code looks really scary. Can't it end up
DECREF'ing an object too many times if something fails?

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2001-06-09 13: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  Thu Mar 28 23:28:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 15:28:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-535905 ] Evil Trashcan and GC interaction
Message-ID: <E16qjJz-0007xu-00@usw-sf-web4.sourceforge.net>

Bugs item #535905, was opened at 2002-03-27 15:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: None
Priority: 7
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Neil Schemenauer (nascheme)
Summary: Evil Trashcan and GC interaction

Initial Comment:
This bug is only a hypothetical bug -- from source 
code inspection it appears clear that it can happen, 
and we have a Zope user who is reporting crashes that 
are consistent with this, but it isn't confirmed that 
this is indeed the cause.  Tim is attempting to 
reproduce it while I'm typing this.

The trashcan code stores NULL or other values in the 
ob_type field of an object, while that object is still 
in the GC doubly-linked list of container objects.  
When the collector is invoked, it dereferences ob_type 
(specifically, in subtract_refs, it retrieves ob_type-
>tp_traverse and calls it).  Obviously, the value 
stored in ob_type by the trashcan code causes this to 
fail.

This bug occurs in all versions of Python that have 
the GC code enabled (i.e. 2.0 and above).  In 2.1 and 
before, the code looks different than in 2.2, but the 
effect is the same: the trashcan code abuses ob_type 
of an object that's in a GC generational chain.

If we fix this, a 2.1.3 release including the fix 
should be issued, and we should hold up the final 
release of 2.2.1 to include a fix as well.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-28 18:28

Message:
Logged In: YES 
user_id=31435

Sorry, Neil, no clue -- PythonLabs likely builds every day 
in release and debug (Py_DEBUG) modes, each using all 
platform defaults, but I don't believe any of us ever 
builds in any other way.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 17:58

Message:
Logged In: YES 
user_id=35752

I'm working on the trashcan code fix right now (use gc_prev
instead of ob_type).  I was going to check it in but an
interpreter built --without-cycle-gc and with Py_DEBUG
defined crashes.  I don't know if our recent changes broke
things of if --without-cycle-gc has been broken for a while.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:10

Message:
Logged In: YES 
user_id=31435

Just noting that I added a test case to test_gc.py in the 
trunk.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 15:44

Message:
Logged In: YES 
user_id=6380

Closing this; fixes have been checked in.

Maybe someone (Tim?) can check in the test case? Only the
trunk seems sufficient.

Christian: no need for a new trashcan IMO.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 14:32

Message:
Logged In: YES 
user_id=6380

The new semaphore code is innocent -- it wasn't even used in
this case.

I cannot reproduce the bug with Neil's patch + my ceval.c
patch any more, so I consider this case closed.

I'll check the necessary things in to the 2.1 and 2.2
maintenance branches. Neil, can you check in your patch to
the trunk?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 13:21

Message:
Logged In: YES 
user_id=6380

Looks like there are at least two independent bugs exposed
by the lis.py example in the CVS trunk/head: on Windows,
traversing the frame object can encounter freed object
because of the way the SETLOCAL() macro first decrefs
fastlocals[i] and then assigns it a new value. I've got a
fix for this (separate, see ceval.c.diff attached). On
Linux, the traceback points to the brand new semaphore code;
haven't researched this further yet.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 11:28

Message:
Logged In: YES 
user_id=6380

Well, it *also* abuses the ob_refcnt field.

How about this wild idea (which Tim & I had simultaneously
yesterday): change the trashcan code to simply leave the
object in the GC generational list, and let the GC code
special-case objects with zero refcnt so that they are
eventually properly disposed?

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-28 10:58

Message:
Logged In: YES 
user_id=35752

I'm not sure the abuse of the ob_type pointer is the only
problem we are facing here.  I've have a patch that changes
trashcan so that it doesn't overwrite the ob_type pointer.
I can still make the interpreter crash.  I'm still trying
to understand this problem completely. :-(

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Christian Tismer (tismer)
Date: 2002-03-28 09:20

Message:
Logged In: YES 
user_id=105700

Ouchh!
I will look into this and find an alternative
implementation. My current abuse of the type field
interacts with that fact that GC still needs it.
We just moved into a new house, I will not be
online often over Easter. Will sove it in the
coming week.
ciao - chris

----------------------------------------------------------------------

Comment By: Matthew T. Kromer (zerohero)
Date: 2002-03-28 09:10

Message:
Logged In: YES 
user_id=378059

Leo in Brazil (the Zope customer experiencing the problem)
has bumped the trashcan depth limit up to 5 million, and
been stable for the entire overnight and morning production
periods.

He confirms the description and I believe he will be trying
the patch today.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 21:15

Message:
Logged In: YES 
user_id=6380

Here's a patch for the 2.1 maintenance branch. AFAICT this
fixes the problem for lists, tuples and dicts, which is a
100% fix (the other trashcan objects, frames and tracebacks,
don't use GC).

Note: the dict test case is just like the tuple or list
testcase, but has
  t = {1: t, 2: Ouch()}
as the last line of f().

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=6380

Alas, that fixes it for tuples, but not for lists. I've
uploaded the list example as lis.py.

We also need a fix for 2.1.2 (to help the Zope user who
originally ran into this) and one for 2.2.1 -- the latter is
needed quickly if we want to make the final release.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 17:18

Message:
Logged In: YES 
user_id=35752

Well, not as simple as I had hoped.  Attached is a rough
patch that fixes the bug (I think, I haven't had time to
really study the interaction between GC and the trashcan
macros).

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-03-27 16:55

Message:
Logged In: YES 
user_id=35752

The fix should be simple.  Coming soon. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 16:04

Message:
Logged In: YES 
user_id=31435

Attaching a brief program (tup.py) that provokes a crash 
quickly, at least on Windows.  The crash goes away if the 
trashcan limit is boosted above the depth of tuple nesting 
this program creates.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535905&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 04:33:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 20:33:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qo4m-0005JF-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 07:36:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 28 Mar 2002 23:36:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E16qqwL-0006ya-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 13: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: Nobody/Anonymous (nobody)
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: Thomas Justin Shaw (justinshaw)
Date: 2002-03-29 02:36

Message:
Logged In: YES 
user_id=135558

I'm experiencing a problem on windows.
When I execute the scripts as 
'http://localhost:8080/cgi-bin\junk.py' 
the page seems to load ok but I get the popup message:
Internet Explorer cannot open the Internet site 
http://localhost:8080/cgi-bin\junk.py
The connection with the server ws reset

On Netscape no errors but the download also takes forever. 
The slow download seems to be caused by the 
FieldStorage() call.


----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 16:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 11:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 09: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 08: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 15: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 12: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 Mar 29 08:30:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 00:30:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-534807 ] C extension modules with same short name
Message-ID: <E16qrmd-0005if-00@usw-sf-web3.sourceforge.net>

Bugs item #534807, was opened at 2002-03-25 19:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: Tom Epperly (tepperly)
Assigned to: Nobody/Anonymous (nobody)
Summary: C extension modules with same short name

Initial Comment:
I am working on a language interoperability project,
http://www.llnl.gov/CASC/components/. We have an IDL
that gets converted into Python C extension modules. If
we have an IDL such as this:

package MPIB {
  interface Base {
  }
}

package MPIB.Default {
  class Base implements-all MPIB.Base {
  }
}

We end up with two C extension modules whose short name
is Base.  There is a symbol conflict when loading both
because they both use "initBase" as the DLL/SO
initialization function.  It would be nice if C
extension modules could use the fully qualified module
name instead of the short name for the initialization
function.  For example,

initMPID_Base and initMPIB_Default_Base 
or
initMPIDBase and initMPIDDefaultBase

What do you think?

----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 09:30

Message:
Logged In: YES 
user_id=21627

I doubt any changes to the current scheme would be accepted.
Currently, you can move a .so around between packages, and
it continues to work. With the proposed change, this won't
work anymore.

So I rather recommend that you find a way to build the
module structure from within a single init function. It
should be possible to build a tree of modules through
exported C API, modifying sys.modules as necessary. Or the
top-level module could just export a nested dictionary
hierarchy, with the code to build the package hierarchy
implemented in Python.

----------------------------------------------------------------------

Comment By: Matthew G. Knepley (knepley)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=58554

I filed this bug with Tom. I would like to get all the Python stubs for single package in his IDL in one shared object. However, each interface/class is a module in order to handle static methods, etc. Therefore, I end up making links from each small .so to one big one since this is much easier to build. I wanted a way t odictate the form of the global symbol which is necessary to load the module.
  I don't think would be too hard, but it is more of a 2.3/3.0 candidate. I got the source and am trying to work through it myself before offering a suggestion to python-dev.

----------------------------------------------------------------------

Comment By: Tom Epperly (tepperly)
Date: 2002-03-28 17:47

Message:
Logged In: YES 
user_id=94539

I apologize for filing this bug. It turns out that it was a
misunderstanding between me and a user who filed a bug report
against my software project.  He was building his .so in a
non-standard way (from a Python perspective) that caused a
symbol conflict.  Basically, he was putting a whole bunch of
extension modules in a single .so.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:32

Message:
Logged In: YES 
user_id=21627

I can't see why this gives a conflict. When Python loads the
module, it requests the symbol specifically from the shared
library it just loaded. What operating system are you using?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-26 14:02

Message:
Logged In: YES 
user_id=6656

There is exactly no way in which this is a 2.2.1 candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534807&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 09:08:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 01:08:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qsNC-0007u4-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
>Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 09:19:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 01:19:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16qsXk-0006C6-00@usw-sf-web3.sourceforge.net>

Bugs item #524600, was opened at 2002-03-02 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-28 01:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 22:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 09:37:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 01:37:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-431899 ] tkfileDialog on NT makes float fr specif
Message-ID: <E16qsp7-0008Hy-00@usw-sf-web1.sourceforge.net>

Bugs item #431899, was opened at 2001-06-10 22:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431899&group_id=5470

Category: Tkinter
Group: Platform-specific
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: tkfileDialog on NT makes float fr specif

Initial Comment:
If I use the line: (Tkinter 8.3 for Python 2.0)
file = tkFileDialog.askopenfilename(...)
on an NT french workstation, that turn off floats 
using dot but comma separator for Tcl...
then if your have defined a Text widget, calling 
self.yview('moveto', '1.0') failed with an unavailable 
type error:
TclError: expected floating-point number but got "1.0"
this appends in lib-tk\Tkinter.py line 2846 in yview
self.tk.call((self._w, 'yview') + what)

But the bugs in my opinion comes from Tcl tkFileDialog 
which activate a flag about float memory 
representation for tcl.

The problem is that I'm unable to find the turnarround 
i.e. finding tcl methode to turn on US float 
representation.

All help may be pleased.

Jerry alias the foolish dracomorpheus
python french fan ;-)



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:37

Message:
Logged In: YES 
user_id=21627

No feedback forthcoming, closing the report.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-02-24 18:17

Message:
Logged In: YES 
user_id=21627

I can't reproduce that problem. I only have a German XP
installation, but it should behave similarly in these
respect. I've been using Python 2.2.

Can you attach a small script to this report which
demonstrates the problem?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=431899&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 09:43:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 01:43:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-484994 ] bugs in Tix.py ListNoteBook  PanedWindow
Message-ID: <E16qsuV-0005Wu-00@usw-sf-web4.sourceforge.net>

Bugs item #484994, was opened at 2001-11-23 23:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470

Category: Tkinter
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Roy (rjroy)
Assigned to: Nobody/Anonymous (nobody)
Summary: bugs in Tix.py ListNoteBook  PanedWindow

Initial Comment:
Python 2.2b2
Tix.py
1)
class ListNoteBook, __init__ method calls base class 
__init__  method with "tixDirList" instead 
of "tixListNoteBook"

2)
class PanedWindow, panes method, does not split the 
string returned from self.tk.call(self._w, 'panes')


patch also adds:
access to the paned window in ListNoteBook
class dummyPanedWindow to support above
paneconfigure methods to PanedWindow 
pageConfigure methods to NoteBook and ListNoteBook
page and pages methods to ListNoteBook


I am attaching the pathched file as well as the 
following diff
################

1044c1044,1046
<        TixWidget.__init__(self, 
master, 'tixDirList', ['options'], cnf, kw)
---
>        TixWidget.__init__(self, 
master, 'tixListNoteBook', ['options'], cnf, kw)
>        self.subwidget_list['pane'] = 
_dummyPanedWindow(self, 'pane',
>                                                 
destroy_physically=0)
1048d1049
< 
1054a1056,1070
>     def page(self, name):
>        return self.subwidget(name)
> 
>     def pages(self):
>        # Can't call subwidgets_all directly because 
we don't want .nbframe
>        names = self.tk.split(self.tk.call
(self._w, 'pages'))
>        ret = []
>        for x in names:
>            ret.append(self.subwidget(x))
>        return ret
> 
>     def pageconfigure(self, name, 
**kw):              
>        apply(self.tk.call,
>              (self._w, 'pageconfigure', name) + 
self._options(kw))
> 
1099a1116,1119
>     def pageconfigure(self, name, 
**kw):              
>        apply(self.tk.call,
>              (self._w, 'pageconfigure', name) + 
self._options(kw))
> 
1162c1182
<        names = self.tk.call(self._w, 'panes')
---
>        names = self.tk.split(self.tk.call
(self._w, 'panes'))
1167a1188,1191
>     def paneconfigure(self, name, 
**kw):              
>        apply(self.tk.call,       
>              (self._w, 'paneconfigure', name) + 
self._options(kw))
> 
1571a1596,1599
>        TixSubWidget.__init__(self, master, name, 
destroy_physically)
> 
> class _dummyPanedWindow(PanedWindow, TixSubWidget):
>     def __init__(self, master, name, 
destroy_physically=1):




----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:43

Message:
Logged In: YES 
user_id=21627

The current revision of Tix.py is 1.9; it is available from

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/python/python/dist/src/Lib/lib-tk/Tix.py?rev=1.9&content-type=text/plain

It would be nice if you could regenerate the patch for the
current version of Tix.py, so that it could get included
into Python 2.3.

----------------------------------------------------------------------

Comment By: Robert Roy (rjroy)
Date: 2001-12-10 03:34

Message:
Logged In: YES 
user_id=352797

Thanks for reviewing my submission. I will make sure to do 
a context diff next time I submit something. 

The pages method that I added is applied to the 
listNoteBook class not the tixPanedWindow class. It is 
inherited from the vstack base class.

Where can I find the later version? Do I have to get them 
from the source tree?

Bob Roy.



----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2001-12-10 00:36

Message:
Logged In: YES 
user_id=33229

The first part of the patch was a definite bug, but your diffs are
against Tix.py 1.5, and the bug is fixed in the current version
1.6. (I've also submitted a new version (1.7?)  to the patch queue).

You're right about the splitlist, but the next part of the patch is
partly wrong: there is no 'pages' method to the tixPanedWindow. 
The methods of the class in Tcl Tix are:

	add delete forget manage panecget paneconfigure panes setsize

I appreciate your help on getting the PanedWindow implementation complete.
Could I ask you to check the Tcl Tix documentation and code carefully and
resubmit this patch against 1.7 when it comes out, perhaps with
some of the other missing methods as well?

To speed things up for Martin, it could be best to use a context diff
diff -c <old> <new> and upload the result as a file.

Mike Clarkson

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-06 17:15

Message:
Logged In: YES 
user_id=3066

I've asked Mike Clarkson (Tix.py guru) to take a look at this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=484994&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 15:58:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 07:58:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qylP-0003ai-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 16:30:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 08:30:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qzHD-0004Mo-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 16:35:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 08:35:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qzLH-0003vQ-00@usw-sf-web2.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 16:52:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 08:52:52 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-536796 ] fchdir
Message-ID: <E16qzcS-0004Yc-00@usw-sf-web1.sourceforge.net>

Feature Requests item #536796, was opened at 2002-03-29 16:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Nobody/Anonymous (nobody)
Summary: fchdir

Initial Comment:
os.fchdir(fd) would be a welcome addition.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 17:12:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 09:12:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16qzvg-0004jw-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-26 21:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 12:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 11:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 11:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 12:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 11:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 11:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 08:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 19:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 14:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 11:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 10:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 07:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Fri Mar 29 22:58:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 14:58:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16r5KC-0007ow-00@usw-sf-web2.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 14:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 01:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 16:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 13:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Sat Mar 30 03:28:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 29 Mar 2002 19:28:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16r9Xq-0005D0-00@usw-sf-web3.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 17:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Mike Coleman (mkc)
Date: 2002-03-29 21:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

----------------------------------------------------------------------

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 03:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 18:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 15:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Sat Mar 30 08:47:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 00:47:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16rEW3-0008Gf-00@usw-sf-web4.sourceforge.net>

Bugs item #524600, was opened at 2002-03-02 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-30 09:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 04:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

----------------------------------------------------------------------

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 23:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-28 01:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 22:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Sat Mar 30 11:37:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 03:37:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-531398 ] 221 still doesn't work on OS 8.1
Message-ID: <E16rHAl-0001Vj-00@usw-sf-web4.sourceforge.net>

Bugs item #531398, was opened at 2002-03-18 16:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: 221 still doesn't work on OS 8.1

Initial Comment:
The current problem is that InterfaceLib--FSRenameUnicode is undefined. Let's try and weak-link InterfaceLib and hope that doesn't cause a string of new problems.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-30 11:37

Message:
Logged In: YES 
user_id=6656

I thought this was fixed?

Or are you waiting for confirmation?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-22 16:15

Message:
Logged In: YES 
user_id=45365

It is not fair. Fixed the Res problem and another one shows up in QuickDraw. The fix (forthcoming) is that all toolbox modules will be weak linked and all interface methods protected against non-existing underlying API routines.

Oh well, this is something that was on my to-do list anyway.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-21 21:13

Message:
Logged In: YES 
user_id=45365

This problem has been fixed, but a new (related?) one has turned up: ConfigurePythonClassic doesn't run. This also shows up on MacOS 8.6, which should make it easier to debug (as I have access to 8.6).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470


From noreply@sourceforge.net  Sat Mar 30 22:02:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 14:02:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-531398 ] 221 still doesn't work on OS 8.1
Message-ID: <E16rQvI-0005Gb-00@usw-sf-web2.sourceforge.net>

Bugs item #531398, was opened at 2002-03-18 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470

Category: Macintosh
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: 221 still doesn't work on OS 8.1

Initial Comment:
The current problem is that InterfaceLib--FSRenameUnicode is undefined. Let's try and weak-link InterfaceLib and hope that doesn't cause a string of new problems.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-03-30 23:02

Message:
Logged In: YES 
user_id=45365

Confirmed fixed with 2.2.1c2. To get the IDE to work you also need the new 221 patch for MacOS8.1. (which differs from the 22 patch for 8.1)

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-30 12:37

Message:
Logged In: YES 
user_id=6656

I thought this was fixed?

Or are you waiting for confirmation?

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-22 17:15

Message:
Logged In: YES 
user_id=45365

It is not fair. Fixed the Res problem and another one shows up in QuickDraw. The fix (forthcoming) is that all toolbox modules will be weak linked and all interface methods protected against non-existing underlying API routines.

Oh well, this is something that was on my to-do list anyway.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-03-21 22:13

Message:
Logged In: YES 
user_id=45365

This problem has been fixed, but a new (related?) one has turned up: ConfigurePythonClassic doesn't run. This also shows up on MacOS 8.6, which should make it easier to debug (as I have access to 8.6).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531398&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 05:38:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 21:38:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16rY2p-0001Id-00@usw-sf-web2.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 17:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Mike Coleman (mkc)
Date: 2002-03-30 23:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-30 02:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-29 21:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

----------------------------------------------------------------------

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 03:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 18:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 15:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 06:28:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 22:28:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-537328 ] Problematic .py extension mapping on XP
Message-ID: <E16rYpD-0004rY-00@usw-sf-web3.sourceforge.net>

Bugs item #537328, was opened at 2002-03-31 18:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: steve matheson (stevematheson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problematic .py extension mapping on XP

Initial Comment:

When the windows pre built version installs on 
windows xp it sets up a file association that 
maps ".py" to the c:\python22\python.exe executable 
as it should.

If python is installed in "c:\program files\python22" 
the map ".py" points to "c:\progra~1\python22". This 
is fine and from the command line <script>.py runs as 
expected.

However, if one then trys to set up a script map in 
IIS on XP (so that "http:\host\test\script.py" 
works) it proves impossible. The IIS admin snap in 
returns "wrong executeable" even though the correct 
executeable "c:\program files\python22\python.exe %s %
s" is selected. This is because the two mappings must 
match exactly. 

The manual work around is to enter the 8.3 file name 
form of the "program to execute" against ".py" in the 
IIS admin snap-in rather than use the browse button 
(which returns the normal NT/XP long form of the 
name).

The better solution which would remove all confusion 
is to ensure the install script enters the full form 
of the file name in file association mapping.

i.e. associate 

.py with c:\program files\python22\python.exe

rather than

.py with c:\progra~1\python22\python.exe

which it does currently.

Then the IIS admin snapin would work as expected.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 06:30:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 22:30:33 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16rYrJ-0004pi-00@usw-sf-web4.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 18:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
>Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: A.M. Kuchling (akuchling)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 01:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 10:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 07:05:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 30 Mar 2002 23:05:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-537328 ] Problematic .py extension mapping on XP
Message-ID: <E16rZOh-0005Dv-00@usw-sf-web3.sourceforge.net>

Bugs item #537328, was opened at 2002-03-31 01:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470

Category: Installation
>Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: steve matheson (stevematheson)
>Assigned to: Tim Peters (tim_one)
Summary: Problematic .py extension mapping on XP

Initial Comment:

When the windows pre built version installs on 
windows xp it sets up a file association that 
maps ".py" to the c:\python22\python.exe executable 
as it should.

If python is installed in "c:\program files\python22" 
the map ".py" points to "c:\progra~1\python22". This 
is fine and from the command line <script>.py runs as 
expected.

However, if one then trys to set up a script map in 
IIS on XP (so that "http:\host\test\script.py" 
works) it proves impossible. The IIS admin snap in 
returns "wrong executeable" even though the correct 
executeable "c:\program files\python22\python.exe %s %
s" is selected. This is because the two mappings must 
match exactly. 

The manual work around is to enter the 8.3 file name 
form of the "program to execute" against ".py" in the 
IIS admin snap-in rather than use the browse button 
(which returns the normal NT/XP long form of the 
name).

The better solution which would remove all confusion 
is to ensure the install script enters the full form 
of the file name in file association mapping.

i.e. associate 

.py with c:\program files\python22\python.exe

rather than

.py with c:\progra~1\python22\python.exe

which it does currently.

Then the IIS admin snapin would work as expected.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-31 02:05

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as WontFix.  If you choose to 
install into a non-default location, you're responsible for 
dealing with the consequences.  Some years ago the 
PythonLabs installer did install under "Program Files" by 
deafault, and associated to the full path, and the problems 
*that* created for people were endless (especially embedded 
spaces).  Now we deliberately install into a non-
problematic ("short name" same as "long name", no embedded 
spaces) path by default.  Note that can you easily change 
the .py association yourself (Windows supplies several 
simple ways to do that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 08:48:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 00:48:12 -0800
Subject: [Python-bugs-list] [ python-Bugs-427345 ] CGIHTTPServer fix for Windows
Message-ID: <E16rb0W-00036K-00@usw-sf-web2.sourceforge.net>

Bugs item #427345, was opened at 2001-05-25 13: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: Nobody/Anonymous (nobody)
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: Thomas Justin Shaw (justinshaw)
Date: 2002-03-31 03:48

Message:
Logged In: YES 
user_id=135558

To: Matthew King
Thanks for reposting that solution.  That did seem to fix 
the problem.

To: Mark Lutz
Using: Win2000 Pro IE5 python2.2.1c locally
The bug shows up as a popup message but the page loads.
When I tried it accross a lan the page wouldn't even
load (blowing a little demo).  So I guess it is not ONLY a 
local problem.

Thanks for posting.
Justin Shaw

----------------------------------------------------------------------

Comment By: Thomas Justin Shaw (justinshaw)
Date: 2002-03-29 02:36

Message:
Logged In: YES 
user_id=135558

I'm experiencing a problem on windows.
When I execute the scripts as 
'http://localhost:8080/cgi-bin\junk.py' 
the page seems to load ok but I get the popup message:
Internet Explorer cannot open the Internet site 
http://localhost:8080/cgi-bin\junk.py
The connection with the server ws reset

On Netscape no errors but the download also takes forever. 
The slow download seems to be caused by the 
FieldStorage() call.


----------------------------------------------------------------------

Comment By: Matthew King (kyrrigle)
Date: 2002-03-28 16:21

Message:
Logged In: YES 
user_id=247536

this looks like the same issue as #430160.  and here's what 
I just wrote there...

it appears that IE is sending 2 extra bytes ('\r\n') after 
the request data.  and if you don't read those two extra 
bytes off, the window's socket handling gets messed up.

the result is that a partial response is returned and the 
socket closed.  IE tries to recover by re-POST'ing (which 
is behavior specified in the HTTP/1.1 RFC)... only they 
seem to add an embedded NULL the second time through, and 
the original socket problem happens again anyway.

Try reading an extra 2 bytes from the rfile before sending 
your response and the problem should go away.  (you can do 
that by 'self.rfile._rbufsize = content_length + 2' inside 
your do_POST method before reading the content)

not sure what the real fix for this should be?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 11:40

Message:
Logged In: YES 
user_id=6380

Load shedding.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-09 09: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 08: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 15: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 12: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  Sun Mar 31 10:40:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 02:40:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-537328 ] Problematic .py extension mapping on XP
Message-ID: <E16rclO-0004B6-00@usw-sf-web1.sourceforge.net>

Bugs item #537328, was opened at 2002-03-31 18:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470

Category: Installation
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: steve matheson (stevematheson)
Assigned to: Tim Peters (tim_one)
Summary: Problematic .py extension mapping on XP

Initial Comment:

When the windows pre built version installs on 
windows xp it sets up a file association that 
maps ".py" to the c:\python22\python.exe executable 
as it should.

If python is installed in "c:\program files\python22" 
the map ".py" points to "c:\progra~1\python22". This 
is fine and from the command line <script>.py runs as 
expected.

However, if one then trys to set up a script map in 
IIS on XP (so that "http:\host\test\script.py" 
works) it proves impossible. The IIS admin snap in 
returns "wrong executeable" even though the correct 
executeable "c:\program files\python22\python.exe %s %
s" is selected. This is because the two mappings must 
match exactly. 

The manual work around is to enter the 8.3 file name 
form of the "program to execute" against ".py" in the 
IIS admin snap-in rather than use the browse button 
(which returns the normal NT/XP long form of the 
name).

The better solution which would remove all confusion 
is to ensure the install script enters the full form 
of the file name in file association mapping.

i.e. associate 

.py with c:\program files\python22\python.exe

rather than

.py with c:\progra~1\python22\python.exe

which it does currently.

Then the IIS admin snapin would work as expected.


----------------------------------------------------------------------

>Comment By: steve matheson (stevematheson)
Date: 2002-03-31 22:40

Message:
Logged In: YES 
user_id=307994

Fair enough ... but it has just taken me about 6 hours to 
work out what was going on and I guess others will be 
eqaully frustrated so in the interests of building py a 
positive following perhaps you could change the installer 
to prevent the location being changed, or at least 
restrict the options, or as a last resort warn of the 
implications. Keep up the good work. Rgds Steve

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-31 19:05

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as WontFix.  If you choose to 
install into a non-default location, you're responsible for 
dealing with the consequences.  Some years ago the 
PythonLabs installer did install under "Program Files" by 
deafault, and associated to the full path, and the problems 
*that* created for people were endless (especially embedded 
spaces).  Now we deliberately install into a non-
problematic ("short name" same as "long name", no embedded 
spaces) path by default.  Note that can you easily change 
the .py association yourself (Windows supplies several 
simple ways to do that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 11:31:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 03:31:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16rdYC-0004fX-00@usw-sf-web1.sourceforge.net>

Bugs item #524600, was opened at 2002-03-02 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



----------------------------------------------------------------------

>Comment By: Martin v. Löwis (loewis)
Date: 2002-03-31 13:31

Message:
Logged In: YES 
user_id=21627

Then this *is* a gcc issue. First, gcc does not implement
the pragma, but should (I just added support for the SunPRO
pragma redefine_extname to gcc for precisely the same
reason: Sun also renames LFS functions). If the #ifdef
really is for DECC, then it is doubtful, though, whether gcc
should define DECC even if it supports the pragma.

It is questionable whose problem this is, but I doubt Compaq
will care much about breakage occurring only with a
third-party compiler. GCC has a strategy for this, so it is
a gcc bug that this strategy is not applied: fixincludes.
GCC produces shadow copies of the system headers to correct
all kinds of problems. It should apply such fixing also to
these headers.

For the specific case, it would probably be sufficient to
change the #define line to

#define stat __F64_stat

Then, taking an address of stat will take the address of
__F64_stat. Better yet, the fixed header files should use
the GCC equivalent of the DECC pragma:

int stat(char*, struct stat*)
  __attribute__((alias("__F64_stat");

Adding this to fixincludes will be a challenge, though; for
Sun, we decided that it is easier to implement the Sun
pragma (especially as it was protected with an #ifdef
__PRAGMA_REDEFINE_EXTNAME, so gcc does not need to claim
being SUNC).

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-31 07:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-30 09:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 04:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

----------------------------------------------------------------------

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 23:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 10:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


----------------------------------------------------------------------

Comment By: Mike Coleman (mkc)
Date: 2002-03-28 01:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-03 22:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 17:23:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 09:23:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization
Message-ID: <E16rj39-0004ph-00@usw-sf-web3.sourceforge.net>

Bugs item #537450, was opened at 2002-03-31 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improper object initialization

Initial Comment:
The descr tutorial specifies this rule:

  __new__ must return an object. There's nothing that
  requires that it return a new object that is an 
  instance of its class argument, although that is the 
  convention. If you return an existing object, the 
  constructor call will still call its __init__ 
  method. If you return an object of a different 
  class, its __init__ method will be called. 

I believe that this rule adds an unnecessary wart to 
the language, since it is not appropriate to call 
__init__, especially with the same arguments as 
__new__ on an 'unexpected' class returned by __new__.
It is simple enough to check that the resulting class 
is an instance of the expected class and to only then 
call __init__.  Otherwise, it should be assumed that 
__new__ is returning a fully constructed instance of 
another class.  In the rare and obscure case that one 
does wish to call __init__ on an object of a different 
class, then it may be done manually from within 
__new__.

So basically, my argument is for explicit versus
implicit semantics.  If __new__(cls) returns an 
instance where type(instance) is not cls, then
__init__ should not be called implicitly.  The
burden should be on the programmer to explicitly
ensure that the object is properly constructed.

Here is an example where the current rule results
in confusing and apparently random behavior
(if one doesn't have initimate knowledge of the
Python implementation, that is):

class Foo(object):
  def __new__(cls, x):
    if x == 0:
      return [1,2,3]
    if x == 1:
      return 1
    if x == 2:
      return (1,2,3)
    if x == 3:
      return '1'
    if x == 4:
      return {1:1,2:2,3:3}
    else:
      return super(cls, Foo).__new__(cls)

for i in range(6):
  try:
    print 'Foo(%d) =' % i,Foo(i)
  except:
    print 'Foo(%d) failed' % i

Which under Python 2.2 results in the following output:
  Foo(0) failed
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) failed
  Foo(5) = <__main__.Foo object at 0x8147f54>

Under the proposed new rule, the output would be
much more sensible:
  Foo(0) = [1,2,3]
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) = {1:1,2:2,3:3}
  Foo(5) = <__main__.Foo object at 0x8147f54>

If there is agreement on this issue, I will submit
a very simple patch to address this.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 18:30:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 10:30:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-536017 ] threading.Lock().acquire bug
Message-ID: <E16rk67-0002ZS-00@usw-sf-web2.sourceforge.net>

Bugs item #536017, was opened at 2002-03-27 21:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470

>Category: Threads
Group: Python 2.1.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fiona Lim (fionalim)
>Assigned to: Tim Peters (tim_one)
Summary: threading.Lock().acquire bug

Initial Comment:
According to the online documentation for threading
Lock objects, setting blocking=0 will produce a
non-blocking call.
But trying it in the command line causes the execution
to hang.
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(blocking=0)
>>> lock.acquire(blocking=0)
[blocks]

----------------------------------
internal documentation claims that the keyword is wait,
but using wait produces the same problem:

>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire.__doc__
'acquire([wait]) -> None or
Boolean\n(PyThread_acquire_lock() is an obsolete
synonym)\n\nLock the lock.  Without argument, this
blocks if the lock is already\nlocked (even by the same
thread), waiting for another thread to release\nthe
lock, and return None when the lock is acquired.\nWith
a Boolean argument, this will only block if the
argument is true,\nand the return value reflects
whether the lock is acquired.\nThe blocking operation
is not interruptible.'
>>> lock.acquire(wait=0)
>>> lock.acquire(wait=0)
[blocks]

---------------------------------
Not using a keyword works fine:
>>> import threading
>>> lock = threading.Lock()
>>> lock.acquire(0)
1
>>> lock.acquire(0)
0
>>> 



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-31 13:30

Message:
Logged In: YES 
user_id=31435

Thanks, Martin!  Since this is already much better in 2.2, 
I'll take responsibility for closing it as Fixed.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 05:33

Message:
Logged In: YES 
user_id=21627

This is fixed in Python 2.2; it will raise an exception
"acquire() takes no keyword arguments". That should make it
immediately clear how to read the documentation.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-27 22:31

Message:
Logged In: YES 
user_id=31435

Changed to docs and assigned to Fred for comment.  Any idea 
how we can make this clearer?  The docs don't claim this 
accepts a keyword argument, and lots of C functions simply 
ignore any keyword arguments that may be given.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536017&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 18:32:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 10:32:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16rk7e-0005Ui-00@usw-sf-web4.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 18:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: A.M. Kuchling (akuchling)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-31 13:32

Message:
Logged In: YES 
user_id=11375

I've already filed a request to add my CVS files to the
repository. 
http://sourceforge.net/tracker/?func=detail&aid=535390&group_id=1&atid=200001

When is 2.2.1 supposed to be wrapped for final release?  Do
I have another week?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 01:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 10:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 18:58:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 10:58:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-537328 ] Problematic .py extension mapping on XP [IIS]
Message-ID: <E16rkX2-0002rZ-00@usw-sf-web2.sourceforge.net>

Bugs item #537328, was opened at 2002-03-31 01:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470

Category: Installation
Group: Platform-specific
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: steve matheson (stevematheson)
Assigned to: Tim Peters (tim_one)
>Summary: Problematic .py extension mapping on XP [IIS]

Initial Comment:

When the windows pre built version installs on 
windows xp it sets up a file association that 
maps ".py" to the c:\python22\python.exe executable 
as it should.

If python is installed in "c:\program files\python22" 
the map ".py" points to "c:\progra~1\python22". This 
is fine and from the command line <script>.py runs as 
expected.

However, if one then trys to set up a script map in 
IIS on XP (so that "http:\host\test\script.py" 
works) it proves impossible. The IIS admin snap in 
returns "wrong executeable" even though the correct 
executeable "c:\program files\python22\python.exe %s %
s" is selected. This is because the two mappings must 
match exactly. 

The manual work around is to enter the 8.3 file name 
form of the "program to execute" against ".py" in the 
IIS admin snap-in rather than use the browse button 
(which returns the normal NT/XP long form of the 
name).

The better solution which would remove all confusion 
is to ensure the install script enters the full form 
of the file name in file association mapping.

i.e. associate 

.py with c:\program files\python22\python.exe

rather than

.py with c:\progra~1\python22\python.exe

which it does currently.

Then the IIS admin snapin would work as expected.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-03-31 13:58

Message:
Logged In: YES 
user_id=31435

A problem is that I don't know where to document this where 
someone who needs to know it would be likely to find it.  
That's a general problem with GUI installers:  the only 
natural place to document oddities is in one of the dialog 
screens, but everybody has been trained to ignore blocks of 
text in dialog screens.

You're also the first person to make a complaint about this 
(while there were countless complaints when we left spaces 
in paths).

All in all, this sounds like an IIS bug to me:  since 
Microsoft saw fit to create a brittle "every component of 
every file path has two distinct names" scheme, at least 
*their* software should deal with the consequences 
gracefully.  Did you file a bug report against IIS?  "Exact 
match" is lazy and doesn't respect MS filesystem semantics.

BTW, I wouldn't be surprised if the ActiveState Python 
installer left long names intact.  I'm accepting the Wise 
installer's default behavior in this respect.  I'm not 
deadly opposed to changing that, since we do suggest a non-
problematic path by default.

----------------------------------------------------------------------

Comment By: steve matheson (stevematheson)
Date: 2002-03-31 05:40

Message:
Logged In: YES 
user_id=307994

Fair enough ... but it has just taken me about 6 hours to 
work out what was going on and I guess others will be 
eqaully frustrated so in the interests of building py a 
positive following perhaps you could change the installer 
to prevent the location being changed, or at least 
restrict the options, or as a last resort warn of the 
implications. Keep up the good work. Rgds Steve

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-31 02:05

Message:
Logged In: YES 
user_id=31435

Sorry, I'm closing this as WontFix.  If you choose to 
install into a non-default location, you're responsible for 
dealing with the consequences.  Some years ago the 
PythonLabs installer did install under "Program Files" by 
deafault, and associated to the full path, and the problems 
*that* created for people were endless (especially embedded 
spaces).  Now we deliberately install into a non-
problematic ("short name" same as "long name", no embedded 
spaces) path by default.  Note that can you easily change 
the .py association yourself (Windows supplies several 
simple ways to do that).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537328&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 19:15:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 11:15:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16rknv-0002yq-00@usw-sf-web1.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 18:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: A.M. Kuchling (akuchling)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 14:15

Message:
Logged In: YES 
user_id=3066

If it can be done by sometime next weekend, that should be
good enough for me.  I think we're shooting for the
following Tuesday for the release, so I'll probably be
finishing the formatting on Monday.

Michael Hudson should correct me if I'm wrong on the
schedule.  ;-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-31 13:32

Message:
Logged In: YES 
user_id=11375

I've already filed a request to add my CVS files to the
repository. 
http://sourceforge.net/tracker/?func=detail&aid=535390&group_id=1&atid=200001

When is 2.2.1 supposed to be wrapped for final release?  Do
I have another week?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 01:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 10:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 19:57:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 11:57:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-537484 ] SMTPLib sendmail fails on hyphenated adr
Message-ID: <E16rlSW-0003TK-00@usw-sf-web2.sourceforge.net>

Bugs item #537484, was opened at 2002-03-31 12:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537484&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Anderson (shadowlore)
Assigned to: Nobody/Anonymous (nobody)
Summary: SMTPLib sendmail fails on hyphenated adr

Initial Comment:
When using smtplib's SMTP.sendmail, if the To: address
contains a hyphen, the To: header will be silently dropped.

To duplicate:

Follow the docstring for smtplib.SMTP.sendmail, and use
a hyphenated email address, such as foo-help@somewhere.org






----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537484&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 20:11:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 12:11:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16rlfX-0003a3-00@usw-sf-web1.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 23:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: A.M. Kuchling (akuchling)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:11

Message:
Logged In: YES 
user_id=6656

Sheesh, this is the third time I've attempted to follow up to 
this report.

Yes, 2.2.1 will be released on or about the ninth of April.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 19:15

Message:
Logged In: YES 
user_id=3066

If it can be done by sometime next weekend, that should be
good enough for me.  I think we're shooting for the
following Tuesday for the release, so I'll probably be
finishing the formatting on Monday.

Michael Hudson should correct me if I'm wrong on the
schedule.  ;-)

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-31 18:32

Message:
Logged In: YES 
user_id=11375

I've already filed a request to add my CVS files to the
repository. 
http://sourceforge.net/tracker/?func=detail&aid=535390&group_id=1&atid=200001

When is 2.2.1 supposed to be wrapped for final release?  Do
I have another week?


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 06:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 15:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 20:13:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 12:13:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-534108 ] AIX 3.2.5 Has No chroot/fsync Prototypes
Message-ID: <E16rlhw-0003bS-00@usw-sf-web1.sourceforge.net>

Bugs item #534108, was opened at 2002-03-23 20:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: AIX 3.2.5 Has No chroot/fsync Prototypes

Initial Comment:
`make' fails for Python-2.2.1c1 under AIX 3.2.5 due to
lack of prototypes for chroot and fsync in
Modules/posixmodule.c.  configure.in uses
AC_CHECK_FUNCS to check these two can be linked into
an executable, and configure correctly determines they
can.

    $ egrep 'chroot|fsync' config.cache
    ac_cv_func_chroot=${ac_cv_func_chroot='yes'}
    ac_cv_func_fsync=${ac_cv_func_fsync='yes'}
   
However, AC_CHECK_FUNCS essentially compiles and links

    #include "confdefs.h"
    #include <assert.h>
    char chroot();
    int main() {
    chroot();
    ; return 0; }
    
which under AIX 3.2.5 works fine.  But chroot isn't
prototyped in *any* system include file, nor is fsync.
Consequently, Modules/posixmodule.c has problems when
it attempts to use both chroot and fsync as an rvalue
for a pointer to a function.

    return posix_1str(args, "et:chroot", chroot);
    return posix_int(args, "i:fsync", fsync);
    
Both lines cause `Undeclared identifier' errors.
    
The solution is to conditionally add prototypes for
these two functions.  Modules/posixmodule.c has an
icky set of conditional prototypes at the start but 
they rely heavily on __IBMC__, __sun__, etc,
preprocessor symbols.  These could be expanded to
cover AIX 3.2.5's case but it may be better to use
autoconf's AC_CHECK_DECLS macro,
http://www.gnu.org/manual/autoconf/html_chapter/autoconf_5.html#SEC52.

By manually adding two prototypes at the start of the
source file I've confirmed the source file builds
successfully.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:13

Message:
Logged In: YES 
user_id=6656

Ralph, want do you want to do here?  Can you supply a way of 
identifying aix 3 with the preprocessor?

I'm worried that just bunging prototypes for chroot & fsync 
inside a "#if _AIX" might break AIX 4.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:54

Message:
Logged In: YES 
user_id=21627

AC_CHECK_DECLS is not supported in autoconf 2.13, so it is
not available for use in Python 2.2.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:41

Message:
Logged In: YES 
user_id=6656

Hmm, AC_CHECK_DECLS might well be useful (and not just for
these declarations).

However, I'm not an autoconf guru, and really don't want to
have to become one.

Is there a way to identify AIX 3 using the preprocessor?  Or
does AIX 4 not have these prototypes either?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534108&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 20:15:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 12:15:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16rlja-0003ce-00@usw-sf-web1.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 17:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:15

Message:
Logged In: YES 
user_id=6656

I'm proposing to close this, maybe adding a note to the 
README that says "if in difficulties, run ./configure --
without-gcc".

Objections?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 13:36

Message:
Logged In: YES 
user_id=6656

I'm getting lost.  What action is needed?

The LINKCC thing was fixed, but I forgot to run autoconf
before building the 2.2.1c1 tarball (sorry).

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 00:43

Message:
Logged In: YES 
user_id=911

BTW, the build then halts because 1.295 of configure.in
isn't in the release candidate so LINKCC's definition
in Makefile contains LINKCC and the recursion isn't welcome.
SF bug #477487 apparently.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 21:34

Message:
Logged In: YES 
user_id=911

Replying to a few comments at once...  The C compiler
on AIX comes in many guises.  They are normally all
hard links to the same executable.  /etc/xlc.cfg
defines these identities, so cc_r, if it exists, just
causes a certain set of options to be used.

* extended c compiler aliased as cc_r
cc_r: use        = DEFLT
    crt        = /lib/crt0_r.o
    mcrt       = /lib/mcrt0.o
    gcrt       = /lib/gcrt0.o
    libraries  = -L/usr/lib/dce,-lc_r,-lpthreads
    proflibs   = -L/lib/profiled,-L/usr/lib/profiled
    options    = -H512,-T512,-qlanglvl=extended,
        -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_,
        -qnoroconst

So
http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html
is wrong when it says that you can't use cc with an
appropriate set of options since that's all that cc_r,
cckern, c89, xlc_r, or any of the other hard links
are.

However, not all AIX installations have all bits of
the C compiler available to support all its guises.
So I think it's preferable to use cc_r if it is
available, else fall-back on cc.  And if using cc
hopefully configure's testing for whether threads is
available will determine it isn't.

This is all based on AIX 3, AIX 4 expanded on this in
a few ways.

In summary, I'd agree with donnc `Without cc_r, just
don't enable threads'.  Hopefully, that'll happen
automatically.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 18:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 18:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-22 17:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 17:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 10:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 20:19:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 12:19:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16rln3-0003f3-00@usw-sf-web1.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 20:21:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 12:21:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16rlpR-0003gq-00@usw-sf-web1.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 02:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. Löwis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 16:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 16:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-29 15:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 04:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 22:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 21:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 16:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 16:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 16:02

Message:
Logged In: YES 
user_id=133413

Here it is.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 15:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 13:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 13:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 10:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 00:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-28 00:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 19:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 16:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

----------------------------------------------------------------------

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 15:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 21:59:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 13:59:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-537511 ] ref to non-existant PyArg_ConvertTuple
Message-ID: <E16rnMN-0004gW-00@usw-sf-web1.sourceforge.net>

Bugs item #537511, was opened at 2002-03-31 16:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537511&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref to non-existant PyArg_ConvertTuple

Initial Comment:
In Doc/ext/extending.tex, there is a reference to
PyArg_ConvertTuple which does not exist.  I'm not sure
what this is referring to, otherwise I would fix it. 
Perhaps, PyArgUnpackTuple is meant?  If someone can
provide quick guidance, I can fix it.

Here's the text:

status = converter(object, address);

where \var{object} is the Python object to be converted
and \var{address} is the \ctype{void *} argument that
was passed to \cfunction{PyArg_ConvertTuple()}.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537511&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 22:54:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 14:54:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-537533 ] Grossly inefficient re
Message-ID: <E16roDr-0005MZ-00@usw-sf-web2.sourceforge.net>

Bugs item #537533, was opened at 2002-04-01 01:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537533&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Pekka Pessi (ppessi)
Assigned to: Fredrik Lundh (effbot)
Summary: Grossly inefficient re

Initial Comment:
Here is a regexp (ported from a awk script,
supposed to match C comments):

/[*][^*]*([*]+[^/][^*]+)*[*]+/

The regexp is *sometimes* *very* slow when run in
Python. Also, while replacing the regexp with
sub(), the Python interpreter is in deep recursion
in sre and does not respond to any signals.

I *think* this should be a O(N) regexp.

An example script demonstrating the problem is
attached. I have an example where adding two
characters to the input makes the re.sub() some
250000 times longer to execute.

There was no noticeable difference between sre and
pre modules.

I have a RedHat 7.2 box with a 600 MHz
PentiumIII, I'm using is Python 2.2 Linux RPMs
by Sean Reifschneider <jafo-rpms@tummy.com>:

Python 2.2 (#1, Dec 23 2001, 09:30:32) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2

Same problem applies to the Python 1.5.2 provided by
Redhat:
Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96
20000731 (Red Hat Linux 7.1 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum,
Amsterdam


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537533&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 23:17:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 15:17:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16roZM-0005aa-00@usw-sf-web2.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Nobody/Anonymous (nobody)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2002-03-31 23:17

Message:
Logged In: YES 
user_id=56214

Patch #537536 submitted to fix this.  "make test" output is
same as before the patch.  If someone can give me an idea of
where/how to insert a regression test for the bug being
fixed, I'll submit a patch for that, too.  Thanks.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


----------------------------------------------------------------------

Comment By: Martin v. Löwis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 23:40:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 15:40:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16rovz-0000ID-00@usw-sf-web4.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

----------------------------------------------------------------------

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 23:42:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 15:42:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-532007 ] urllib ftp broken if Win32 proxy
Message-ID: <E16roxp-0000NG-00@usw-sf-web3.sourceforge.net>

Bugs item #532007, was opened at 2002-03-19 14:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Medberry (medberry)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib ftp broken if Win32 proxy

Initial Comment:
If Win32 has a proxy enabled, ftp urls will NOT work in
urllib.

Here is a trace:
Traceback (most recent call last):
  File
"C:\Python22\lib\site-packages\Pythonwin\pywin\framework\scriptutils.py",
line 301, in RunScript
    exec codeObject in __main__.__dict__
  File "C:\Python22\Lib\urllib.py", line 1457, in ?
    main()
  File "C:\Python22\Lib\urllib.py", line 1448, in main
    test(args)
  File "C:\Python22\Lib\urllib.py", line 1410, in test
    fn, h = urlretrieve(url, None, reporthook)
  File "C:\Python22\Lib\urllib.py", line 80, in urlretrieve
    return _urlopener.retrieve(url, filename,
reporthook, data)
  File "C:\Python22\Lib\urllib.py", line 210, in retrieve
    fp = self.open(url, data)
  File "C:\Python22\Lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\Lib\urllib.py", line 438, in open_ftp
    host, path = splithost(url)
  File "C:\Python22\Lib\urllib.py", line 944, in splithost
    match = _hostprog.match(url)
TypeError: expected string or buffer

If the Win32 proxy is removed, it resumes working. In
urllib splithost, url is None or an empty tuple
(instead of the actual url.)

To reproduce, just enable a proxy on Win32 and execute
the "urllib.py -t" selftest. Disable the proxy and it
will be restored.

I haven't got the setup to check if web_proxy or
ftp_proxy on Posix machines causes the same problem.



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:42

Message:
Logged In: YES 
user_id=6380

Medberry, can you see if the patch from SF bug 503031
(http://www.python.org/sf/503031) solves your problem?

----------------------------------------------------------------------

Comment By: David Medberry (medberry)
Date: 2002-03-19 17:46

Message:
Logged In: YES 
user_id=95087

<bold>Is this bold?</bold>

----------------------------------------------------------------------

Comment By: David Medberry (medberry)
Date: 2002-03-19 17:44

Message:
Logged In: YES 
user_id=95087

This is _NOT_ a bug under Linux Python 2.2--it works just
fine there. (Makes me curious why it would behave
differently under Windows, but I'm not sure where to look yet.)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532007&group_id=5470


From noreply@sourceforge.net  Sun Mar 31 23:44:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 15:44:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-426866 ] urllib and socket fail with MS proxy
Message-ID: <E16rp0I-0005sN-00@usw-sf-web2.sourceforge.net>

Bugs item #426866, was opened at 2001-05-24 02:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Nobody/Anonymous (nobody)
Summary: urllib and socket fail with MS proxy 

Initial Comment:
Both urllib and socket fail to work with MS proxy with 
winsock client install.

urllib's proxy detection will correctly detect the 
existing of the proxy server but fail to work with it. 
It will return an empty page when an read() is issued.

socket will report 1006 winsock error.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:44

Message:
Logged In: YES 
user_id=6380

Can you see if the patch from SF bug 503031
(http://www.python.org/sf/503031) solves your problem?

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-03-09 20:18

Message:
Logged In: YES 
user_id=44345

Jeremy,

I assigned this to you simply because you commented on 
it.
It was submitted anonymously and the OP never responded 
to
your comment.  I think it should be marked "invalid" and
closed.  Whaddya think?

Skip


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-07-06 12:16

Message:
Logged In: YES 
user_id=31392

Can you provide more details?  What is MS proxy?  What URLs 
have you tried and what exactly is the response -- headers 
would help?  Under what conditions does socket raise a 
winsock error?

Do socket and urllib work on your platform without the 
proxy?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=426866&group_id=5470