Small suggestion regarding type errors and subscription

Ideas
1

If this provides you an error message on the specific key that’s missing

class User:
  profile = None 

u = User()
u.profile.name # AttributeError: None does not have attribute name

Then may I suggest that this has the same ?

user = {
“profile”: None
}
user[“profile”][“name”] # TypeError: None is not subscripable

Currently doesn’t indicate which key triggered this which isn’t helpful in software that will send the high level exception message to you.

There has been recent discussion in the null operator thread that statements like this should always make clear which part failed

But python even today doesn’t always do this

2

Do you mean like this?

$ python -c 'print({"profile":None}["profile"]["name"])'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    print({"profile":None}["profile"]["name"])
          ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
TypeError: 'NoneType' object is not subscriptable

This is what python 3.13 does. Maybe 3.12 as well? edit: confirmed it’s new in 3.13

1 Like
3

Nice so it will give an error like this now ? If so, nice!

TypeError: Key “name” cannot be used with “NoneType” because it’s not subscripts or
4

No, it will give the error message @jamestwebber showed. Try it out in a python shell! That is the easiest way to figure out exactly how a feature behaves.

3 Likes
5
6

This should be available since 3.11 What’s New In Python 3.11 — Python 3.13.0 documentation
But it seems the old REPL didn’t show them properly.
So I think what’s new in 3.13 is the new REPL, which shows the tracebacks properly.

3 Likes
7

That makes much more sense. I was sure I had seen it before 3.13, but it must have been in a notebook or somewhere else where it displayed properly. I don’t use the base REPL very often.

8

If that line of code is broken up across two lines, the error will be more specific, and the bug simple to fix.

Python one liners are superficially great, but only when they work. Debugging them and trying to understand them, not so much.

9

Of course but there is always a big gap between the code you should write

And the code you’ve been given to debug :grinning:

10

I think that the should issues involving None be made more self explanatory question is unanswerable until you figure out how you’d do it. In this case, how is NoneType.__getattr__() or NoneType.__getitem__() supposed to know what the None placeholder-ing for or what assumption failed to require the placeholder to be used in the first place?

11

getattr already includes the attribute name in the Exception, is there a reason that getitem could not do the same ?

12

Ahh, I see what you mean now. Yes, that should be possible.

13

If you look closely at the exception here, where None comes from is underlined with a different underline from the attempt at subscription, which directly indicates which one failed.

While it may be possible to improve that message, just pointing that out for things you have to deal with now (and it should be faster to fix places you have to deal with this than wait for a new python version to do even more than this)

(And you should not rely on stability of exception messages, they aren’t guaranteed, so I hope you don’t mean to programmatically handle TypeError exceptions like this rather than split things and handle each possible error properly)

14

Noted, yes this was more just a QOL improvement suggestion by me as it strikes me as a useful breadcrumb that could be left to help to the developer get to the bottom of where it’s come from especially when debugging bad code like this.

The faster they can find where the bad code is and refactor it as you suggested above, the better. And if it’s a trivial change, all the better.

Obviously coding around the Exception’s error message would be madness but making it a bit more explicit about the specific error is always useful especially as not all tools such as Sentry will support that new REPL underlining indicator out of the box.

15

obj[key] is sugar for obj.__getitem__(key). The first step is to look up the __getitem__ method, and the second is to call it with the key. While it’s possible that the code that raises the TypeError has access to all three objects, it can already be raised just by attempting getattr(obj, '__getitem__'), so I would not assume that this is a trivial thing to do at the level that the exception is being raised.

The traceback generator, on the other hand, has access to both the exception and the code objects that created it, which I suspect is why you are able to get the helpful underlines at that point.

Also, note that reporting the key is also probably non-trivial. When it’s a string or integer literal, that’s one thing, but it could be an arbitrary expression that has up to that point not been evaluated. Attempting to execute it could trigger another exception, and attempting to report it could be quite long.

Anyway, this is not a part of the code I’ve spent much time in, but I suspect it’s not an easy QOL win.

1 Like