[ python-Bugs-1172785 ] doctest.script_from_examples() result sometimes un-exec-able

[SourceForge.net]

Bugs item #1172785, was opened at 2005-03-29 15:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172785&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan E. Guyer (jguyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: doctest.script_from_examples() result sometimes un-exec-able

Initial Comment:
doctest.script_from_examples() can sometimes return results that 
cannot be passed to exec. The docstring for script_from_examples() 
itself is an example:

guyer% python2.4
Python 2.4 (#1, Mar 10 2005, 18:08:38) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1671)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> text = '''
... Here are examples of simple math.
... Python has super accurate integer addition
... >>> 2 + 2
... 5
... 
... And very friendly error messages:
... 
... >>> 1/0
... To Infinity 
... And
... Beyond
... 
... You can use logic if you want:
... 
... >>> if 0:
... ...blay 
... ...blah
... ...
... 
... Ho hum
... '''
>>> exec doctest.script_from_examples(text)
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 21
# Ho hum
  ^
SyntaxError: invalid syntax


The issue seems to be the lack of trailing '\n', which is documented 
as required by compile(), although not for exec. 

We never saw a problem with this in Python 2.3's doctest, probably 
because comment lines, such as "Ho hum", were stripped out and 
apparently adequate '\n' were appended.

Python 2.4 on Mac OS X 10.3.8

--

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

[ python-Bugs-1172763 ] dumbdbm hoses index on load failure

[SourceForge.net]

Bugs item #1172763, was opened at 2005-03-29 15:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172763&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: currivan (currivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumbdbm hoses index on load failure

Initial Comment:
Using python to read a dumbdbm db created with jython
on Windows, the index got erased.  The load failed with
an exception due to the python os.linesep being "\n",
while the jython version created the db with "\r\n".  

On exit, the python dumbdbm module committed the empty
index it had read, destroying the db.  commit (or sync)
is implicitly being called on exit from python.

dumbdbm ignores the flag it was opened with and commits
even if it was opened with 'r'.  jython doesn't seem to
support any other standard dbm implementation, so I'm
stuck with dumbdbm.

The problem can be worked around by setting os.linesep
manually to enforce consistency.


--

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

[ python-Bugs-1075984 ] Memory fault pyexpat.so on SGI

[SourceForge.net]

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

Category: XML
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Maik Hertha (mhertha)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory fault pyexpat.so on SGI

Initial Comment:
I build the latest RC1 of python 2.4.
System SGI Fuel IP35, Irix 6.5.26m

cc -version
MIPSpro Compilers: Version 7.3.1.3m

- make tests passes test_pyexpat without error
- running this code leads to a core dump

-- code ---
import xml.dom.minidom
doc = xml.dom.minidom.parseString(fstream)

<<< core dump >>>
--- runing python -v test.py
#
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
matches
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.py
import xml.dom.expatbuilder # precompiled from
/opt/python24c1/lib/python2.4/xml/dom/expatbuilder.pyc
import xml.parsers # directory
/opt/python24c1/lib/python2.4/xml/parsers
#
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
matches
/opt/python24c1/lib/python2.4/xml/parsers/__init__.py
import xml.parsers # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/__init__.pyc
# /opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
matches /opt/python24c1/lib/python2.4/xml/parsers/expat.py
import xml.parsers.expat # precompiled from
/opt/python24c1/lib/python2.4/xml/parsers/expat.pyc
dlopen("/opt/python24c1/lib/python2.4/lib-dynload/pyexpat.so",
2);
Memory fault(coredump)

- running this code from an interactive session leads
not to a coredump

I need some assistance howto provide further debug
information.

--maik./

--

Comment By: Bernhard Herzog (bernhard)
Date: 2005-03-29 20:11

Message:
Logged In: YES 
user_id=2369

I ran into this problem as well on a debian GNU/Linux system
on x86 hardware.  It occurs both with pygtk 2.4 and wxPython
2.5 both built against gtk 2.4.

bos' patch at least solves the immediate problem of the
segmentation fault.  It may be a good idea to print a
warning message if some of the error codes cannot be
translated to strings, though.


--

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-05 00:16

Message:
Logged In: YES 
user_id=28380

With the GNU linker, you can pass in -Bstatic to force it to resolve the 
symbols in the local shared library, instead of globally. This also works on 
Irix. I don't know about other Unixes.

--

Comment By: Michael Hudson (mwh)
Date: 2005-02-02 11:35

Message:
Logged In: YES 
user_id=6656

It's a nasty one, I'll give you that.

Fred, what do you think of bos's patch?  It solves the immediate issue, 
but I'm not sure it's a complete fix.

It seems to me that it would be better to resolve the expat symbols at 
builf time, but I don't know how to arrange for that.

--

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-02 07:09

Message:
Logged In: YES 
user_id=28380

By the way, this is not an SGI-specific bug. This will bite any Unix system 
with a modern sysv-style dynamic linker. The priority of this bug should be 
higher, IMO.

--

Comment By: Bryan O'Sullivan (bos)
Date: 2005-02-01 08:53

Message:
Logged In: YES 
user_id=28380

I've been bitten by the same bug. In my case, the problem was with Qt, not GTK.

It's not actually necessary to check the expat version; just see if 
XML_ErrorString actually returns anything.

Here's the patch I use for this problem:

--- python/Modules/pyexpat.c2005-01-06 16:26:13 -08:00
+++ python/Modules/pyexpat.c  2005-01-31 23:46:36 -08:00
@@ -1936,9 +1936,12 @@
 }
 #endif

-#define MYCONST(name) -PyModule_AddStringConstant(errors_module, #name, -  
 (char*)XML_ErrorString(name))
+#define MYCONST(name)   +{ +char *_v = 
(char*)XML_ErrorString(name); +if (_v) +
PyModule_AddStringConstant(errors_module, #name, _v); +}

 MYCONST(XML_ERROR_NO_MEMORY);
 MYCONST(XML_ERROR_SYNTAX);


--

Comment By: Stephen Watson (kerofin)
Date: 2004-12-13 14:46

Message:
Logged In: YES 
user_id=471223

pyexpat initializes using its internal copy of expat. 
libexpat.so is still mapped in (after pyexpat has
initilized), but gdb finds the python copy of
XML_ErrorString and other functions.

I suspect that this will be a problem if the system version
of expat is newer than Python's.


--

Comment By: Michael Hudson (mwh)
Date: 2004-12-13 14:01

Message:
Logged In: YES 
user_id=665

[ python-Bugs-1172554 ] "cmp" should be "key" in sort doc

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-29 10:35

Message:
Logged In: YES 
user_id=80475

Thanks for the report.
This was already fixed.
You should see it in the new Py2.4.1.

--

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

[ python-Bugs-1172554 ] "cmp" should be "key" in sort doc

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

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

[ python-Bugs-1172581 ] "cmp" should be "key" in sort doc

[SourceForge.net]

Bugs item #1172581, was opened at 2005-03-29 15:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1172581&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Keith Briggs (kbriggs)
Assigned to: Nobody/Anonymous (nobody)
Summary: "cmp" should be "key" in sort doc

Initial Comment:
http://www.python.org/doc/current/lib/typesseq-
mutable.html:

> key specifies a function of one argument that is used 
to extract a comparison key from each list 
element: "cmp=str.lower" 

I think should be 

key specifies a function of one argument that is used to 
extract a comparison key from each list 
element: "key=str.lower" 

--

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

[ python-Bugs-1170766 ] weakref.proxy incorrect behaviour

[SourceForge.net]

Bugs item #1170766, was opened at 2005-03-25 21:54
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 14:39

Message:
Logged In: YES 
user_id=6656

Also see bug #1075356 (which is very minor, but might as
well get fixed at the same time).

--

Comment By: Armin Rigo (arigo)
Date: 2005-03-29 14:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, 
sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), 
etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show 
that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same 
way that nb_nonzero was.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 12:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



--

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 14:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying 
object's nb_nonzero slot instead of going through the general PyObject_IsTrue() 
mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in 
addition to tp_compare.  In fact, we should review the code to check if 
ProxyType knows about the most recent type slots...

--

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

[ python-Bugs-1165761 ] KeyboardInterrupt causes segmentation fault with threads

[SourceForge.net]

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

Category: Threads
Group: Python 2.4
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: KeyboardInterrupt causes segmentation fault with threads

Initial Comment:
The attached sample program crashes Python 2.4.1c1 with a 
segmentation fault if it is interupted.

I wrote a simple program which simulates multiple HTTP clients.

The program is mult-threaded.

It runs on Debian with a 2.6 kernel.

If the program is interrupted (via ^C), Python 2.4.1c1 takes a 
segmentation fault.

Investigation with gdb shows that the error occurs within 
PyEval_EvalFrame at line 1661 below.
It's executing an END_FINALLY bytecode.
The offending statement is
   v = POP();
The value of v is 0.
This is then passed to PyInt_Check(), which attempts to dereference 
a NULL pointer.


1659case END_FINALLY:
1660v = POP();
1661if (PyInt_Check(v)) {
1662why = (enum why_code) 
PyInt_AS_LONG(v);
1663assert(why != WHY_YIELD);
1664if (why == WHY_RETURN ||
1665why == WHY_CONTINUE)
1666retval = POP();
1667}



#0  PyEval_EvalFrame (f=0x821cd04) at Python/ceval.c:1661
#1  0x080ae6bd in fast_function (func=0x4030df8d, 
pp_stack=0xbfffe85c, n=1, na=1076944740, nk=1079484852) at 
Python/ceval.c:3629
#2  0x080ae254 in call_function (pp_stack=0xbfffe85c, 
oparg=1076944740) at Python/ceval.c:3568
#3  0x080ac7a6 in PyEval_EvalFrame (f=0x8227d04) at Python/
ceval.c:2163
#4  0x080ad21e in PyEval_EvalCodeEx (co=0x4037e660, 
globals=0x4030df64, locals=0x4030df8d, args=0x40295c78, 
argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, 
closure=0x0)
at Python/ceval.c:2730
#5  0x08105647 in function_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x0) at Objects/funcobject.c:548
#6  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#7  0x08062e38 in instancemethod_call (func=0x4038a304, 
arg=0x40295c6c, kw=0x4030df64) at Objects/classobject.c:2431
#8  0x0805c409 in PyObject_Call (func=0x8148088, 
arg=0x4030df64, kw=0x4030df64) at Objects/abstract.c:1751
#9  0x080ae0e7 in PyEval_CallObjectWithKeywords 
(func=0x4030df64, arg=0x4028702c, kw=0x405785a4) at Python/
ceval.c:3419
#10 0x0809101c in slot_tp_del (self=0x4057a1b4) at Objects/
typeobject.c:4818
#11 0x08086f93 in subtype_dealloc (self=0x4057a1b4) at Objects/
typeobject.c:669
#12 0x08062a4c in instancemethod_dealloc (im=0x4057857c) at 
Objects/classobject.c:2225
#13 0x080790a4 in dict_dealloc (mp=0x4056aacc) at Objects/
dictobject.c:734
#14 0x0805e544 in instance_dealloc (inst=0x40569dcc) at Objects/
classobject.c:687
#15 0x081042cb in frame_dealloc (f=0x8218f14) at Objects/
frameobject.c:418
#16 0x080dc1e9 in PyThreadState_Clear (tstate=0x81f9820) at 
Python/pystate.c:217
#17 0x080dbdf8 in PyInterpreterState_Clear (interp=0x8148048) at 
Python/pystate.c:93
#18 0x080dcef2 in Py_Finalize () at Python/pythonrun.c:408
#19 0x08055391 in Py_Main (argc=1, argv=0xbfffee14) at Modules/
main.c:504
#20 0x08054eeb in main (argc=1076944740, argv=0x4030df64) at 
Modules/python.c:23


--

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-29 23:36

Message:
Logged In: YES 
user_id=29957

Checked in on 2.4 branch and on trunk.


--

Comment By: Tim Peters (tim_one)
Date: 2005-03-29 05:12

Message:
Logged In: YES 
user_id=31435

Note that I already marked the patch as Accepted.

Re-assigning to Anthony, since he said he'll check it in.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-29 01:15

Message:
Logged In: YES 
user_id=29957

This patch applies, and seems to work. I can't see any
reasons for it to _not_ go into 2.4.1 final, unless someone
else can see a reason to avoid it, I'll check it in, in the
morning.


--

Comment By: Michael Hudson (mwh)
Date: 2005-03-28 21:53

Message:
Logged In: YES 
user_id=6656

Oh, pig.  Here's the patch with the irrelevant stuff from my new-style 
exceptions work chopped out (I should check that in soon, too I guess).

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-28 18:39

Message:
Logged In: YES 
user_id=29957

This patch won't compile for me on the 2.4 br

[ python-Bugs-1170766 ] weakref.proxy incorrect behaviour

[SourceForge.net]

Bugs item #1170766, was opened at 2005-03-25 21:54
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1170766&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander Kozlovsky (kozlovsky)
Assigned to: Nobody/Anonymous (nobody)
Summary: weakref.proxy incorrect behaviour

Initial Comment:
According documentation, proxy in most contexts must 
have the same behaviour as object itself.

PROBLEM:

bool(proxy_object) != bool(object_itself)

EXAMPLE:

>>> class X(list): pass # collection class
... 
>>> x = X() # empty collection
>>> import weakref
>>> proxy = weakref.proxy(x)
>>> bool(x)
False
>>> bool(proxy)
True

PYTHON VERSION:

2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit 
(Intel)]

also tested on:

2.3.4 (#53, May 25 2004, 21:17:02) [MSC v.1200 32 bit 
(Intel)]

--

>Comment By: Armin Rigo (arigo)
Date: 2005-03-29 13:23

Message:
Logged In: YES 
user_id=4771

The following type slots appear to be missing in the proxy types:

* nb_(inplace_){floor,true}_divide
* sq_repeat, sq_concat, sq_item, sq_ass_item, sq_inplace_concat, 
sq_inplace_repeat (which are needed for operator.repeat(), operator.concat(), 
etc. to work)
* tp_as_buffer
* tp_richcompare (tp_compare alone is not enough)
* tp_descr_get, tp_descr_set (for proxies to descriptors...)
* nb_coerce (though it seems that only an explicit call to coerce() can show 
that this is missing; implicit coercion is done correctly in other operators)
* nb_oct, nb_hex

As far as I can tell, there is no existing operator that is broken in the same 
way that nb_nonzero was.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-27 11:17

Message:
Logged In: YES 
user_id=80475

Fixed the __nonzero__ problem for Py2.5 and will backport to
Py2.4.  See Objects/weakrefobject.c 1.21.

Leaviing this report open until the rest of the module can
be checked and fixed.



--

Comment By: Armin Rigo (arigo)
Date: 2005-03-26 14:50

Message:
Logged In: YES 
user_id=4771

The bug is in weakrefobject:proxy_nonzero(), which calls the underlying 
object's nb_nonzero slot instead of going through the general PyObject_IsTrue() 
mecanism.  Built-in types like list and dict don't have a nb_nonzero slot.

As a related bug, (Callable)ProxyType should implement tp_richcompare in 
addition to tp_compare.  In fact, we should review the code to check if 
ProxyType knows about the most recent type slots...

--

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

[ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Michael Hudson (mwh)
Summary: Assignment to __bases__ of direct object subclasses

Initial Comment:
I'm not entirely sure this is a bug, but I think it is 
surprising:

Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC 
v.1200 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or 
"license" for more 
information.
>>> class A(object):
... pass
...
>>> class B(object):
... pass
...
>>> B.__bases__ = (A,)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: __bases__ assignment: 'A' deallocator differs 
from 'object'

It seems like you should be able to change the 
__bases__ of a new-style class (implemented in 
Python) which inherits directly from object to another 
new-style class.  (Will the deallocator issue ever come 
into play if the only types involved are HEAPTYPES and 
object as the ultimate base?)


--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:21

Message:
Logged In: YES 
user_id=6656

Well, my motivation is to better understand what's going on
in typeobject.c.  There are a number of unclear sections (to
put it mildly) and undocumented assumptions and this makes
it hard to work out whether things (like this) are bugs or not.

I'm now fairly confident that the line
"compatible_for_assigment(new_base, self->tp_base)" is
asking the right question (and, thus, your patch is not
really correct, though I doubt it's actually unsafe).  The
spelling is a bit funny though.

This issue in and of itself isn't that high a priority, but
understanding (and documenting that understanding) of
typeobject.c does seem worth working on...

--

Comment By: Greg Chapman (glchapman)
Date: 2005-03-28 23:54

Message:
Logged In: YES 
user_id=86307

Still here -- sorry not to reply sooner.  I couldn't
actually remember what my patch was supposed to do, or more
specifically I couldn't remember what it did to check that
this sort of change in __bases__ was safe.  So, anyway, I
finally got around to looking at the patch again, and at
typeobject.c, and I can say that I'm less sure of the
subtleties involved now than I was then.  Anyway, with that
caveat, what you suggest sounds reasonable enough, though I
suppose you'd have to reinsert a dict descriptor if
__bases__ was later changed back to (object,).  (It looks
like the patch would have supported changing __bases__ back
to (object,), though perhaps it shouldn't.)

It seems to me nobody is particularly troubled by this
limitation on assignment to __bases__ (perhaps you know
differently?).  Maybe it's best just to close this as "not a
bug."


--

Comment By: Michael Hudson (mwh)
Date: 2005-03-16 13:22

Message:
Logged In: YES 
user_id=6656

Two years on, I think about this again.  Still here? :)

The motivating thought is that:

class A(object): pass
class B(object): pass
B.__bases__ = (A,)

and 

class A(object): pass
class B(A): pass

should be equivalent.

An issue that hadn't occurred to me before is that in the first example both 
A and B have a __dict__ (and __weakref__) descriptor, and in the second 
B doesn't.  Should B's __dict__ descriptor be removed on the 
__bases__ assignment?

--

Comment By: Michael Hudson (mwh)
Date: 2003-02-05 14:22

Message:
Logged In: YES 
user_id=6656

Mhmm.  That looks OK to me (after realizing that solid_base
worries about __slots__).

But I don't know how one can be sure :-(

--

Comment By: Greg Chapman (glchapman)
Date: 2003-02-05 02:39

Message:
Logged In: YES 
user_id=86307

Well, I wrote a small patch which I'm attaching.  However, I 
can't say that I'm partcularly confident in it.  It works for the 
simple cases I've  been able to think of (and for 
test_descr.py), but looking at typeobject.c, I get the nagging 
feeling that a lot more tests are required to be sure it's OK.  
The problem is, I'm just not sure what they (the tests) are.


--

Comment By: Michael Hudson (mwh)
Date: 2003-01-31 18:09

Message:
Logged In: YES 
user_id=6656

Are you interested in working up a patch for this?  Hacking
this kind of stuff requires motivation I'm not sure I can
drum up in time for 2.3...

--

Comment By: Greg Chapman (glchapman)
Date: 2003-01-23 17:03

Message:
Logged I

[ python-Bugs-1166660 ] The readline module can cause python to segfault

[SourceForge.net]

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

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Michael Hudson (mwh)
Summary: The readline module can cause python to segfault

Initial Comment:
When starting an interactive interpreter in another
thread, with readline's completion functionality, there
exists a race condition which causes the Python
interpreter to segfault. There's a small discussion
about this bug at
.

Attached is a small proof-of-concept code. Please note
that some people couldn't reproduce this on slower
machines. I've managed to reproduce it on several Linux
systems (Dual Xeon computers), using Python 2.3.4, 2.4
and 2.4.1c2.

Thanks in advance.

--

>Comment By: Michael Hudson (mwh)
Date: 2005-03-29 13:10

Message:
Logged In: YES 
user_id=6656

Unless there's some reason to suspect they share a common
cause (and, I don't see one) a second report is more
appropriate.

Also, if you understand what's going on, you can explain
there :)

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-28 23:33

Message:
Logged In: YES 
user_id=326689

I haven't (Completely forgot about it, after finding the
main one...). Should I post a seperate bug report, or will
this one do?

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-27 21:43

Message:
Logged In: YES 
user_id=6656

I'll take a look at this.

Did you submit a bug on the set_startup_hook problem mentioned in the 
ipython tracker?

--

Comment By: Yariv Ido (dcoder)
Date: 2005-03-19 23:59

Message:
Logged In: YES 
user_id=326689

I may be completely off track here, but shouldn't
on_completion(...) (readline.c) use _PyOS_ReadlineTState
instead of completer_tstate to restore the GIL?

Also, in readline_until_enter_or_signal(...), shouldn't
PyEval_SaveThread()'s return value be saved back to 
_PyOS_ReadlineTState?

It seems that these patches manage to fix the above
segmentation fault...

--

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