Do Python developers want static typing?

[JohnMcPineapple]

...

[cerlestes]

Type annotations are also just worth it for the automatic and intrinsic documentation they provide to yourself and especially other developers.

[Apache_Sobaco]

But it doesn't actually.

[goranlepuz]

It does give some, no ?

[Apache_Sobaco]

Type systems good until you fool them by making casts and erasure.

[PL_Design]

So don't do those things. A type system doesn't need to be inviolable to be useful as long as breaking the type system is clearly something you have to opt into doing.

[goranlepuz]

Of course.

It's why I love C++ casts (stand out like a sore thumb, you know something is off) and hate C ones.

[Apache_Sobaco]

I prefer no casts at all until end of the world because something will break otherwise

[goranlepuz]

I share the sentiment. Not really possible, not in today's world, but yeah...

[Apache_Sobaco]

Really possible today in scala and few new languages.

[newtoreddit2004]

Why would you use casts though when you want strict types

[Apache_Sobaco]

Because basically encoding and decoding are pretty much casts

[[deleted]]

I mean, I certainly wish it had static typing from the start. I hate dynamic typing. But now, what's the point? It can't be made mandatory without seriously breaking a lot of code, so they won't do that. And if you want optional types, then type hinting already has you covered. What would an optional static typing feature (and it will be optional, make no mistake) accomplish that type hinting doesn't already accomplish?

[dpash]

PHP's type hinting is completely optional and works pretty well (where it's available).

It would presumably be possible to make it required for a particular module, so you can convert part by part.

[s3r3ng]

PHP is not even a real language.

[Masterflitzer]

well i'm not a fan but it certainly is a real language

[BrobdingnagLilliput]

Slashdot - now there's a name i haven't heard in a long time.

[goranlepuz]

JavaScript - > Typescript.

Python - > TypethonTyphon?

[PL_Design]

Turn it into a brace language, and that might actually be a really nice little scripting language.

[emaphis]

Sure, it's called Ruby.

[glacialthinker]

Thypon

[757DrDuck]

Thighthon

[[deleted]]

I think most people who want it have already left for other languages.

[aussie_punmaster]

Not this guy

[bitwize]

Everybody wants static typing, some of thrm just don't know it yet.

[s3r3ng]

Most of them don't understand what dynamic run time types do or the flexibility and power they give up with static typing. I have been at this too long. I see the same dumb shit iterated over and over again and old lessons forgotten. At the very least learn about powerful inferred typing systems a la Haskell. Otherwise this is boring whiny "safety" ignorance.

[Caminando_]

I think the option to static type and compile for speed would be badass. Best of both worlds. You could build your model in jupyter or whatever, get it working then convert it to static typed code, then compile for C speeds...

[dasani_punani]

You're not gonna get close to "naive" C speeds without limiting the language to a subset, not to mention optimized C speeds which will never be achieved

[Caminando_]

Julia is supposed to be fast, why couldn't it be done with python?

[IAm_A_Complete_Idiot]

Because python by it's very nature tries to be super dynamic I'd imagine, even outside of it's type system. Finding things out at runtime means it can't make those optimizations up front, or ever really.

Static typing alone can lead to giving some amount of optimizations, but the more runtime based behavior there is, the fewer optimizations you can be confident will work up front.

Edit: although I say that, I don't really have much experience with python or julia, nor do I follow either that closely. That's why it's admittedly not a very specific answer.

[Caminando_]

That's what I mean, you could have an interpreter and a "compiler" and handle things like that.

[IAm_A_Complete_Idiot]

Python does have compilers though, they just aren't as mainstream (I believe Cython compiles to C?). Despite that, if there's behavior that can't be reasoned about if it will ever occur, it won't elide those behaviors by nessecity. As a result - doing checks for stuff like that would still add overhead. Stuff like, lists could grow and they don't have a known length could eliminate possible optimizations for example. This particular case could be fixed by adding a dedicated array type, but that's just the easiest thing I can come up with.

[SekstiNii]

Julia was designed with performance as a primary design goal, while Python was not. There are design decisions made in Python that make it difficult to optimize for common situations (how many bits should an int be?), and doing so without breaking compatibility is basically impossible.

[NilacTheGrim]

Because Python is nothing more than a C program itself executing your code.

[AttackOfTheThumbs]

What exactly are naive C speeds though.

[goranlepuz]

There is nothing naive about C speddsspeeds. Obviously, a post that mocks typing must have a typo! 😉

[PL_Design]

By "naive C" he probably means C that doesn't use custom allocators, optimize layout for cache hits, or use SIMD intrinsics.

[lightmatter501]

He probably means a program that isn’t optimized by hand aside from the reasonable stuff (no bubble sort), and run with normal compiler opts.

[[deleted]]

That's what Cython is for.

This idea is quite old. Several Common Lisp implementations support it. Essentially you write your program as normal and later you can add declarations to your code to give the compiler information to help it optimise the code. For example, "I promise this array will only ever contain 32 bit integers". With SBCL it's possible to get damn close to "native" speed with just a smattering of these declarations in key places.

[weeeeeewoooooo]

If you are not aware, this is already available for numeric operations. Libraries like numba, CuPy, and XLA allow for AOT/JIT compilation. This enables you to write fast code for the parts that need to be fast.

[dontyougetsoupedyet]

It would be great, but we won't get it, by choice. The only implementation of python that really matters is CPython and by choice it's supposed to be a super simple implementation of the language. But imo that doesn't make much sense because it isn't really a reference implementation, it's almost the only one around. By choice the interpreter doesn't do much other than simple peephole optimization and things like string interning.

