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

[SourceForge.net]

Bugs item #1165761, was opened at 2005-03-18 05:18
Message generated for change (Comment added) made by mwh
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: Open
Resolution: None
Priority: 5
Submitted By: Jeff Stearns (jeffstearns)
Assigned to: Nobody/Anonymous (nobody)
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: Michael Hudson (mwh)
Date: 2005-03-19 10:29

Message:
Logged In: YES 
user_id=6656

Well, sure.  However, the attached patch makes at least some of them go 
away; it also makes this comment from Py_Finalize:

/* Now we decref the exception classes.  After this point nothing
   can raise an exception.  That's okay, because each Fini() method
   below has been checked to make sure no exceptions are ever
   raised.
*/
less hilariously inaccurate.  I'm not saying it's anything like a thorough fix.

I'm away for a week from about five minutes time, so if you like it, check it 
in yourself, please.

--

Comment By: Tim Peters (tim_one)
Date: 2005-03-18 21:38

Message:
Logged In: YES 
user_id=31435

I'm thinking maybe we should rename .setDaemon() 
to .generateRandomShutdownSegfaults() -- pretty much the 
same thing in practice!  Unless/until teardown is rewritten to 
be purely gc-based, asking a thread to keep running while 
the interpreter is destroying itself is going to be vulnerable.

--

Comment By: Michael Hudson (mwh)
Date: 2005-03-18 15:43

Message:
Logged In: YES 
user_id=6656

Can you try the attached patch?

[ python-Bugs-1164631 ] super(...).__new__( ... ) behaves "unexpected"

[SourceForge.net]

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

Category: Type/class unification
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'---> why does super( MA, metacls ).__new__ call MC.
__new__ in next line '




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




--

>Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 10:32

Message:
Logged In: YES 
user_id=360037

Okay, that's the point.
Thanx for your time and work - bug becomes deleted.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 01:30

Message:
Logged In: YES 
user_id=1038590

Additional text from the descrintro essay, indicating that
it is deliberate that C3 does not trigger an exception:

"""However, if one of the base metaclasses satisfies the
constraint (including the explicitly given __metaclass__, if
any), the first base metaclass found satisfying the
constraint will be used as the metaclass."""

So, unless Guido chooses to change the desired behaviour,
these two snippets pretty much cover what needs to be added
to the docs.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 00:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-19 00:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


--

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-18 19:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived by accident -- and the error could show up as 
memory corruption, instead of something meaningful.


--

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-18 15:48

Message:
Logged In: YES 
user_id=360037

Ok - I think I found the reason for the behaviour I explained 
above ...

