Sturla Molden <sturla.mol...@gmail.com> writes: > Type hinting will be mandatory because of bad managers.
That's a pretty weird concept: I've worked for good managers and bad ones, but so far never one who imposed any low-level code style decisions without also being involved in writing the code. That was always left to project leads. Upper management (i.e. the CTO) sometimes made high level decisions like "the production apps will be in Java not Python" but that's different. > But then someone is going to ask what benefit Python has to offer: > > Readabiliy? No ... down the drain. The type hints don't impair readability as far as I can tell. Rather, they help it, since they indicate concisely what the function does. > Dynamic typing? No ... down the drain. It's still dynamic in the sense of having a universal type, and the hints can also let the compiler specialize. > Speed? No ... still 200x slower than Swift. I don't think it's anything like 200x now, especially with pypy. The type hints will allow more optimization though the language semantics will always keep it a slower than C/C++ (dunno about Swift). > Why go for Python? There is no benefit to it any longer. The type hints look like an improvement to me. I'd use them if they were available. I wouldn't have any problem with a project lead mandating them, just like they currently mandate use of specific unit test packages, etc. I could imagine mandating them in a project that I was leading. The "bad management" thing only applies when someone mandates coding practices that they themselves don't have to follow. I think you're imagining some terrible scenario that's not close to reality. Erlang has a similar feature that I've already mentioned a few times in this thread. I've used it and it's a good feature. It helps keep the code organized and it doesn't get in the way too much. You don't have to put a signature on every function: it's optional so you can put them in just the important places and let the tool figure out the rest. If you use a seriously typeful language like Haskell, you have to design your whole program around the static types. But with Erlang you can code pretty much the same way you would in Python, add a few signatures here and there, and that's enough for the analysis tool to do some quite useful checks. I remember in one of the endless static-vs-dynamic debates on comp.lang.lisp, someone mentioned a code instrumentation experiment that found that even in dynamic languages, most functions were monomorphic in practice. I think that's mostly because experienced programmers unconsciously follow an ML-like type discipline most of the time, even when the compiler isn't enforcing it. So having some compile-time checking will mostly do good. -- https://mail.python.org/mailman/listinfo/python-list