I write data science code, it's a mess. Type hints have saved me a lot of time and headache.
Python’s “type hints” are a bit of a disappointment to me
491–500 of 597 posts
Re: Python’s “type hints” are a bit of a disappointment to me
#492Earlier quoted context omitted.
> integration tests running on real data not on mokups. I can see you are enjoying the life outside of a highly regulated industry. Having certain kinds of production data in tests (or feeding that to test environment) would be a major audit finding in any finance or healthcare company. Makes for both a blessing and a curse.
You can anonymize such data or get the necessary agreements for a small subset. All of which is tricky, but not impossible.
> You can anonymize such data
...thereby destroying the production-like features for which you want it for testing, which you then need to recreate and reintroduce, so you might as well just synthesize test data in the first place, since that's what you end up doing anyway, in effect.
Re: Python’s “type hints” are a bit of a disappointment to me
#493Earlier quoted context omitted.
> You can't call something that isn't a function. Sure you can. That's exactly what you do when you call a function returned by `dlopen` -- it might be a function, but it might also just be garbage. It might even be garbage that's coincidentally marked as executable and does some stuff before eventually crashing! > You can't call a function on something that doesn't have it. This is also very easy to do -- you can de…
I think you're talking past the comment you're replying to. In both examples, you have tell the compiler exactly what the types are. In the first one you have to cast the return value of `dlsym` to a function pointer, and at that point, as far as the compiler is concerned, it's a function. In the second example you have to explicitly declare the struct containing function pointers, so of course you can call its membe…
I didn't say it was "somewhat untyped." I said it has a very weak static typing system.
Just because "weak typing" means something different in Haskell doesn't mean it can't be used meaningfully (and beyond "bad") in the context of C. C's typing is historically referred to as "weak" because C's notion of casting doesn't distinguish between type and value transmutation: pointer-to-pointer casts don't convert the referent (because they can't), which in turn gives the C compiler very little leeway in proving that the program's types as declared have any particular meaning at runtime.
Compare this to Python, which is "strongly" typed in the same sense: doing `y = str(x)` on `x` means that `type(y)` actually is `str`, and not merely a promise to the runtime. It's enforced, which makes it strong.
Re: Python’s “type hints” are a bit of a disappointment to me
#494Earlier quoted context omitted.
The whole reason Python and JS surpassed most all other languages is specifically because you can write code fast, without worrying about strict definition of data structures. The issues with python code bases aren't from a lack of strict typing or type support, but from a lack of a good testing framework.
JS is popular because it's literally the only language web browsers support. Python is popular because it's very beginner oriented, so it's the first language a lot of people learn. It's modern BASIC. Neither of those things mean that writing dynamically typed code is a good idea. The idea that you can write dynamically typed code faster isn't even true once you get past a couple of hundred lines.
This concept of "programer is generally dumb, so languages must have features to prevent them from making mistakes", with strong typing falling under those features, is solely an academic exercise that is taught in academia, and perpetuated by people who just wanna fit the mold in FAANG and other big players.
And Python being popular because its basic/beginner oriented is a laughable statement. http://highscalability.com/blog/2012/3/26/7-years-of-youtube.... Not to mention that all the bleeding edge ML stuff is Python first.
Language adoption directly depends on how quickly people can build stuff in that language, and its an exponential effect, because with speed of development comes more libraries, which in turn allows other people to build stuff that uses those libraries quicker. And the initial speed of development directly depends on the programmer having to manage less things. Static typing, in real world, is often a hinderance because code bases are dynamic, and having to go and refactor code because data definition changed takes time. And if you have competent programmers that write clean code and a good code review and testing framework, static typing gives you no advantage since the time spent fixing issues due to failing tests will be equivalent to spending time fixing issues with failure to compile.
Re: Python’s “type hints” are a bit of a disappointment to me
#495Earlier quoted context omitted.
Not typing is kinda a crazy way to write programs when you think about it. It can be beneficial in certain niche use cases like data science where code is always terrible. For everything else, types are a huge boon for the developer and everyone consuming their work
Have you tried it? Python has gained most of its popularity before type hints, and I would (wildly) guess 99% of Python programmers don't even use type checking at all. Static typing is completely viable and I hear those arguments mostly from those who didn't use Python for a long time. The added productivity makes up for a little more debugging while the program is running. I'd also posit that many Python codebases…
I'm not sure I'm following your comment correctly, but you seem to be implying that adding type hints in Python results in some lost productivity?
If so, I would counter that adding types isn't particularly onerous and adds very little overhead to development time, and over time they'll tend to increase your productivity since you'll make less errors, IDEs can give you better hints, etc.
As to the percent of Python developers who use types / type checking, it seems to me that's been changing somewhat rapidly over the past few years. It's certainly greater than 1%.
Re: Python’s “type hints” are a bit of a disappointment to me
#496Earlier quoted context omitted.
If you find that you are returning silly types like that, then it is an indicator you are writing your function badly and should refactor it to be simpler
That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list. What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union. I'll leave it to you to write that Union "type".
As of Python 3.10, you can use `T | U` instead of Union.
Starting from 3.8 (I think), you can also directly use dict[T, U] and list[T] rather than having to import Dict and List.
Re: Python’s “type hints” are a bit of a disappointment to me
#497Earlier quoted context omitted.
> make things possible, often just to run it once This is the largest difference. When there's no expectation of code lasting beyond a very short lifespan, why go through the effort to future proof things, improve maintainability, have better ergonomics, etc?
Because science doesn't work unless experimental results are reproducible.
Sure. And once you land on something worth keeping, you clean it up then. But between time point 0 and then, a whole lot of code gets written to be run very few times.
Re: Python’s “type hints” are a bit of a disappointment to me
#498Earlier quoted context omitted.
I like the validation scripts being available in a repo so I can run them locally before pushing to CI, but I also often use WIP commits and quick fixups and then rebase before opening the PR, so pre-commit hooks are really annoying to my workflow. I more often than not just do `git commit --no-verify` or simply delete the git hook in `.git`, then just run it myself before pushing. Anyway CI will catch it, so I don't…
Yeah, when you just want to add a checkpoint WIP commit its annoying. Hate having to fight with that. But it prevents people form submitting a PR and then just having CI fail anyways. I could see it being nice to only enforce on CI though. Sucks seeing those red builds because someone didn't run something manually.
I don't see it as a big issue as we just assume PRs with failing builds not to be ready for review and push them back to draft. But whatever works for your team, honestly. In the end what matters is having a CI acting as authority source, the rest is simply workflow related.
Re: Python’s “type hints” are a bit of a disappointment to me
#499Despite this: > Even if the Python runtime did check all the type hints at runtime, then it would still be too late. I don’t want a fancy type exception at runtime. That already exists (most of the time). I want to know about type mismatches in advance. You should check out Typeguard [1], which lets you add a @type_checked decorator to anything and get runtime type checking that's far better than e.g. a random blowup…
Do you know if there is a way to do runtime type checking in the whole program with typeguard, beartype or something else? As far as I know you have to go through and add decorators manually. Typeguard had a profiler hook that almost got it right, but is being removed. Ideally I would want to say 'python3 -m typecheck myprogram.py' and it would run typechecking everything in my code (but maybe not in library code).
I believe you're describing MyPy? http://mypy-lang.org/
Re: Python’s “type hints” are a bit of a disappointment to me
#500Earlier quoted context omitted.
That's not a silly type, it is just a silly type annotation. It's easy to unpack the tuple inside that list. What is not easy is type-hinting it. What if I want it to be both an list and an iterator? Well, I would have to use Union. I'll leave it to you to write that Union "type".
As of Python 3.10, you can use `T | U` instead of Union. Starting from 3.8 (I think), you can also directly use dict[T, U] and list[T] rather than having to import Dict and List.
I would rather see work done on something more useful than new syntax for typing.