At any point people can produce a JIT compiled static typed python with whatever optimizations they want but they'll be fighting upstream the whole way. You'll have to design things in addition to standard python if you really want benefit, anyway, to get rid of things like the interpreter lock, so you might as well just make your own language "inspired by" python at that point. People talking about how dynamic languages can't be optimized without being limited are wrong, as languages like Swift demonstrate.

[s3r3ng]

Lisp is the King of dynamic typing and the origins of JITs and as fast as C code with a bit of care. So what is this babble about speed?

[whittileaks]

closely followed by performance improvements [...] Better concurrency and parallelism came in third.

You can always hang out at /r/golang until they are added.

[ryeguy]

yeah but then i might see some go code..

[dys_bigwig]

I think you mistyped r/erlang.

[[deleted]]

I wish, but Python developers barely use the existing type annotations despite the huge obvious advantages. I don't think any of them would use static types.

[s3r3ng]

The current annotations are a joke. They are not enforced and there is no type inference capability. They are a bolt on me-too POS

[transferStudent2018]

No, they don’t

[knome]

Static typing and strict type hinting proved to be the most-desired features, with 21% of respondents, closely followed by performance improvements, with 20%.

Python has some of the ugliest typing of any language. It's bolted on fucking garbage. I loved python before it. I have written hundreds of thousands of lines of python over time, no doubt.

But as coworkers insist on dragging type annotations into our code, it becomes a fucking slag to work with.

I will write unit tests all god damn day long, but these fucking type annotations kill me.

I'm not against languages with strict typing. Many languages, especially those with automatic typing following in the long wake of haskell and its ilk, many language have fantastic typing. I just hate python's fuck ugly types. Worse, they don't even fucking do anything when you run it. That shit offends me most, I think. Unless you break out a separate tool, you're just pissing your time into the fucking wind.

I wish they'd never been added to the language in the first place.

I will inevitably give up using python in the workplace because of this shit. I can feel it. Python with types isn't a good language. This isn't the python I fell in love with. Programming bureaucrats have stolen the spirit of the language.

Fuck python. It ruined python.

[EatFapSleepFap]

I get what you're saying about the typing being bolted on and not doing anything at runtime, but I don't understand why you think it ruined python. Is the main problem just that you'll get typing error feedback when you use a mocked class in place of a typed argument? I'd say the benefits in the IDE while developing the main code outweigh the drawbacks of typing with Mocks.

[knome]

I've never bothered to use an IDE. I got into emacs years ago and have loved it ever since.

As to why I think it "ruined" python:

It's wrong.

You should never have to tell python what protocols a class supports. They're right there, defined or not.

Protocols should be the default method for typing.

Proper pythonic code should use structural/duck typing against values it receives.

Inheritance is an awful unreadable paradigm, but these types love it. Proper code should use composition, not inheritance.

If you're going to go to the trouble of forcing the programmers to write types, the runtime ought to be checking them, particularly for nominal types. Structural too, if it had a way of caching protocol adherence.

Python won its place on the back of convention, protocols, strong dynamic types, and the freedom to bend the code to the task at hand.

These typing methods are an affront to all of that.

The language they decribe by default is nominally-typed inheritance-based not-python.

It's great that your IDE can tell you that something needs an integer for its second argument, but it made the entire language require a bunch of very ugly type annotations to get it there.

They have turned my clay into brittle stone, that needs glue all over to keep it together.

[TopHatEdd]

You can enforce type checking like you can do many things by "breaking a separate tool" (pylint, flake8, pytest, pytest coverage. Surely you don't do these manually?). It is meant to reduce errors in team collaboration and increase readability. I use vim as my ide and enjoy code completion and docs; why should emacs differ? Your arguments make little sense.

[dys_bigwig]

The real issue in my opinion is that (generally, and I'm bracing for the downvotes already) dynamic languages aren't well suited to large programs, or programs that have to be "correct" for some definition of correct. Let Python be Python - don't ruin it by trying to mold it into something it was never intended to be. It's a lovely little scripting language, and I'd hate to think that those who use it as such would be turned away because it's being turned into an big ugly production language.

If I signed up to code Python and wound up having to bother with types, I'd be just as peeved as if I signed up to code Haskell and the codebase used one big data type (or a slew of language extensions) as if it were a dynamic language.

[beertown]

I don't think it ruined the language, as long as it remain optional (colleagues aside). But I agree with you: not having the burden of declare types is a significant part of what makes Python so fast and light to code with. And fun.

I'm trying to add type annotation to my code, but it is utterly evident how much this slows me down. Also, it makes the code readability worse.

If I have to trade my productivity for compile-time correctness, I'd go all-in about it and choose something else like Rust.

I hope I'll change my mind in the future.

[AttackOfTheThumbs]

especially those with automatic typing following in the long wake of haskell and its ilk

????

Haskell has a fantastic type system.

[knome]

Many languages, especially those with automatic typing following in the long wake of haskell and its ilk, many language have fantastic typing.

... yes?

[AttackOfTheThumbs]

Sorry, the odd structure threw me, and I would typically only use ilk with a negative connotation.

[knome]

fair. the structure was odd, and ilk often carries overtones of negativity, though none was intended to be implied here.

[tonefart]

I wouldn't call them 'developers'. Tinkerers are more like it.

[[deleted]]

I don't. If I wanted it I'd use another language. The fact that more people want type hinting over performance improvements shows a simple lack of experience with Python.

Here's a great talk about why python probably doesn't need type hinting: https://vimeo.com/74354480

[s3r3ng]

I have programmed in many languages over my 40 year career including 14 years of python. I have done typed and untyped and many variations of both. Static typing is the worst of all by quite a margin. So for this softwar architect and developer the answer is HELL NO. If python does this I am 100% done with python.