> it's subject to change in future releases; you'll need to change
> your code accordingly if it changes
> because it's language change, it's unlikely you can conditionally
> choose which syntax to use based on the version of Python being used
> you enable it explicitly and accept the instability o
Reading the latest discussion about PEP 622/634-636 on the Python Dev mailing
list, I've noticed there appears to be confusion about what `__future__`
imports are supposed to be used for. Multiple people in that thread (and
probably elsewhere in one of the many many threads about these PEPs) hav
> From a cultural perspective (with python traditionally not being written in
> this style)
> I think writing code like this at the level of internal library code (that
> the user of the
> library will not see when using the library) is perfectly fine.
>From a cultural perspective (with python t
> Alas, this still doesn't work because type annotations are advisory and
> not mandatory. Regardless of the type hints given, I can still call
> div(1, "surprise") and get a TypeError.
I'd assume that everyone is a consenting adult and if someone really wanted to
shoot themselves in the foot t
I think on this point at lot of people will have to agree to disagree. The
clear advantage for me is that the `ZeroDivisionError` that is naturally part
of `div` is made explicit and handled in a type safe way (given than one is
using a type checker like mypy). Especially in this example I can't
