Conversation
|
typing.cast is a no-op (identity function) at runtime. |
|
I feel like typing is overkill for small demos or even small apps and instead distracts from the main purpose. |
|
Right now the primary idea is to have a second language option "Python (typed)" that would use the normal Python source, and then "Python" would show the source stripped of type checks, ideally by an automated tool. I will put this to draft for now. |
|
I saw the discussion - maybe it can be extended to some kind of "Best practices" toggle? |
|
I'll probably end up doing that. |
|
@theCapypara can you reopen against https://github.com/workbenchdev/demos/ ? Please note we now have separate |
|
I'll be back tomorrow and do some cleaning up, also have some PRs to review :) |
3 participants
This is the first demo that would use
typing.cast. What is your opinion in that?I feel like with data driven APIs like this, and due to the fact it relies much less on the already established global objects than other demos, showing the user a good way to be able to properly type this is both useful to know for real world apps and also makes some parts of the demo easier to read, since it's now clear from the code how the different objects are related (eg.
ListItem.get_itemreturning theStringObjectbecause it's aStringList)The downside is that casts can't really be checked statically. So in theory this could break, but in practice even if it would, the demo also wouldn't work properly then anyway.