typeobject.c:
  function type_new(...)
   [...]
   /* Determine the proper [..

[ python-Bugs-1160383 ] digit-only tag values are mishandled in Tkinter

[SourceForge.net]

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

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. Löwis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()   
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

--

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 08:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
   Each  item may also have any number of tags
associated with it.  A tag
   is just a string of characters, and it may take any
form  except  that
   of  an  integer.   For example, ‘‘x123’’ is OK but
‘‘123’’ isn’t.  The
   same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

--

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

[ python-Bugs-1099324 ] Optik OptionParse important undocumented option

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: ncouture (nicolas_couture)
Assigned to: Greg Ward (gward)
Summary: Optik OptionParse important undocumented option

Initial Comment:
the add_help_option variable is undocumented in
Python's Library Reference, tho it can be figured by
reading the optparse module, I think it would be
usefull to document it on
http://docs.python.org/lib/optparse-generating-help.html.

--

>Comment By: Greg Ward (gward)
Date: 2005-03-19 11:28

Message:
Logged In: YES 
user_id=14422

Fixed in Optik svn r501.
Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


--

Comment By: Johannes Gijsbers (jlgijsbers)
Date: 2005-01-10 15:57

Message:
Logged In: YES 
user_id=469548

This should probably be addressed by fixing
http://python.org/sf/993601.

--

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

[ python-Bugs-993601 ] optparse needs reference documentation

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Greg Ward (gward)
Summary: optparse needs reference documentation

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

--

>Comment By: Greg Ward (gward)
Date: 2005-03-19 11:30

Message:
Logged In: YES 
user_id=14422

Partially addressed in Optik svn r501 (everything important
but the list of keyword args to parser.add_option() is
documented now).  More updates coming soon, I hope.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


--

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

[ python-Bugs-1160383 ] digit-only tag values are mishandled in Tkinter

[SourceForge.net]

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

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. Löwis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()   
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

--

>Comment By: Fredrik Lundh (effbot)
Date: 2005-03-19 17:53

Message:
Logged In: YES 
user_id=38376

Here's the text before the quoted line:

"Everywhere a method expects an item specifier, you can 
use one of the following: * item handles * tags /.../ Item 
handles are integer values that are used to identify a specific 
item on the canvas /.../ Item handles can be passed to the 
various canvas methods either as integers or as strings. /.../"

Note the use of "one of", and the fact that item handles are 
described before tags. (Writing documentation for people who 
only reads random sentences is pretty much impossible...)

--

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 15:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
   Each  item may also have any number of tags
associated with it.  A tag
   is just a string of characters, and it may take any
form  except  that
   of  an  integer.   For example, ‘‘x123’’ is OK but
‘‘123’’ isn’t.  The
   same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

--

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

[ python-Bugs-993601 ] optparse needs reference documentation

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Greg Ward (gward)
Summary: optparse needs reference documentation

Initial Comment:
The optparse libref documentation, while extensive, 
doesn't actually include an API reference. There's no way 
of knowing the valid parameter set of 
OptionParser.add_option() without going through the 
source. 
 
Please consider adding an API reference page for each of 
OptionParser (including OptionContainer), Values, Option 
(aka make_option) and OptionGroup. 
 

--

>Comment By: Greg Ward (gward)
Date: 2005-03-19 12:05

Message:
Logged In: YES 
user_id=14422

Finished in Optik svn r502 and r503 -- now lists all option
attributes in a separate section.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.3.

Will port to Python CVS trunk later.

--

Comment By: Greg Ward (gward)
Date: 2005-03-19 11:30

Message:
Logged In: YES 
user_id=14422

Partially addressed in Optik svn r501 (everything important
but the list of keyword args to parser.add_option() is
documented now).  More updates coming soon, I hope.

Ported to Python CVS on 2.4 branch: Doc/lib/liboptparse.tex
rev 1.18.2.2 .

Will port to Python CVS trunk later -- post release of Optik
1.5.1.


--

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

[ python-Feature Requests-1073198 ] Extension to optparse: options with optional arguments

[SourceForge.net]

Feature Requests item #1073198, was opened at 2004-11-25 09:18
Message generated for change (Settings changed) made by gward
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1073198&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: pollastri (pollastri)
Assigned to: Greg Ward (gward)
>Summary: Extension to optparse: options with optional arguments

Initial Comment:
When parsing command line options, I found very useful
to have an
option with a facultative value, able to do the following:

1-tell to me if the option was or was not seen on the
command line, return the value None if the option was
not seen;

2-if the option only was specified, return a default value.

3-if the option with a value was specified on the
command line, return the specified value;

A way to reach this goal can be the addition of a new
value for the options actions in module optparse, it
may be something like "store_with_default".





--

Comment By: Greg Ward (gward)
Date: 2005-01-05 08:19

Message:
Logged In: YES 
user_id=14422

I don't know what "facultative" means, but what you want is
optional option arguments.  Don't worry, I want that feature
too, and have even started implementing it on a branch of
the Optik source repository.  See
http://sourceforge.net/tracker/?func=detail&aid=1050431&group_id=38019&atid=421100
for a similar feature request.

I'm leaving this open, since I haven't finished anything or
merged it into the Python CVS.  It could be a few months
before there's any action here, and it certainly won't
happen before Optik 1.6 / Python 2.5.  Might require Optik
2.0, in which case I'm not certain when it'll get into Python.


--

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

[ python-Bugs-1118729 ] Error in representation of complex numbers(again)

[SourceForge.net]

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

Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Martin v. Löwis (loewis)
Summary: Error in representation of complex numbers(again)

Initial Comment:
>>> -(1+0j)
(-1+-0j)

I encountered this while I was calculating conjugate of 
complex numbers(e.g. z.conjugate()).

Related bug
* http://www.python.org/sf/1013908

One thing to note is that -(0j) can return 0j or -0j 
dependeing on OSes.

Confirmed on SuSE 9.1 & cygwin.

--

>Comment By: George Yoshida (quiver)
Date: 2005-03-20 02:11

Message:
Logged In: YES 
user_id=671362

Martin, what's your take on this?

The representation of '-(1+0j)' has changed since Revision 2.71
(complexobject.c) and you applied the patch.

# original patch
making Python LC_NUMERIC agnostic
  http://www.python.org/sf/774665

--

Comment By: George Yoshida (quiver)
Date: 2005-02-10 09:02

Message:
Logged In: YES 
user_id=671362

Hi, Björn.

Sorry, not to be clear about what my complaint is.  I'm not 
talking about if -(0j) should be 0j or -0j.  It's been that way 
for a long time, so changing it would break old codes.

My point is the signature of imaginary part. As you can see, 
it's represented as '+-'. Before the commit of patch #774665, 
it was represented as '-1-0j'. But after that, '-1+-0j'.

If you test it with Python <= 2.3, you'll get (-1-0j) and I think 
this is how -(1+0j) should be represented on machines where -
(0j) is represented as -0j.


--

Comment By: Björn Lindqvist (sonderblade)
Date: 2005-02-10 03:54

Message:
Logged In: YES 
user_id=51702

What you are seeing is negative zero (-0.0). It is distinct 
from positive zero (0.0) but 0.0 == -0.0 is always true. On 
some machines you can also see it by typing:

>>> -0.0
-0.0

On other machines you will see "0.0" instead. You can also try 
printf("%f\n", -0.0); and you will notice the same thing. So 
I'm not sure it is a bug per se. However, it can be worked 
around by adding "if (v->cval.imag == 0.) v->cval.imag = 
0.0;" to complexobject.c, assuming ofcourse it is OK to 
change negative zeros to positive ones.

--

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

[ python-Bugs-1086675 ] optparse docs missing section on Extending

[SourceForge.net]

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

Category: Documentation
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Greg Ward (gward)
Summary: optparse docs missing section on Extending

Initial Comment:
In Python 2.3 the module docs for optparse include a
fifth section,  6.20.5 Extending optparse. This section
is no longer present in the docs for Python 2.4. It is
still present in the current Optik docs
(http://optik.sourceforge.net/doc/1.5/extending.html)
so my guess is this is an inadvertent omission.

--

>Comment By: Greg Ward (gward)
Date: 2005-03-19 12:16

Message:
Logged In: YES 
user_id=14422

Fixed in Python 2.4 CVS, Doc/lib/liboptparse.tex rev 1.18.2.5.

--

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

[ python-Bugs-777867 ] test_ioctl fails

[SourceForge.net]

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

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zooko O'Whielacronx (zooko)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_ioctl fails

Initial Comment:
test_ioctl
test test_ioctl failed -- errors occurred in
test.test_ioctl.IoctlTests

...
223 tests OK.
1 test failed:
test_ioctl
31 tests skipped:
test_aepack test_al test_bsddb185 test_bsddb3
test_bz2 test_cd
test_cl test_curses test_dbm test_email_codecs
test_gdbm test_gl
test_imgfile test_linuxaudiodev test_locale test_macfs
test_macostools test_nis test_normalization
test_ossaudiodev
test_pep277 test_plistlib test_scriptpackages
test_socket_ssl
test_socketserver test_sunaudiodev test_timeout
test_unicode_file
test_urllibnet test_winreg test_winsound
4 skips unexpected on linux2:
test_dbm test_bz2 test_gdbm test_locale
make: *** [test] Error 1


My system:
 * Python from CVS: Python 2.3c1 (#1, Jul 23 2003,
08:31:24) 
 * Debian testing/unstable
 * Linux pion 2.4.21 #1 Sat Jul 19 10:21:24 EDT 2003
i686 unknown unknown GNU/Linux
 * gcc (GCC) 3.3.1 20030626 (Debian prerelease)
 * AMD Athlon XP 1600+


--

Comment By: George Yoshida (quiver)
Date: 2005-03-20 03:05

Message:
Logged In: YES 
user_id=671362

On a linux box for my work, I had similar fail(test_ioctl and 
test_ioctl_mutate).

My System:
* Python : 2.3.3, 2.4
* kernel : 2.4.22
* GCC: 2.95.3
* glibc  : 2.2

I don't know why but somehow test_ioctl.py seems to be 
invoked in the background on 'make test' process, which 
resuls in 2 fails.

Maybe the easiest way to make test_ioctl fail is :
  $ ./python ./Lib/test/regrtest.py test_ioctl &

--

Comment By: Michael Hudson (mwh)
Date: 2003-07-29 00:06

Message:
Logged In: YES 
user_id=6656

Heh, yes it certainly would be easier if I (or anyone else) could 
reproduce this.  However, this is the first I've heard of it, and I'd 
have thought/hoped that there are other people running the 
release candidates on Debian testing... glibc is very much a guess 
scapegoat, don't jeopardize your system just for me.

I suggested the '-r' thing because it's the sort of thing that can be 
done in the background.

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-29 00:00

Message:
Logged In: YES 
user_id=52562

It's always possible that I'm doing something very silly and
not reporting it.  But, as I am pressed for time, it would
be really good if you could get a failure like this running
on your own box.  Hm.  Maybe this means I should just
upgrade my glibc.

MAIN pion:~$ dpkg --status libc6 | grep ^Version
Version: 2.3.1-16

Hm.

Okay, I'll add -r to TESTOPTS and run lots of "make test".


--

Comment By: Michael Hudson (mwh)
Date: 2003-07-28 23:54

Message:
Logged In: YES 
user_id=6656

This is deeply weird.

The most likely scenario that some *other* test (or combination of 
tests, sigh) is tickling a bug in glibc that test_ioctl is revealing.

Evidence for/against this could be acquired by adding '-r' to 
TESTOPTS and running make test a few times.  But I still don't 
understand why running regrtest.py from the shell passes.  Unless 
it's a Heisenbug, or just a flat out bug in the test.

Hmm.  Ten gets you one that it's test_fork1 that buggers it up.

It seems exceedingly unlikely that this points to a real problem in 
Python's ioctl code.  ioctl() is not the easiest thing in the world to 
write tests for...

--

Comment By: Zooko O'Whielacronx (zooko)
Date: 2003-07-26 21:20

Message:
Logged In: YES 
user_id=52562

Okay, I added "-v" to TESTOPTS in Makefile.

test_ioctl
test_ioctl (test.test_ioctl.IoctlTests) ... FAIL
test_ioctl_mutate (test.test_ioctl.IoctlTests) ... FAIL

==
FAIL: test_ioctl (test.test_ioctl.IoctlTests)
--
Traceback (most recent call last):
  File
"/home/zooko/playground/python/python/dist/src/Lib/test/test_ioctl.py",
line 22, in test_ioctl
self.assertEquals(pgrp, struct.unpack("i", r)[0])
  File
"/home/zooko/playground/python/python/dist/src/Lib/unittest.py",
line 292, in failUnlessEqual
raise self.failureException, AssertionError: 32261 != 28460

==
FAIL: test_ioctl_mutate (test.test_ioctl.IoctlTests)
--
Traceback (most recen

[ python-Bugs-1166582 ] IterableUserDict not in docs

[SourceForge.net]

Bugs item #1166582, was opened at 2005-03-19 18:13
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=1166582&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Kent Johnson (kjohnson)
Assigned to: Nobody/Anonymous (nobody)
Summary: IterableUserDict not in docs

Initial Comment:
There is no mention of UserDict.IterableUserDict in the
docs (3.7 UserDict). Here is a suggested rewrite:

class UserDict( [initialdata])
Class that simulates a dictionary. The instance's
contents are kept in a regular dictionary, which is
accessible via the data attribute of UserDict
instances. If initialdata is provided, data is
initialized with its contents; note that a reference to
initialdata will not be kept, allowing it be used for
other purposes. Note: For backward compatibility,
instances of UserDict are not iterable.

class IterableUserDict( [initialdata])
Subclass of UserDict that supports direct iteration
(e.g. "for key in myDict").

In addition to supporting the methods and operations of
mappings (see section 2.3.8), UserDict and
IterableUserDict instances provide the following attribute:

--

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

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

[SourceForge.net]

Bugs item #110, was opened at 2005-03-19 23:48
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=110&group_id=5470

Category: Threads
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Yariv Ido (dcoder)
Assigned to: Nobody/Anonymous (nobody)
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.

--

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

[ python-Bugs-1166704 ] [ast branch] fatal error when compiling test_bool.py

[SourceForge.net]

Bugs item #1166704, was opened at 2005-03-19 23:34
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=1166704&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



--

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

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

[SourceForge.net]

Bugs item #110, was opened at 2005-03-19 23:48
Message generated for change (Comment added) made by dcoder
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: Nobody/Anonymous (nobody)
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: Yariv Ido (dcoder)
Date: 2005-03-20 01: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

[ python-Bugs-1166714 ] [ast branch] fatal error when compiling test_bool.py

[SourceForge.net]

Bugs item #1166714, was opened at 2005-03-20 00:14
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=1166714&group_id=5470

Category: Parser/Compiler
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: [ast branch] fatal error when compiling test_bool.py

Initial Comment:
When using the ast-branch compiler, python exits with a
fatal error when compiling test_bool.py or the
symplified test case that I'll attach.

The immediate problem is that when the compiler is in
make_closure after compiling the lambda, self is found
to be a LOCAL reference type and make_closure assumes
it's a FREE reference if it's not a CELL reference in
the enclosing scope.

I don't know if self is supposed to be a LOCAL
reference or if make_closure should handle LOCAL
references.



--

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

[ python-Bugs-1164631 ] super(...).__new__( ... ) behaves "unexpected"

[SourceForge.net]

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

Category: Type/class unification
Group: Python 2.4
Status: Deleted
Resolution: None
Priority: 5
Submitted By: Dirk Brenckmann (brenck)
Assigned to: Nobody/Anonymous (nobody)
Summary: super(...).__new__( ... ) behaves "unexpected"

Initial Comment:
Hello there,




python code and trace output enclosed.




What I did:


1. Metaclass inheritence:


   type <-- MA <-- MB <-- MC




2. Created Class A using __metaclass__= MC




3. Create Class B(A) using __metaclass__= MB




...although this might seem strange, it should work...




When taking a look at the trace, you will notice one line 
that goes like:


'---> why does super( MA, metacls ).__new__ call MC.
__new__ in next line '




if you run the code, you will find it three times. That's ok. 
In my trace I just replaced two occurences of that line by 
">>" to enable focussing on the Problem...




What I would expect the code to do is the following:


1. Create a Class A which is of type MC


2. Create a Class B(A) which is of type MB




What the interpreter does is different:


1.   Create a Class A which is type MC


2.1 Nearly create a Class B which is of type MB.


2.2 In type.__new__( ... ) change it's mind.


2.3 Due to the superclass A of B, create some 
class A which is of type MC as well. Although  B 
contains a __metaclass__ = MB statement.




Well - that's what I experienced is "the way windows 
works", so I ran the code on Solaris again but the 
behaviour remains reproduceable...




I would consider it a bug therefor. If it's not a bug, I would 
expect an Exception which tells me where I did wrong...




Thanx for your time and efforts


   




--

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-19 20:25

Message:
Logged In: YES 
user_id=764593

Note that the documentation is known to be very weak 
regarding both metaclasses and the differences between 
classic and new-style classes.

If you (or Nick) wanted to submit a documentation patch, I 
doubt I'm the only one who would appreciate it.

--

Comment By: Dirk Brenckmann (brenck)
Date: 2005-03-19 05:32

Message:
Logged In: YES 
user_id=360037

Okay, that's the point.
Thanx for your time and work - bug becomes deleted.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 20:30

Message:
Logged In: YES 
user_id=1038590

Additional text from the descrintro essay, indicating that
it is deliberate that C3 does not trigger an exception:

"""However, if one of the base metaclasses satisfies the
constraint (including the explicitly given __metaclass__, if
any), the first base metaclass found satisfying the
constraint will be used as the metaclass."""

So, unless Guido chooses to change the desired behaviour,
these two snippets pretty much cover what needs to be added
to the docs.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 19:17

Message:
Logged In: YES 
user_id=1038590

To address the documentation side, the following text from
Guido's descrintro essay could be added to the official
documentation:

"""For new-style metaclasses, there is a constraint that the
chosen metaclass is equal to, or a subclass of, each of the
metaclasses of the bases. Consider a class C with two base
classes, B1 and B2. Let's say M = C.__class__, M1 =
B1.__class__, M2 = B2.__class__. Then we require
issubclass(M, M1) and issubclass(M, M2). (This is because a
method of B1 should be able to call a meta-method defined in
M1 on self.__class__, even when self is an instance of a
subclass of B1.)""" 

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-03-18 19:14

Message:
Logged In: YES 
user_id=1038590

Minimal case that should throw an exception on C3, but
doesn't (instead, it silently replaces the explicitly
requested metaclass M1 with its subclass M2):

class M1(type):
  pass

class M2(M1):
  pass

class C1(object):
  __metaclass__ = M1

class C2(C1):
  __metaclass__ = M2

class C3(C2):
  __metaclass__ = M1


--

Comment By: Jim Jewett (jimjjewett)
Date: 2005-03-18 14:14

Message:
Logged In: YES 
user_id=764593

Yes, it is intentional.  

class Derived(Base): ...

should mean that you can use an instance of Derived 
anywhere you need an instance of Base.

There are ways to break this, but it isn't a good idea.

Letting Derived ignore part of the metaclass (and creation 
instructions) of Base would make it much easier to create an 
invalid Derived b

[ python-Bugs-1160383 ] digit-only tag values are mishandled in Tkinter

[SourceForge.net]

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

Category: Tkinter
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Martin v. Löwis (loewis)
Summary: digit-only tag values are mishandled in Tkinter

Initial Comment:
It  appears that  most Tkinter tag operations fail on
digit-only tag values

>>> from Tkinter import *
>>> root=Tk()
>>> c=Canvas(root)
>>> c.create_line(0,0,100,100, tags="123")
1
>>> c.gettags(1)
('123',)
>>> c.pack()   
>>> c.find_withtag("123")
()

tkinter docs:
http://www.pythonware.com/library/tkinter/introduction/x2017-concepts.htm

only say this about tag values:
  "Tags are ordinary strings, and they can contain
anything except whitespace."

So this behaviour seems like a bug.

--

>Comment By: Ilya Sandler (isandler)
Date: 2005-03-19 22:33

Message:
Logged In: YES 
user_id=971153

>".. Item handles can be passed to the various canvas methods 
> either as integers or as strings..." (from effbot posting)

While I can see how a very careful reader might notice that
there is a potential conflict between this "handles as
strings" statement and "tags can contain anything", I still
think that at the very least this conflict needs to be
mentioned explicitly.

> Furthermore, the site www.pythonware.com is a third-party
> site not run by the Python developers (from  jepler posting)

Actually for whatever reason I thought that pythonware.com
is the authorative source for tkinter docs

I guess it does bring an interesting question for Fredrik...
Would you consider merging your Tkinter docs (which seem to
be reasonably complete) with python.org docs which seem to
be very spotty?



--

Comment By: Fredrik Lundh (effbot)
Date: 2005-03-19 08:53

Message:
Logged In: YES 
user_id=38376

Here's the text before the quoted line:

"Everywhere a method expects an item specifier, you can 
use one of the following: * item handles * tags /.../ Item 
handles are integer values that are used to identify a specific 
item on the canvas /.../ Item handles can be passed to the 
various canvas methods either as integers or as strings. /.../"

Note the use of "one of", and the fact that item handles are 
described before tags. (Writing documentation for people who 
only reads random sentences is pretty much impossible...)

--

Comment By: Jeff Epler (jepler)
Date: 2005-03-19 06:20

Message:
Logged In: YES 
user_id=2772

This is a documentation bug.  The Tk documentation says
(canvas, section "ITEM IDS AND TAGS"):
   Each  item may also have any number of tags
associated with it.  A tag
   is just a string of characters, and it may take any
form  except  that
   of  an  integer.   For example, ‘‘x123’’ is OK but
‘‘123’’ isn’t.  The
   same tag may be associated with many different items.

Furthermore, the site www.pythonware.com is a third-party
site not run by the Python developers.  The official Python
documentation
(http://docs.python.org/lib/module-Tkinter.html and 'pydoc
Tkinter') doesn't explain the syntax of an item tag anywhere
that I could see)

I recommend closing this bug and notifying pythonware.com /
Fredrik Lundh about the problem via e-mail.

--

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