Seems like part of the problem is that there might not be much overlap between the types of things he points out that aren't optimized - which are obscure and useless - and what could "legally" be optimized.
So, yes, something like this isn't optimized:
def foo():
return [1024][0]
But it's also pretty unlikely to see something like that in actual code. One could argue that that's just an example of a /type/ of a more general case, but I think you'd find that the more general case can't be safely optimized because Python is insanely dynamic. So e.g.
def foo():
return SomeArrayLikeThing(1024)[0]
can't be optimized because not only might the behavior be very different from a typical Python array, the behavior could very easily not be determined until the exact moment when that code is run.
IOW, the things the author points out are things that, in practice, end up being so narrow and rare that there's no real point in trying to optimize them.
So, yes, something like this isn't optimized:
def foo(): return [1024][0]
But it's also pretty unlikely to see something like that in actual code. One could argue that that's just an example of a /type/ of a more general case, but I think you'd find that the more general case can't be safely optimized because Python is insanely dynamic. So e.g.
def foo(): return SomeArrayLikeThing(1024)[0]
can't be optimized because not only might the behavior be very different from a typical Python array, the behavior could very easily not be determined until the exact moment when that code is run.
IOW, the things the author points out are things that, in practice, end up being so narrow and rare that there's no real point in trying to optimize them.