On Nov 22, 2009, at 3:33 AM, detlev wrote:
On Samstag, 21. November 2009, Seth Hill wrote:
Hello all,
I'm new to the mailing list and Eric, so please bear with me.
I have discovered a possible bug in the DebugClientBase.py which
comes with Eric4 4.3.9 (r3513) on Windows XP. I've put a workaround
in place for the issue (see below). My question is not so much about
the bug (if it is a bug), but rather, where's the appropriate place
to submit bug reports?
The ideal way to report bugs is via the included reporting function
(s. Help
menu). However, it is fine to report them here as well.
I noticed that menu command fully 60 seconds after sending the email!
There is __a_lot__ of functionality to learn in Eric!
If the right place is here, then continue
reading (and my apologies if not!).
I'm working with a django 1.1 project, trying to get debugging going.
I'm working with a form in a view function. I set a breakpoint in the
view function, and get a TypeError in DebugClientBase.py:1608. It
looks like the debugger is going through the locals and calling
unicode() on all of them. Some of the locals in this case don't
support the unicode method. When the debugger calls the unicode()
method, it triggers an exception inside the running wsgi server. I
get an error message on the web page, and the debug session stops
working.
My code looks like:
forms.py:
class NewCustomerForm(forms.Form):
name = forms.CharField()
# etc
views.py:
def create_customer(request):
if request.method == "POST": # breakpoint here
form = NewCustomerForm(request.POST)
if form.is_valid(): # exception occurs when stepping
to here
The line in DebugClientBase.py looks like:
valtypestr = unicode(type(value))[1:-1]
I don't understand, why type(value) does not support the unicode()
method.
Now that you mention it, I don't either. I've been digging a little
deeper, and it seems that this is django's problem:
A django.forms.forms.Form class defines __metaclass__ =
DeclarativeFieldsMetaclass (see source code http://
code.djangoproject.com/browser/django/trunk/django/forms/forms.py:
336). I'm not entirely sure what it does, but I gather that it
converts the class attributes into fields which can be accessed by a
class instance.
Anyway, the metaclass seems to be promoting the __unicode__ function
of Form to type(Form):
>>> f = Form()
>>> type(f)
<class 'django.forms.forms.Form'>
>>> unicode(type(f))
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: unbound method __unicode__() must be called with Form
instance as first argument (got nothing instead)
>>> type(Form)
<class 'django.forms.forms.DeclarativeFieldsMetaclass'>
>>> import inspect
>>> inspect.getsource(type(f).__unicode__)
' def __unicode__(self):\n return self.as_table()\n'
Anyway, the effect is still that if you are running the debugger and
have a Form instance as a local variable, it will blow up. I would be
willing to be that debugging a Model instance would have a similar
effect (since it also uses a metaclass).
Maybe, instead of below a workaround should be:
if type(value) is type:
valtypestr = unicode(type(value))[1:-1]
else:
valtypestr = repr(type(value))[1:-1]
However, even when doing that I suppose some metaclass could screw up
__repr__ just like django's DeclarativeFieldsMetaclass did with
__unicode__. (?)
I've "fixed" the error by wrapping the line in a try:
try:
valtypestr = unicode(type(value))[1:-1]
except TypeError:
valtypestr = repr(type(value))[1:-1]
You can duplicate the TypeError with something like:
class Foo:
... def __unicode__(self):
... return u'Foo instance'
...
unicode(Foo)
Traceback (most recent call last):
File "<console>", line 1, in <module>
TypeError: unbound method __unicode__() must be called with Foo
instance as first argument (got nothing instead)
However, unicode(type(Foo)) works fine, and that is what the
"faulty" line
does. Could you please give another example or stripped down script
that
causes your problem.
Regards,
Seth Hill
_______________________________________________
Eric mailing list
Eric@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/eric
Regards,
Detlev
--
Detlev Offenbach
det...@die-offenbachs.de
_______________________________________________
Eric mailing list
Eric@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/eric
