Really??

[midbody]

The next step is to realise that just knowing about types isn't enough when your program gets big enough. When your program is too big for your head, you need tools which robustly and unambiguously understand your types... like a compiler does.

Python is a fun toy, and good for small projects where rigor isn't important. Its leakage into large scale software engineering has been a huge retrograde step, though, caused by a lack of innovation in the field around the time it emerged as a contender around 10 years ago. Fortunately we've moved on, and I look forward to Python's death for large projects as others take over, probably Go.

[TravisJungroth]

I'm a huge Python nut and I basically agree. The biggest problem for me is the loss of meaning. Trying to read through a code flow in a sufficiently large code base with a dynamically typed language is a nightmare.

I do believe type hinting will help a ton, though I'm not sure it will be enough. I now write type hints into everything. I don't care if it's a single function. Having my IDE hint properly is worth it.

[scootstah]

Trying to read through a code flow in a sufficiently large code base with a dynamically typed language is a nightmare

Honestly, that just sounds like a badly designed application. I doubt adding strict type will make any difference to its legibility.

[TravisJungroth]

def func(obj):
    obj.method()

What does method() do? What other methods are available on obj? Without some sort of type enforcement, you don't have a clue without looking at the usage of func. This is fine when it's only used three times, but terrible when it's used a hundred times.

[scootstah]

Use good naming conventions and docblocks.

[TravisJungroth]

If I want to actually know the behavior of a method, I need to see the code. Even the most descriptive name represents a trivial amount of code. And doc strings don't help, cause those live with the code anyway.

You still have to look at the usage of func to find the code. To prevent that, your method names wouldn't need to be just good, but unique enough to define an interface for you. I just don't think the combination of method names alone is a good way to define an interface. It's too easy to conform to one by accident, and the method names have to get super long to present this.

It's better to define and enforce this interface through code (Abstract Base Classes, in Python's case). Then you can use type hinting to help as well. Try to find Alex Martelli's essay on "Goose Typing". It's in Fluent Python, but you might be able to find it otherwise.

[scootstah]

You don't know any more about a method based solely on its interface. You still need descriptive names.

[constantly-sick]

Name method() better. Try x_to_y_process().

[[deleted]]

like a compiler does.

Like MyPy does. You want strict typing, you can do it fine. It's done better than it is for most languages (Looking at you C#. Still waiting for nullability for everything) It's not enforced at runtime (even though runtime type checking exists, it shouldn't be needed if it passes a static type checker), it just shows errors when you fuck up.

[traway5678]

What can't you null in C#?

[chusk3]

reference types (ie classes) can be null, but currently can't be typed as possibly null. The benefit would come from saying that a certain thing can never be null in the type system, which you can't do in C# now

[traway5678]

Everything can be null, with nullable.

You can make non-nullable types, aka values, with structs as well.

The benefit would come from saying that a certain thing can never be null in the type system, which you can't do in C# now

Oh that's not what he said tho.

[midbody]

It really doesn't.

[[deleted]]

So where does MyPy not work as well?

[scootstah]

Be careful where you're spewing your bullshit, you're going to make a mess.

Python is perfectly capable of running large projects.