“Assume it’s a map and treat like a map and then catch the type error if it’s not.” Paraphrased from actual advice by Guido on how you should write Python. Python isn’t a bad language but the philosophy that comes along with it is so fucked.
Why though? I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong. Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?
I worked on OpenStack back in the day: millions of lines of untyped Python.
Let’s say you’ve got an X509 certificate. You know you can probably pull the subject out of it - how? Were I using Java (for instance), the types would guide my IDE and make the whole thing discoverable. The prevalent wisdom at the time was that the repl was your friend. “Simply” instantiate an object in the repl then poke at it a bit.
And it’s not just that kind of usability barrier. “Where is this used?” is a fantastic IDE tool for rapid code comprehension. It’s essentially impossible to answer for a large Python codebase.
Don’t get me wrong: python is still a great go-to tool for glue and handy cli tools. For large software projects, the absence of type enforcement is a major impediment to navigation, comprehension and speed of iteration.
And as for your specific question: typechecked code doesn’t get to production with a type error; it won’t compile. There’s a common phrase, “left-shifting errors”. It means catching bugs as early in the development cycle as possible. In terms of things like developer time (and patience), it’s far more cost-effective to do so.
“Assume it’s a map and treat like a map and then catch the type error if it’s not.” Paraphrased from actual advice by Guido on how you should write Python. Python isn’t a bad language but the philosophy that comes along with it is so fucked.
This is just preferring runtime validation instead of compile time validation.
And relying on runtime validation is a horrific way to write production code
Why though? I’ve genuinely never had a problem with it. If something is wrong, it was always going to be wrong. Why is it preferable to have to write a bunch of bolierplate than just deal with the stacktrace when you do encounter a type error?
I worked on OpenStack back in the day: millions of lines of untyped Python.
Let’s say you’ve got an X509 certificate. You know you can probably pull the subject out of it - how? Were I using Java (for instance), the types would guide my IDE and make the whole thing discoverable. The prevalent wisdom at the time was that the repl was your friend. “Simply” instantiate an object in the repl then poke at it a bit.
And it’s not just that kind of usability barrier. “Where is this used?” is a fantastic IDE tool for rapid code comprehension. It’s essentially impossible to answer for a large Python codebase.
Don’t get me wrong: python is still a great go-to tool for glue and handy cli tools. For large software projects, the absence of type enforcement is a major impediment to navigation, comprehension and speed of iteration.
And as for your specific question: typechecked code doesn’t get to production with a type error; it won’t compile. There’s a common phrase, “left-shifting errors”. It means catching bugs as early in the development cycle as possible. In terms of things like developer time (and patience), it’s far more cost-effective to do so.