Movatterモバイル変換
[0]ホーム
[Python-Dev] Proposed resolutions for open PEP 343 issues
Guido van Rossumguido at python.org
Tue Oct 25 18:14:29 CEST 2005
On 10/25/05, Nick Coghlan <ncoghlan at gmail.com> wrote:> Almost there - this is the only issue I have left on my list :)[,,,]> > Why are you so keen on TypeError? I find AttributeError totally> > appropriate. I don't see symmetry with for-loops as a valuable> > property here. AttributeError and TypeError are often interchangeable> > anyway.>> The reason I'm keen on TypeError is because 'abstract.c' uses it consistently> when it fails to find a method to support a requested protocol.Hm. abstract.c well predates the new type system. Slots and methodsweren't really unified back then, so TypeError made obvious sense atthe time.But with the new unified types/classes, those TypeErrors are reallyjust delayed (or precomputed? depends on your POV) AttributeErrors.> None of the abstract object methods currently raise AttributeError, and this> property is fairly visible at the Python level because the abstract API's are> used to implement many of the bytecodes and various builtin functions. Both> for loops and the iter function, for example, get their current exception> behaviour from PyObject_GetIter and PyIter_Next.>> Having had a look at mwh's patch, however, I've realised that going that way> would only be possible if there were dedicated bytecodes for GET_CONTEXT,> ENTER_CONTEXT and EXIT_CONTEXT (similar to the dedicated GET_ITER and FOR_ITER).>> Leaving the exception as AttributeError means that level of bytecode hacking> isn't necessary (mwh's patch just emits a fairly normal try/finally statement,> although it still modifies the bytecode to include LOAD_EXIT_ARGS).Let's definitely not introduce new bytecodes just so we can raise adifferent exception.> So, the inconsistency with other syntactic protocols still bothers me, but I> can live with AttributeError if you don't want to add three new bytecodes just> to support PEP 343.I think the consistency you are seeking is a mirage. The TypeErrorsstem from the pre-computation of the slot population, not from somerequirements to raise TypeError for failing to implement some requiredbuilt-in protocol. I wouldn't hold it against other implementations ofPython if they raised AttributeError in more situations.It is true though that AttributeError is somewhat special. There arelots of places (perhaps too many?) where an operation is defined usingsomething like "if the object has attribute __foo__, use it, otherwiseuse some other approach". Some operations explicitly check forAttributeError in their attribute check, and let a different exceptionbubble up the stack. Presumably this is done so that a bug insomebody's __getattr__ implementation doesn't get masked by the"otherwise use some other approach" branch. But this is relativelyrare; most calls to PyObject_GetAttr just clear the error if they havea different approach available. In any case, I don't see any of thisas supporting the position that TypeError is somehow more appropriate.An AttributeError complaining about a missing __enter__, __exit__ or__context__ method sounds just fine. (Oh, and please don't go checkingfor the existence of __exit__ before calling __enter__. That kind ofbug is found with even the most cursory testing.)----Guido van Rossum (home page:http://www.python.org/~guido/)
More information about the Python-Devmailing list
[8]ページ先頭