Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python type hints may not be not for me in practice

utcc.utoronto.ca

Post reply on HN
Print view View original

201–209 of 209 posts

Re: Python type hints may not be not for me in practice

#201

Post by hermitdev »

agubelu wrote: post #7

Type hints are nice, until you have to interact with a library that isn't type-hinted, and then it very quickly becomes a mess. I don't know how other IDEs behave, but VScode + the Python extensions try to infer the missing hints and you end up with beauties such as `str | None | Any | Unknown`, which of course are completely meaningless. Even worse, the IDE marks as an error some code that is perfectly correct, beca…

FWIW, you have some control over how this inference is done. Search your settings in vscode for `@ext:ms-python.vscode-pylance strict`.

Re: Python type hints may not be not for me in practice

#202

Post by int_19h »

ansgri wrote: post #60
rcfox wrote: post #58

Earlier quoted context omitted.

Pretty much anywhere you're tempted to use a namedtuple, you should be using a dataclass[0] instead. And typing JSON-like data is possible with TypedDict[1]. [0] https://docs.python.org/3/library/dataclasses.html [1] https://docs.python.org/3/library/typing.html#typing.TypedDi...

Why? I thought one should prefer immutability. As for typed dicts.. yes, I’m mostly stuck on old python versions, nice reminder.

In general, preferring immutability is great. In Python specifically, it can be hard to pull off given that e.g. something as basic as dict does not have a standard immutable equivalent. You inevitably have to rely on conventions - basically saying "this is supposed to be immutable" rather than enforcing it.

Re: Python type hints may not be not for me in practice

#203

Post by Myrmornis »

CJefferson wrote: post #54
Myrmornis wrote: post #29

Earlier quoted context omitted.

Can you give some examples of how the Python type system is disappointing you?

Mainly, the seems to be no way, in a dynamic language, to dynamically check if functions get the right types. To me, this means I don't really understand the python type hinting at all, as adding hints to just one or two functions provides no value to me at all. I assume I must be not using them usefully, as I've tried adding type hints to some projects and they just seemed to do nothing useful.

It's a static type-checking system, along the same lines as what Rust, Java, C++ etc have during their compilation processes (and what Typescript has during its transpilation step). The main purpose of static type-checking systems is to find bugs before you ever run the code. It's most useful if your editor shows the type errors as you type, but it can also be done by running pyright or mypy from the command line. And of course running pyright or mypy in CI to guarantee type errors don't get into main. But you are right that in Python they are optional and the value increases with the number of annotations you add!

Re: Python type hints may not be not for me in practice

#204

Post by otherme123 »

pmontra wrote: post #164
otherme123 wrote: post #75

Earlier quoted context omitted.

>these people don't push code out as fast they could. Well, one of my coworkers pushes code quite fast, and also he is the one who get rejected more often because he keep adding .tmp, .pyc and even .env files to his commits. I guess "git add asterisk" is faster, and thus more efficient, than adding files slowly or taking time to edit gitignore. Not so long ago I read a history here in HN about a guy that first coded…

They invented .gitignore to prevent those files to get checked in into the repository. Head, paper, keyboard is what we did in the 80s when compilers were too slow to afford throwing code at them and fix the errors later. Was that code in the HN story a substantial piece of code or some 100 lines program? Our programs used to be small.

.gitignore doesn't prevent you from committing unwanted files if a pattern is missing. This is a real example: .gitignore had ".sqlite3" extension ignored, but this coworker created a test database as ".dbsq3" or something like that for some reason. He forgot to add the pattern to .gitignore and the file was commited.

Also you can have .env in the .gitignore, yet someone create their file as .env.local and escape the .gitignore pattern. It's easy to come after and lecturing about creating a better .gitignore pattern, but it's even easier to at the very least take a little care of your commits even if it means slower speeds.

Re: Python type hints may not be not for me in practice

#205

Post by throwaway2037 »

maleldil wrote: post #181
throwaway2037 wrote: post #121

Earlier quoted context omitted.

You can use: > @dataclass(frozen=True) to create an immutable data class.

While that works (and I use it extensively), it's a bit hacky. You have to use `object.__setattr__` to set attributes in `__init__` or `__post_init__`, which looks so wrong.

What is wrong with a static factory method?

Re: Python type hints may not be not for me in practice

#206

Post by hbrn »

IshKebab wrote: post #173
hbrn wrote: post #79

Earlier quoted context omitted.

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startup...

Proper engineering isn't that much of a concern when you have 0 customers, and by the time you have some it's too late to change. Besides nobody is claiming that it's impossible to build a successful products with dynamic typing. It's just not as good. You can build a successful product with zero comments in your codebase, doesn't mean it's a good idea.

> It's just not as good

Again, the evidence (as limited as it is) suggests otherwise. You are more likely to succeed if you're going with dynamic language and not doing "proper engineering". This has been widely accepted before type-checker era, and I see no reason why it would be different now. Utilize type checker when it's free, but don't waste time on type puzzles.

"Proper engineering" doesn't get you to product-market fit faster. All it does is tickle your ego.

Re: Python type hints may not be not for me in practice

#207

Post by hbrn »

sethammons wrote: post #131
hbrn wrote: post #79

Earlier quoted context omitted.

How come all those unicorns were built with intolerable Python/Ruby, not Java/C#/Go? https://charliereese.ca/y-combinator-top-50-software-startup...

My previous unicorn rose despite the initial tech, not because of it

I gave you a selection of top 50 startups out of thousands funded by YC. You're giving me one anecdote.

Re: Python type hints may not be not for me in practice

#208

Post by hbrn »

IshKebab wrote: post #193
hbrn wrote: post #76

Earlier quoted context omitted.

> Most code with type hints is easier to read That has not been my experience in the past few years. I've always been a fan of type hints in Python: intention behind them was to contribute to readability and when developer had that intention in mind, they worked really well. However, with the release of mypy and Typescript, engineering culture largely shifted towards "typing is a virtue" mindset. Type hints are no lo…

> intention behind them was to contribute to readability This is provably wrong. See https://peps.python.org/pep-3107/#use-cases

Have you read the whole section?

> Documentation for parameters and return values ([23])

> Let IDEs show what types a function expects and returns ([16])

> For example, one library might use string-based annotations to provide improved help messages, like so:

  def compile(source: "something compilable",
    filename: "where the compilable thing comes from",
    mode: "is this a single statement or a suite?"):

Re: Python type hints may not be not for me in practice

#209

Post by VagabundoP »

joeyagreco wrote: post #77

> After the code has stabilized I can probably go back to write type hints [...] but I'm not sure that this would provide very much value. I think most developers who revisit their projects 6+ months later would disagree with the second part of this statement. My typical flow for "quick scripts" is: on first pass I'll add basic type hints (typing ":str" after a func param takes .2 seconds) for more complex data struc…

Considering that most AI add-ons type hint code reasonably well, there no real reason not to, just for readability.

It takes a few seconds to prompt and then check it.

Post reply on HN