Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sat, Apr 16, 2005 at 07:24:27PM -0400, Barry Warsaw wrote: > On Thu, 2005-04-14 at 23:46, Barry Warsaw wrote: > > I've noticed an apparent inconsistency in the exception thrown for > > read-only properties for C extension types vs. Python new-style > > classes. > > I haven't seen any follow ups on this, so I've gone ahead and posted a > patch, assigning it to Raymond: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1184449&group_id=5470&atid=105470 > In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits from both TypeError and AttributeError? If anyone currently does catch the error raising only AttributeError will break their code. 2.5 should just raise an AttributeError, of course. If that's acceptable I'll gladly submit a similar patch for mmap.get_byte() PyErr_SetString (PyExc_ValueError, "read byte out of range"); has always irked me (the same thing with mmap[i] is an IndexError). I hadn't thought of a clean way to fix it, but MI on the error might work. -jackdied ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, 2005-04-17 at 11:53, Jack Diederich wrote: > In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits > from both TypeError and AttributeError? If anyone currently does catch the > error raising only AttributeError will break their code. 2.5 should just > raise an AttributeError, of course. Without introducing a new exception class (which I think is out of the question for anything but 2.5), the only common base is StandardError, which seems too general for this exception. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, Apr 17, 2005 at 11:53:31AM -0400, Jack Diederich wrote:
> On Sat, Apr 16, 2005 at 07:24:27PM -0400, Barry Warsaw wrote:
> > On Thu, 2005-04-14 at 23:46, Barry Warsaw wrote:
> > > I've noticed an apparent inconsistency in the exception thrown for
> > > read-only properties for C extension types vs. Python new-style
> > > classes.
> >
> > I haven't seen any follow ups on this, so I've gone ahead and posted a
> > patch, assigning it to Raymond:
> >
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1184449&group_id=5470&atid=105470
> >
> In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits
> from both TypeError and AttributeError? If anyone currently does catch the
> error raising only AttributeError will break their code. 2.5 should just
> raise an AttributeError, of course.
>
> If that's acceptable I'll gladly submit a similar patch for mmap.get_byte()
> PyErr_SetString (PyExc_ValueError, "read byte out of range");
> has always irked me (the same thing with mmap[i] is an IndexError).
> I hadn't thought of a clean way to fix it, but MI on the error might work.
>
I just did a quick grep for raised ValueErrors with "range" in the
explanation string and didn't find any general consensus. I dunno what
that means, if anything.
wopr:~/src/python_head/dist/src# find ./ -name '*.c' | xargs grep ValueError |
grep range | wc -l
13
wopr:~/src/python_head/dist/src# find ./ -name '*.c' | xargs grep IndexError |
grep range | wc -l
31
(long versions below)
-jackdied
wopr:~/src/python_head/dist/src# find ./ -name '*.c' | xargs grep -n IndexError
| grep range
./Modules/arraymodule.c:599:PyErr_SetString(PyExc_IndexError,
"array index out of range");
./Modules/arraymodule.c:997:PyErr_SetString(PyExc_IndexError, "pop
index out of range");
./Modules/mmapmodule.c:639: PyErr_SetString(PyExc_IndexError, "mmap
index out of range");
./Modules/mmapmodule.c:727: PyErr_SetString(PyExc_IndexError, "mmap
index out of range");
./Modules/_heapqmodule.c:19:PyErr_SetString(PyExc_IndexError,
"index out of range");
./Modules/_heapqmodule.c:58:PyErr_SetString(PyExc_IndexError,
"index out of range");
./Modules/_heapqmodule.c:136: PyErr_SetString(PyExc_IndexError,
"index out of range");
./Modules/_heapqmodule.c:173: PyErr_SetString(PyExc_IndexError,
"index out of range");
./Modules/_heapqmodule.c:310: PyErr_SetString(PyExc_IndexError,
"index out of range");
./Modules/_heapqmodule.c:349: PyErr_SetString(PyExc_IndexError,
"index out of range");
./Objects/bufferobject.c:403: PyErr_SetString(PyExc_IndexError,
"buffer index out of range");
./Objects/listobject.c:876: PyErr_SetString(PyExc_IndexError, "pop
index out of range");
./Objects/rangeobject.c:94: PyErr_SetString(PyExc_IndexError,
./Objects/stringobject.c:1055: PyErr_SetString(PyExc_IndexError,
"string index out of range");
./Objects/structseq.c:62: PyErr_SetString(PyExc_IndexError,
"tuple index out of range");
./Objects/tupleobject.c:104:PyErr_SetString(PyExc_IndexError,
"tuple index out of range");
./Objects/tupleobject.c:310:PyErr_SetString(PyExc_IndexError,
"tuple index out of range");
./Objects/unicodeobject.c:5164:PyErr_SetString(PyExc_IndexError,
"string index out of range");
./Python/exceptions.c:1504:PyDoc_STRVAR(IndexError__doc__, "Sequence index out
of range.");
./RISCOS/Modules/drawfmodule.c:534: { PyErr_SetString(PyExc_IndexError,"drawf
index out of range");
./RISCOS/Modules/drawfmodule.c:555: { PyErr_SetString(PyExc_IndexError,"drawf
index out of range");
./RISCOS/Modules/drawfmodule.c:578: { PyErr_SetString(PyExc_IndexError,"drawf
index out of range");
./RISCOS/Modules/swimodule.c:113: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:124: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:136: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:150: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:164: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:225: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:237: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:248: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
./RISCOS/Modules/swimodule.c:264: { PyErr_SetString(PyExc_IndexError,"block
index out of range");
wopr:~/src/python_head/dist/src# find ./ -name '*.c' | xargs grep -n ValueError
| grep range
./Modules/mmapmodule.c:181: PyErr_SetString (PyExc_ValueError,
"read byte out of range");
./Modules/mmapmodule.c:301: PyErr_SetString (PyExc_ValueErro
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, Apr 17, 2005, Barry Warsaw wrote: > On Sun, 2005-04-17 at 11:53, Jack Diederich wrote: >> >> In 2.4 & 2.3 does it make sense to raise an exception that multiply >> inherits from both TypeError and AttributeError? If anyone currently >> does catch the error raising only AttributeError will break their >> code. 2.5 should just raise an AttributeError, of course. > > Without introducing a new exception class (which I think is out of the > question for anything but 2.5), the only common base is StandardError, > which seems too general for this exception. Why is changing an exception more acceptable than creating a new one? (I don't have a strong opinion either way, but I'd like some reasoning; Jack's approach at least doesn't break code.) Especially if the new exception isn't "public" (in the builtins with other exceptions). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
> In 2.4 & 2.3 does it make sense to raise an exception that multiply inherits > from both TypeError and AttributeError? If anyone currently does catch the > error raising only AttributeError will break their code. 2.5 should just > raise an AttributeError, of course. I think that sets a bad precedent. I understand you want to do this for backwards compatibility, but it's a real ugly thing in the exception inheritance tree and once it's in it's hard to get rid of. It's also introducing a new feature so it's a no-no to do this for 2.3 or 2.4 anyway. I wonder if long-term, AttributeError shouldn't inherit from TypeError? AttributeError really feels to me like a particular case of the stuff that typically raises TypeError. Unfortunately this is *also* a b/w compatibility problem, since people currently might have code like this: try: ... except TypeError: ... except AttributeError: ... and the AttributeError branch would become unreachable. Personally, I think it would be fine to just change the TypeError to AttributeError. I expect that very few people would be hurt by that change (they'd be building *way* too much specific arcane knowledge into their program if they had code for which it mattered). So why, given two different backwards incompatible choices, do I prefer changing the exception raised in this specific case over making AttributeError inherit from TypeError? Because the latter change has a much larger scope; it can affect much more code (including code that doesn't have anything to do with the problem we're trying to solve). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, 2005-04-17 at 12:25, Aahz wrote: > Why is changing an exception more acceptable than creating a new one? > (I don't have a strong opinion either way, but I'd like some reasoning; > Jack's approach at least doesn't break code.) Especially if the new > exception isn't "public" (in the builtins with other exceptions). Adding an exception that we have to live with forever (even if it's localized to this one module) seems like it would fall under the new feature rubric, whereas I think the choice of exception was just a bug. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, 2005-04-17 at 14:36, Guido van Rossum wrote: > Personally, I think it would be fine to just change the TypeError to > AttributeError. I expect that very few people would be hurt by that > change (they'd be building *way* too much specific arcane knowledge > into their program if they had code for which it mattered). Unless there are any objections in the next few days, I will take this as a pronouncement and make the change at least in 2.5 and 2.4. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
> > Personally, I think it would be fine to just change the TypeError to > > AttributeError. I expect that very few people would be hurt by that > > change (they'd be building *way* too much specific arcane knowledge > > into their program if they had code for which it mattered). > > Unless there are any objections in the next few days, I will take this > as a pronouncement and make the change at least in 2.5 and 2.4. You meant 2.5 only of course. It's still a new feature and as such can't be changed in 2.4. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
Barry Warsaw <[EMAIL PROTECTED]> writes: > On Sun, 2005-04-17 at 14:36, Guido van Rossum wrote: > >> Personally, I think it would be fine to just change the TypeError to >> AttributeError. I expect that very few people would be hurt by that >> change (they'd be building *way* too much specific arcane knowledge >> into their program if they had code for which it mattered). > > Unless there are any objections in the next few days, I will take this > as a pronouncement and make the change at least in 2.5 and 2.4. I don't think this should be changed in 2.4. Cheers, mwh -- As far as I'm concerned, the meat pie is the ultimate unit of currency. -- from Twisted.Quotes ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Sun, 2005-04-17 at 15:44, Guido van Rossum wrote: > You meant 2.5 only of course. It's still a new feature and as such > can't be changed in 2.4. Fair enough. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Inconsistent exception for read-only properties?
On Monday 18 April 2005 05:17, Barry Warsaw wrote: > Unless there are any objections in the next few days, I will take this > as a pronouncement and make the change at least in 2.5 and 2.4. God no - this isn't suitable for a bugfix release. It seems fine for 2.5, though. -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
