Type annotations don't seem to actually have any effect, though? Consider:

    >>> def add(a: int, b: int):
    ...     return a+b
    ... 
    >>> add("a", "b")
    'ab'

This should be an error, even if it's a runtime error.

it's optional typing. Running it through mypy will result in an error. If you are using type annotations I don't see why you wouldn't also be using a proper IDE or testing your code.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments.

I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

I've been using enforce for this purpose (https://github.com/RussBaz/enforce). It provides decorators that enable type checking where wanted. This gives the advantage of migrating existing code to type checking at your own pace at least.

On a general note I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes, and that makes the whole thing feel like a hack. It's better than nothing for my use cases, but if I remember correctly both mypy and enforce have problems in common that are probably coming from the way python itself is built, such as self reference in a class definition.

> I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes

With pep-0563, python3.7, and `from __future__ import annotations` this should no longer be necessary. Those are some pretty detailed caveats, but I have been using it in places where I can and it is so nice.

Python has a "we're all adults here" mindset, which means it will allow you to reach into internals of libraries, ignore type hints, etc because maybe you actually know what you're doing and know the drawbacks but just need a quick solution (lots of python code is small throwaway scripts).

For actual projects you can use a static type checker like mypy.

Make mypy type checking part of the CI pipeline. Done.

Type annotations have no effect by default. You're free to use a tool to do compile or runtime checking though.

> `a.y() and do_x()`

If you're happy to write it that way round, why not just use `if a.y(): do_x()`?

It's worth noting the second can't be used inline.

I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python. [x() if y()] if it existed, might carry an explicit else None.

On the other hand [x() and y()] does something different when y() is falsey.

>I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python.

Maybe I misunderstood your context, but if not, conditional expressions do exist in Python:

  $ python
  Python 2.7.12 |Anaconda 4.2.0 (32-bit)| (default, Jun 29 2016, 11:42:13) [MSC v.1500 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  Anaconda is brought to you by Continuum Analytics.
  Please check out: http://continuum.io/thanks and   https://anaconda.org
  >>> 1 if 1 == 1 else 2
  1
  >>> 2 if 1 == 1 else 2
  2
  >>> ^Z

  $ py -3
  Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
  Type "help", "copyright", "credits" or "license" for more   information.
  >>> 1 if 1 == 1 else 2
  1
  >>> 2 if 1 == 1 else 2
  2
  >>>

Using nested conditional expressions to classify characters:

https://jugad2.blogspot.com/2017/04/using-nested-conditional...

Sorry, the code shown in the two Python interpreter sessions above, is not a good example. To make the concept of conditional expressions more clear, this example is better:

  >>> from __future__ import print_function
  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 == 1 else "even")
  ...
  3 is odd
  4 is even

which can be shortened to this:

  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 else "even")
  ...
  3 is odd
  4 is even

Now print() is printing 3 values: i, "is", and either "odd" or "even" based on the boolean condition.

That works in both Python 2 and 3.

Against pep-8 standards. I do end up using that sytax quite a bit anyway though.

> PEP8: This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.

It's fine not to follow PEP8 for your own software. It's a useful guide, not a law.

> You can use type annotations, either via the builtin lib or 3rd party libs!

> https://docs.python.org/3/library/typing.html

I know, but tragically, because I am not forced to, I never do. I do appreciate that feature though. Maybe this will be the impetus I need to start taking advantage of it.

I started doing this about a year ago and it has made me a better Python developer. Getting into the habit of always writing a type annotation was hard at first, but you quickly get used to it. It helps if you configure mypy to complain at you if the annotations are missing.

You'll have a much better experience in an ecosystem where typing is the widespread expectation, IME.

Try an ML-family language if you haven't already - I find they combine the best parts of something like Python and something like Java. There was a post pushing F# earlier today.

If you're starting a new project you can force yourself by running mypy's strict mode in CI.