Re: [Python-Dev] Attribute error: providing type name
Martin v. Löwis wrote: Alex Martelli wrote: I think the standard exception hierarchy should grow additional standard fields. E.g. AttributeError should have attributes 'type','name', or perhaps even 'object','name'. TypeError should have attributes 'expected', 'actual' (or, again, 'expected', 'object'). And so on - that might produce quite a large PEP. I don't think there's any reason to do it in one big bang. And approached individually, each such alternate constructor is a small RFE consisting of: 1. Specific C API for creating exceptions of that type with a standard message and attributes 2. Python level class method 3. New attributes on the affected object Point 3 would be optional really, since most of the gain comes from the better error messages. If extra attributes were included in such an RFE, the potential lifecycle implications of including references to actual objects rather than merely their types makes the better choice fairly obvious to me (i.e. just include the type information, since it generally tells you everything you need to know for TypeErrors and AttributeErrors). As 3.0 missed the chance to fix this, compatibility is also an issue. It might be possible to overload exception constructors on the number of parameters, or using keyword parameters for the new way of filling the exception. Or go the traditional multiple constructor route and provide class methods for the alternative mechanisms. And no, I don't volunteer to write this PEP :-) Assuming I understand what you mean by nested exceptions correctly, they should be covered by the __context__ and __cause__ attributes in Py3k: Exception context: === try: ... raise IOError ... except: ... raise AttributeError ... Traceback (most recent call last): File stdin, line 2, in module IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 4, in module AttributeError === Exception cause: === raise AttributeError from KeyError KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File stdin, line 1, in module AttributeError === Putting it all together: === try: ... raise IOError ... except: ... try: ... raise KeyError ... except Exception as ex: ... raise AttributeError from ex ... Traceback (most recent call last): File stdin, line 2, in module IOError During handling of the above exception, another exception occurred: Traceback (most recent call last): File stdin, line 5, in module KeyError The above exception was the direct cause of the following exception: Traceback (most recent call last): File stdin, line 7, in module AttributeError === Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Nick Coghlan wrote: Martin v. Löwis wrote: Alex Martelli wrote: I think the standard exception hierarchy should grow additional standard fields. E.g. AttributeError should have attributes 'type','name', or perhaps even 'object','name'. TypeError should have attributes 'expected', 'actual' (or, again, 'expected', 'object'). And so on - that might produce quite a large PEP. I don't think there's any reason to do it in one big bang. And approached individually, each such alternate constructor is a small RFE consisting of: 1. Specific C API for creating exceptions of that type with a standard message and attributes 2. Python level class method 3. New attributes on the affected object Point 3 would be optional really, since most of the gain comes from the better error messages. If extra attributes were included in such an RFE, the potential lifecycle implications of including references to actual objects rather than merely their types makes the better choice fairly obvious to me (i.e. just include the type information, since it generally tells you everything you need to know for TypeErrors and AttributeErrors). As 3.0 missed the chance to fix this, compatibility is also an issue. It might be possible to overload exception constructors on the number of parameters, or using keyword parameters for the new way of filling the exception. Or go the traditional multiple constructor route and provide class methods for the alternative mechanisms. Bear in mind, though, that as new functionality none of this can go in before 3.1/2.7. So a PEP might not be a bad idea if only to establish best practices. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... Alex On Mon, Dec 1, 2008 at 1:30 AM, Filip Gruszczyński [EMAIL PROTECTED] wrote: Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. He does. It is supposed to appear in 4.8. So I guess that's it, thanks a lot for your help. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Alex Martelli wrote:
I wonder if there's some desiderata left for future Python versions to
make this standard behavior easier (for C-coded, Python-coded, and
Cython-coded classes, ones made by SWIG, etc) without too much black
magic...
Perhaps adding something like the following to the C API:
void PyErr_FormatAttributeError(PyObject* type, char *attr)
{
PyErr_Format(PyExc_AttributeError,
object of type %.100s has no attribute '%.200s',
type-tp_name, attr);
}
This could also be exposed as a class method of AttributeError itself
for use in Python code.
(Interestingly, I noticed that there are still quite a few attribute
errors at least in typeobject.c that don't provide any information on
the type of the object that is missing an attribute - they appeared to
mostly be obscure errors that will only turn up if something has gone
very strange, but they're there)
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Alex Martelli wrote: I wonder if there's some desiderata left for future Python versions to make this standard behavior easier (for C-coded, Python-coded, and Cython-coded classes, ones made by SWIG, etc) without too much black magic... I think the standard exception hierarchy should grow additional standard fields. E.g. AttributeError should have attributes 'type','name', or perhaps even 'object','name'. TypeError should have attributes 'expected', 'actual' (or, again, 'expected', 'object'). Also, some languages support nested exceptions (attribute 'inner'); usefulness of this concept should be reviewed. And so on - that might produce quite a large PEP. As 3.0 missed the chance to fix this, compatibility is also an issue. It might be possible to overload exception constructors on the number of parameters, or using keyword parameters for the new way of filling the exception. And no, I don't volunteer to write this PEP :-) Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
On Sun, Nov 30, 2008 at 11:41 AM, Filip Gruszczyński [EMAIL PROTECTED] wrote: This is my first message in this list, therefore I would like to say hello to everyone. I also hope, that I am not breaking any rules or guidelines for sending proposals. I would like to ask, if it is possible to provide type name of the object invoking the exception, when Attribute error is catched. It is done for functions, like: AttributeError: 'function' object has no attribute 'getValue' but for some objects there is only: AttributeError: connectToBases This is cool, when you know exactly what type of object cast the exception. But if there might be many of them, you must do one of two things: add print statement just before the line with the exception and check the type or iterate over all classes that might appear them. Showing the class name would solve this problem and could save a lot of time. I'm sure you'll get support for this, unless it's a really inconvenient spot that requires a gross hack to print the type name. Post a patch on the bug tracker. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Well, if this is not an inconvenient spot that requires a gross hack to print the type name I'd love to get some instructions or direction, and try to change it myself. Unfortunately it's the first time I looked into Python source and it's pretty big - I tried browsing exceptions.c and errors.c, but couldn't find any simple place, where I could place the required type information. I can of course post it on the bug tracker, but I believe I could learn something on this ;-) And I don't like missing a chance to get a glance at something new. I'm sure you'll get support for this, unless it's a really inconvenient spot that requires a gross hack to print the type name. Post a patch on the bug tracker. -- Adam Olsen, aka Rhamphoryncus -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Adam Olsen wrote: I'm sure you'll get support for this, unless it's a really inconvenient spot that requires a gross hack to print the type name. Post a patch on the bug tracker. So far I can see only one argument against the proposed idea: doc tests. The modified exception message would break existing doc tests. Christian ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I would say this is due to Py_FindMethod being used. It is a nice and easy function to use, but it fails to set a good error message so maybe you are experiencing these error messages from modules that are using it. Yep, found it and it does call PyErr_SetString with proper values. I'll try to change this, without breaking anything. Thanks for help :) -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Christian Heimes wrote: Adam Olsen wrote: I'm sure you'll get support for this, unless it's a really inconvenient spot that requires a gross hack to print the type name. Post a patch on the bug tracker. So far I can see only one argument against the proposed idea: doc tests. The modified exception message would break existing doc tests. It wouldn't be the first time we've broken doc tests that way. Since the details of the error messages aren't guaranteed to remain the same across releases, doctests that aren't part of Python's own test suite really should be using IGNORE_EXCEPTION_DETAIL when checking for exceptions that are raised directly by the interpreter or standard library. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
I have done some testing and it seems, that it might not be Python problem. Well, when I use only pure Python objects, I get really nice description of the object (which means the type). But I am using PyQt and it seems, that when an object is subclassing QObject (or possibly some other class from qt, that can be not derived from QObject) it can only display information about the name of the function. PyQt are python bindings for C++ qt library. Can this be the reason for not displaying type of the object? 2008/11/30 Nick Coghlan [EMAIL PROTECTED]: Christian Heimes wrote: Adam Olsen wrote: I'm sure you'll get support for this, unless it's a really inconvenient spot that requires a gross hack to print the type name. Post a patch on the bug tracker. So far I can see only one argument against the proposed idea: doc tests. The modified exception message would break existing doc tests. It wouldn't be the first time we've broken doc tests that way. Since the details of the error messages aren't guaranteed to remain the same across releases, doctests that aren't part of Python's own test suite really should be using IGNORE_EXCEPTION_DETAIL when checking for exceptions that are raised directly by the interpreter or standard library. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/gruszczy%40gmail.com -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Filip Gruszczyński wrote: I have done some testing and it seems, that it might not be Python problem. Well, when I use only pure Python objects, I get really nice description of the object (which means the type). But I am using PyQt and it seems, that when an object is subclassing QObject (or possibly some other class from qt, that can be not derived from QObject) it can only display information about the name of the function. PyQt are python bindings for C++ qt library. Can this be the reason for not displaying type of the object? Yeah, any time someone implements their own attribute lookup process for a class (be it via __getattr__, __getattribute__ or the C equivalents), it is up to the reimplementation to appropriately format their error message if they raise AttributeError directly. This could possibly be made easier to do correctly via a specific AttributeError class method (also exposed through the C API) that accepted a type object and an attribute name and then produced a nicely formatted error message the way the builtin types do. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
Yeah, any time someone implements their own attribute lookup process for a class (be it via __getattr__, __getattribute__ or the C equivalents), it is up to the reimplementation to appropriately format their error message if they raise AttributeError directly. I guess, this means that I have to go to Phil Thompson at Riverbank and try to convince him to change the message. -- Filip Gruszczyński ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Attribute error: providing type name
On Sun, Nov 30, 2008 at 2:02 PM, Filip Gruszczyński [EMAIL PROTECTED] wrote: Yeah, any time someone implements their own attribute lookup process for a class (be it via __getattr__, __getattribute__ or the C equivalents), it is up to the reimplementation to appropriately format their error message if they raise AttributeError directly. I guess, this means that I have to go to Phil Thompson at Riverbank and try to convince him to change the message. Yes, but he should be able to change it in one place (in sip, the C++ to Python wrapper generator he's also authored and uses for PyQt) AND it would make sip even better, so he may want to put it on his backlog. Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
