I feel you've completely misunderstood what that issue about comprehensions in annotation scope is about. Its really nothing to do with supporting arbitrary weird syntax, its just fixing a genuine bug where something doesn't work when in an annotation scope (ie. when using the type var syntax) inside a nested class scope. The weird syntax in the bug report is because the bug was found by fuzzing: generating random weird syntax and throwing it at the interpreter to make sure it doesn't break it.
Its definitely not about allowing annotations to "accept comprehensions and lambdas." - you could ALWAYS do that. Its not about annotation syntax, its about annotation SCOPE.
Ie. consider:
class C(get_base_class()):
...
Here, we're calling a function to return the base class - not common, but perfectly legitimate. If we put this inside a nested class, we'll evaluate that function in in nested class scope. And if the class is a generic class, using the new TypeVar syntax, we're also in the **annotation scope** of that TypeVar. This is so you can do stuff like:
def foo[T](val : T) -> T:
And it knows that "T" here is the type variable, scoped to that function.
But there was a bug in the interpreter that caused this to fail when you also introduced another lambda or list comprehension scope, so while this:
class C(get_base_class([i for i in range(5)])):
...
would normally work, but if you did it inside a nested class, and made the class generic:
class Outer:
class C[T](get_base_class([i for i in range(5)])):
It'll currently fail in python 3.12. Worse, in some cases (the examples in that bug report) it'd fail with a SystemError - the python interpreter itself was reporting an erro . Far from meriting a "You don't say", that's something that should never happen: it indicates an internal error in python.
Currently in 3.12 the above just gives a SyntaxError (I assume because they just forbade this nesting as a stopgap in 3.12). But there's no reason it *should* fail: it's all perfectly legitimate syntax. If it worked without the annotation, it should definitely work with it - the above comprehension doesn't even USE the type variable (though the examples did).
As such, this is really nothing to do with relaxing what's allowed in annotations - its just fixing a bug where introducing annotation scopes broke this particular case.
I feel you've completely misunderstood what that issue about comprehensions in annotation scope is about. Its really nothing to do with supporting arbitrary weird syntax, its just fixing a genuine bug where something doesn't work when in an annotation scope (ie. when using the type var syntax) inside a nested class scope. The weird syntax in the bug report is because the bug was found by fuzzing: generating random weird syntax and throwing it at the interpreter to make sure it doesn't break it.
Its definitely not about allowing annotations to "accept comprehensions and lambdas." - you could ALWAYS do that. Its not about annotation syntax, its about annotation SCOPE.
Ie. consider:
class C(get_base_class()):
...
Here, we're calling a function to return the base class - not common, but perfectly legitimate. If we put this inside a nested class, we'll evaluate that function in in nested class scope. And if the class is a generic class, using the new TypeVar syntax, we're also in the **annotation scope** of that TypeVar. This is so you can do stuff like:
def foo[T](val : T) -> T:
And it knows that "T" here is the type variable, scoped to that function.
But there was a bug in the interpreter that caused this to fail when you also introduced another lambda or list comprehension scope, so while this:
class C(get_base_class([i for i in range(5)])):
...
would normally work, but if you did it inside a nested class, and made the class generic:
class Outer:
class C[T](get_base_class([i for i in range(5)])):
It'll currently fail in python 3.12. Worse, in some cases (the examples in that bug report) it'd fail with a SystemError - the python interpreter itself was reporting an erro . Far from meriting a "You don't say", that's something that should never happen: it indicates an internal error in python.
Currently in 3.12 the above just gives a SyntaxError (I assume because they just forbade this nesting as a stopgap in 3.12). But there's no reason it *should* fail: it's all perfectly legitimate syntax. If it worked without the annotation, it should definitely work with it - the above comprehension doesn't even USE the type variable (though the examples did).
As such, this is really nothing to do with relaxing what's allowed in annotations - its just fixing a bug where introducing annotation scopes broke this particular case.
Good point.
I don't love json.dumps(), but I can't claim I've ever found it mind-numbing enough that it's left me in a "trailing coma". That sounds no fun at all!
The trailing coma concerns loads() but I get why you get this impression.
I'm pretty sure that he was referring to the fact that you spelt it as "coma" instead of "comma"
Ah ah, I'm French and I completely missed the joked. Let me fix that :)