Is the 2.8 API abusing type annotations and isn't that dangerous?

Isn’t the way how type annotations are used to define properties an abuse of this feature?

While I see how this could somehow make sense to have these as “type” annotations, I’m wondering if this is a future proof concept, especially since typing is becoming more and more important for Python and as far as I have heard although some don’t like it, type checking could become part of the actual future interpreters.

And doesn’t it on the other hand break with the current standard that type annotations are currently completely optional by specifications? So this means actually I should be able to remove all type annotations from any blender addon and I should expect that it still runs without any type annotations as before.

Or is this common practice in other APIs / frameworks and I’m not aware of this and using it like this is actually pretty cool? :wink:

I don’t think it’s abuse. When Blender searches over your class to find the variables it needs to interface with in a special manner, it’s searching just .__annotations__ now instead of every member.

Fundamentally it’s the same as before but now, as you said, type annotations are becoming more important and Blender is guiding you in that direction.

Before blender would do the following:

loop over each member in your class:
    if the member is a variable AND is one of the many bpy.props.* classes:
        hook it up


loop over each annotation in your class:
    if it's one of the many bpy.props.* classes:
        hook it up

I don’t see how type checking could become a viable future for python interpreters when pseudo dynamic typing in both c++ templates and Java generics have not stopped the march of dynamic languages that have dominated the programming world the last two decades.

Type hinting like functional programming is nothing more than gimmick in python. It’s not even syntactic sugar.

Overall the support on static typing is the fallacy that compilers can capture type related issues. In reality nothing could be further from the truth because compilers are stupid by definition. They expect a precisely defined type for type checking to become meaningful which is ok when you deal with simplistic C structures but when OOP enters the mix the shit hits the fan.

OOP is not only invented by dynamically typed languages , it’s so deeply tied to dynamic typing because of its tendency to gravitate towards abstractions that makes OOP in static typed languages so pointless with many arguing , including me, that’s if the the language is static typed is by definition not a OOP language.

Blender’s struggle with its dependency graph is a glaring example. Is an example as is the messy nature of DNA and RNA structures.

So it’s no surprise that modern C++ is so heavily dependent on templates.

On the other hand C is not going anywhere either because dynamic typing’s thorn is performance. Problem is in this case type hinting is not typing which means you get all the negatives without any of the positives.

Why Python has type hinting ? It was never meant as a language feature but rather as a tool to be used by IDEs and code analysis tools to make it easier for them to understand intention behind code.

It’s not all bad though static typing can improve code readability because it tends to be more clear about coder intention. So it’s definetly a good idea for more primitive types. Nonetheless because Python is a language designed to be far more powerful than anything out there, which is why it’s pure OO including its procedural coding , type hinting may be the new hype but it’s by nature unpythonic so it most likely will suffer the fate of function programming in python , after the initial excitement will fall to a similar oblivion.

Type hinting could be used by Blender to optimize performance for Blender standard types , unfortunately Blender data is so incredible complex that makes it prime candidate for full throttle dynamic typing. So I predict we ware going to see quite opposite of relying more and more on dynamic typing of Python to describe very complex Blender structures , especially ones not so heavily dependent on performance.

For performance, nothing changes , you either port code to C to take advantage of the high performance of static typing or you rely on tool that do this for you like numpy and Cython.

On the other hand AI could shape the future of type hinting in python , performance wise but judging from Guidos heavy reluctance to complicate the VM implementation which has been the prime reason he resisted JIT VMs like PyPy , I am not so optimistic he will be eager to take type hinting or even optional static typing seriously any time soon. People in support of static typing are nothing more than a vocal minority. So like functional coding it will remain a fancy feature to be used wisely on a need to rely on basis,

It was never meant as a language feature but rather as a tool to be used by IDEs and code analysis tools to make it easier for them to understand intention behind code.

That’s what made me very sceptical thinking a bit longer of it after a short moment of thinking “that’s pretty cool” when I dived a bit deeper into the 2.8 API for the first time and I saw that this syntax is used:

use_setting: BoolProperty(
    name="Example Boolean",
    description="Example Tooltip",

type: EnumProperty(
    name="Example Enum",
    description="Choose between two items",
        ('OPT_A', "First Option", "Description one"),
        ('OPT_B', "Second Option", "Description two"),

In both examples the annotation feature is used by the API to define UI properties. The problem is, when I delete them, the code will definitely not work as before, since in the Python API type annotations are not optional anymore and even not used as some type hint but to define aspects of the code which is very “dangerous”.

I hope that this will not cause any trouble in the future.

1 Like

Provide exact code how you delete them.

No idea what the reasoning was behind mandatory type hinting, it may be this way to provide easier automatic code generation or specific optimizations for speed and stability. I doubt the reason was cosmetics.