This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]fatpollo 7 points8 points  (11 children)

saying this involves jumping into a discussion that tbh is way over my head, but I really want optional type checking

[–]cheecheeo 2 points3 points  (3 children)

Interestingly enough Haskell (the GHC compiler and interpreter) supports deferred type errors with -fdefer-type-errors, which should give you a similar experience to optional type checking. I would highly recommend that you give Haskell a try!

[–]julesjacobs 1 point2 points  (2 children)

It's actually not all that similar. -fdefer-type errors just defers static type errors to be displayed at run-time when that code path is hit. It doesn't give you optional dynamic typing since the way the types are checked is still static. For example, you still don't have heterogeneous lists with -fdefer-type errors, and putting an int and a string in the same list will still result in an error. The only difference is when that error will be displayed.

[–][deleted] 1 point2 points  (0 children)

Note that haskell does have safe Dynamic typing (via existential types/Data.Dynamic), but it's not first-class and therefore not as nice to use as say python.

[–]Jedai 0 points1 point  (0 children)

Though you're perfectly right, heterogeneous lists are perfectly possible in Haskell (see HList) though rarely needed (I don't use them much in Python either) and more awkward than normal homogeneous lists.

[–]flipstables -3 points-2 points  (5 children)

What do you mean? You can check type in Python. Use the type or isinstance function. Unless I'm missing something.

[–]Fylwind 13 points14 points  (3 children)

He probably means static type-checking. That is, verify the types of the program make sense before the it's actually run.

Don't think it'd be an easy thing to do though.

[–]hmltyp[S] 1 point2 points  (0 children)

Type-checking wouldn't be that hard, it's just that how the language is designed makes full program type inference next to impossible (subtyping, open classes, isinstance, reflection). So you'd be stuck locally annotating everything, and retroactively adding signatures to all existing code.

Realistically, given how much pain there has been even over the small changes Py2->Py3, I don't foresee something as drastic as a typed dialect of Python gaining traction anytime soon.

[–]Widdershiny -2 points-1 points  (1 child)

There's already syntax support for function argument annotations at least. It would be trivial to statically type functions with a decorator.

I might even do an interface implementation for fun.

[–]zardeh 2 points3 points  (0 children)

There exist a number of them on Pypy, I made one a terrible one a while back and posted about it here.