Hacker News Reader

Comment by linsomniac | Hacker News Reader

Honestly, I've recently written a few 300-500 line programs in Python using type hints and I'm never going back. And I'm not even using mypy often, if ever.

My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code. There have been a few times where I found an error, went into the editor and saw I had missed a error message about that line. Shout out: Using LunarVim with LSP and TreeSitter.

The other thing I'm enjoying is that libraries can use them to make things happen more automatically. I believe it was Typer (the CLI argument parsing library) where if you declare an argument to a function as "files: List[Path]", it understands that the argument will take one or more files, or "-" to mean stdin. If you just say "file: Path", it understands it is a singular file.

I was curious about type hints when they first came out, wasn't really expecting to use them but they seemed cool, but now I'm totally sold.

View on HN

>My editor now has a fairly deep understanding of my code, and can tell me of all sorts of surprising errors I'm making before I run the code.

I agree this is useful, but to me the most useful feature of types are the self-documentation. It's crazy the difference between a non-typed library with shitty documentation vs a typed library with shitty documentation.

The types on stitty-documented code often do depend on the types actually being checked though. Otherwise you need to author to be diligent in their types, but if they're bad in their other docs, that seems unlikely.

You don't think that "the author thought that this function would return X, but I got Y" is useful?

Only for archeological, and maybe sometimes psychological investigations of code.

That line of reasoning doesn't make any sense to me.

If the author / last person who touched the code misunderstood it then there is a 100% chance there is a bug here.

Knowing that off the bat is quite helpful. And it also tells something about the code quality if it is a common occurrence.

Could be an indicator to look up the file in git log.

Which need would send me back to pypi to look at other prior art, if possible.

Some people are willing to be meticulous about references even when they're Less Good Than One Might Wish at picking names or explaining things.

type hints are documentation, and machine readable documentation to boot!

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

I think data science is a perfect example in favor of types -- the code is often terrible because of the lack of typing. Pandas has notoriously poor developer ergonomics, and I recall painfully poring over type errors across the board -- lists, dataframes, numpy arrays, etc. are all iterables, so they can be interchanged in some contexts, but not in others.

Had I had MyPy back when I was working in data science, I would've saved countless hours and headaches.

What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding.

No, the code in data science isn't bad because of the lack of typing. The code is "bad" mostly because those writing it are relatively fresh from starting to program. Also there is more pressure to make things possible, often just to run it once, and neglect repeatability or scaling to larger code bases. Different emphasis. That doesn't mean an experienced full stack developer would do Data Science better, because he might lack a lot of skills that matter more in that domain.

> That doesn't mean an experienced full stack developer would do Data Science better, because he might lack a lot of skills that matter more in that domain.

This resonates with my experience. I had the opportunity to work on a DS codebase written entirely in Scala with all the typing, parallelism, actor model, whatnot. Basically I joined the company because of this technical factor. It was fun until I figured out that DS was "typed IF-THEN-ELSE written by Java devs in Scala returning stuff the users complain about with high reliability within milliseconds". Now I am happy to be back to the single threaded untyped Python world. Still no bugs in production, because we validate all requests to death, have unit tests and integration tests running on real data not on mokups. Basically we follow the principle: if the integration test passes, our typing is just right, or at least good enough. Funnily all the typing errors we catch are caused by wrongly typed data, coming from the productive system written in a typed programming language... what a strange world.

> 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.

I know you probably just want to be annoying, but really, there is a world of difference between completely synthetic and anonymized data. Without talking about specifics, anonymizing is just the operation of making the process of deanonymization a lot of harder. "Hard enough" is usually specified in some form by the regulator. You can identify an individual by their ECG data, for example, it's just really hard...

No, in actual practice you don't scrub the stuff you actually need to test.

> I know you probably just want to be annoying, but really, there is a world of difference between completely synthetic and anonymized data.

No, I’ve spent ~20 years in healthcare, with this issue as a frequently recurring issue.

> No, in actual practice you don't scrub the stuff you actually need to test.

In actual practice, the stuff you really need to test often overlaps with the stuff minimally required to scrub to legally deanonymize the data. The most common scenario I’ve seen trying to do this is both creating most of the work of generating synthetic data and failing to legally deidentify the source data.

What I wrote was meant in the context of data science. You can not do ML without having access to real data, not even in highly regulated industries. Obviously you won't touch PIIs. But whether the real data is sitting in your train/test/validation data set or you use it for integration tests, doesn't make any difference from the perspective of an audit.

> 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.

> Pandas does is notoriously hard to fit into a compile-time type system

What, mutate data with known structure? What exactly do you imagine is hard about this, let alone notoriously so?

Not hard per se, but extremely unergonomic.

A pandas dataframe types to something like Iterable[SomeKindOfProductType[int, str, str, ... (78 other columns)]]. The formal type of a dataframe in the middle of a transformation is... not very useful to know.

You wouldn't typically type tabular data in any language. Give it (at most) a DataFrame<StoreTransaction> type if you must, where StoreTransaction describes the structure of a row - maybe declaring only columns that model generation code was doing typed operations on (e.g. numerics vs strings) to avoid the need for reflection.

Either you type the tabular data at compile time or you don't get type checking of tabular data at compile time.

The number and types of the columns aren't necessarily known at compile time. Which leads to runtime errors. Even in a statically typed language, such dataframes are a kind of "dynamic typing escape hatch". As complexity of a software increases, such mechanismus of dynamic typing and throwing runtime errors creep up all over the place.

Sure. If you're dealing with untyped data at runtime you can't type it at compile time. Not a new issue, and handled all the time in otherwise typed languages.

It's not very useful to type, but that's why we have type inference.

It's certainly very useful to know, even if that knowledge is indirect via the type of the resulting dataframe after all the transforms.

From dabbling in F# I have a feeling such "information" would be somewhat more annoying than useful.

> What Pandas does is notoriously hard to fit into a compile-time type system. Certainly too hard to go into the brains of scientists who didn't grow up coding.

I'm not sure if that's true. Doesn't Pandas handle ETL and some anaysis? There is nothing inherent to ETL that makes it a hard problem with compiled languages.

In your opinion, what does Pandas do that's hard to do with compile-time languages?

I didn't say "with compile-time languages" but "with compile-time type systems". And many similar tools in a statically typed language will necessarily create a way to have one static type that doesn't care what the data inside actually looks like.

This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor. Worse, most often you don't know (or want to know) some of the dimensions or even dimensionality of some of the objects. Then it is impossible to check all of this at compile time.

> This even starts with basic Numpy and handling tensor objects. It's not easy for a type checker to understand what operations you can do with what shape of tensor.

That doesn't sound like a Python problem.

Instead, it sounds like the natural consequence of numpy being designed in a way where their data types aren't organized into subtypes, and leave that as runtime properties. This is a natural reflection of numpy's take on vectors, matrices, and tensors, which in terms of types are just big arrays with runtime properties.

To put things in perspective, in C++, Eigen supports static dense vectors and matrices whose size is specified and known at compile-time. I'm sure Python doesn't impose addition static type constraints than C++.

Of course it's not a Python problem, all similar tools have the same "problem" that they can't easily fit that stuff into their type systems, so they invent some way to not care about it.

It isn't a matter of "compile time": explicit type declarations and definitions can often be formally sound but practically worthless.

Significant types in ETL-style applications typically come from outside (e.g. a certain CSV column in the input file contains a date in YYYYMMDD format, or maybe YYYYDDMM, figure it out, and don't forget time zones or your accounting will go wrong).

Then types are mostly complex but obvious and easily deducted (e.g. multiplying matrices of compatible shapes necessarily gives a matrix of a certain shape, why should the program say anything more detailed or lower-level than "do a matrix multiplication" or "do a tensor product"?); they are an often dynamic and unpredictable property of the data, not a useful abstraction.

The source code shouldn't need to say anything about the type of the resulting matrix explicitly, perhaps. But why shouldn't the type system keep track of shapes and deduce the accurate type for the result of said multiplication?

Because the shape can be dynamic, for example.

> What Pandas does is notoriously hard to fit into a compile-time type system.

Sounds a lot like F# type providers to me.

https://thesharperdev.com/introduction-to-fsharp-type-provid...

As I said, it is hard.

And good luck teaching beginning scientists F#.

Totally agree, I would love for data scientists to use types and a lot of other good practices. I work primarily in mlops and have been trying to do this for some time, it just mostly feels like a losing game.

The output of most analytics is a report. For longer lived processes it seems easier to just hand off

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 are somewhat less "untyped" than one might assume. Django for example does a lot in its ORM and Form classes to make sure the right stuff goes in the right slot.

If you mean “Python programmers” to be random sysadmins that write hack code residing on a random EC2 instance then maybe you’re right. But most I get the sense you haven’t looked at many Python libs lately.

The added productivity of non-typed Python is such a ridiculous myth to anyone who has to maintain significant Python code bases. Sure, it makes you more productive for one-off exercises but the moment you’re having someone else inspect your code the productivity gains vanish. This largely true of dynamic languages more generally except in niche caches (e.g., ORMs) where types are strongly implicit.

I say all this as a mathematician that is used to reading papers full of symbols packed with implicit information. The code I’ve read from gung-ho dynamic typing advocates is some of the most painful drivel I’ve ever had to wade through.

Python libraries aren't representative of Python code. The majority of Python programmers (not "just sysadmins" wherever that slur comes from) never publish or contribute to any libraries.

I can compare Python's productivity to other languages, and it beats all of them so far. Another lesson I learned from working with statically typed languages: The quality of the code is more dependent on who writes it than on the language or even the ecosystem. But people are productive much sooner in Python than they are in C# or F#, and then we can work on the foot-gunning.

Python's productivity isn't a myth. This is proven by its popularity and by successful projects across academia and industry alike.

You might be more productive in Python versus anything else for the scale and complexity of the software you are involved in, but you cannot make sweeping generalisations like this. I also think you fail to understand that in many situations, static type systems actually improve productivity, especially at scale or for non-trivial domains. This is of course why Python is now trying to retrofit them.

There's also the argument that one is most productive in what they know. As someone who has spent far too long with Haskell and OCaml, Python's semantics and libraries often seem surprising and counterintuitive to me.

I "fail to understand" something you actually never did or experienced, right? I know that a lot of companies are maintaining large Python codebases, and the "lack of typechecking" might be one of the biggest pain points, but the total pain is a lot less. That was always my experience and most people who say differently haven't actually used Python that ...

I know that Typescript helped me over Javascript. I don't get that benefit from Mypy yet, but the "pain" just isn't as great as it was with JS. And I've seen what inexperienced programmers do when a static typecheckers try to force or encourage them to do the right thing. It's not necessarily the right thing, just a lot more complicated than it needs to be.

> I "fail to understand" something you actually never did or experienced, right?

No, I have worked at a variety of large institutions that have millions of lines of Python. I work with it often. The use of Python is more about it being accessible for non-developers, which is why they also teach it in schools; and the need for a standard. It is the new "Visual Basic". Again, it is not more productive in all situations.

If you write more code that is untyped than typed, you are harming whoever comes after you. Untyped code is an absolute dragon even if it is properly documented (which it practically never is). Glorifying "productivity" and putting it above the greater good is essentially everything that's wrong with the world, at every level.

That’s quite a strongly worded opinion. It sounds like it should be utterly trivial in this case to show that typed code causes less harm. I’m happy with whatever definition of harm you’re happy with. So where can i review the data supporting such a strongly worded position?

On a quick search, for example https://link.springer.com/article/10.1007/s10664-013-9289-1. "This paper describes an experiment that tests whether static type systems improve the maintainability of software systems, in terms of understanding undocumented code, fixing type errors, and fixing semantic errors. The results show rigorous empirical evidence that static types are indeed beneficial to these activities, except when fixing semantic errors." is pretty much as strongly worded as scientific journals can accept.

Cool - this paper has 3 conclusions:

- Static type systems are an effective form of documentation

– Static type systems reduce the effort to fix type errors

– Static type systems may not be helpful in preventing semantic errors

It would have been awesome to have evidence for #3 but even just #1 & #2 could be useful, albeit to a much lesser extent. Could we quantify by how much?

It’d be important to quantify because if static types mean a developer can be done sooner, then they have spare time to spend improving the software. So do these differences with static types translate into benefits for the developer?

The author of that paper says no. He published this other paper just after that one: https://www.ics.uci.edu/~jajones/INF102-S18/readings/23_hane...

For the second paper, looks like the test task is quite small and the language used requires more work from developer than a modern static type system with type inference and generics. Still the difference between static and dynamic typed variants is rather small. I wonder if the situation would change if the project took weeks or months instead of hours, but that would be an expensive experiment. Also, it would be interesting to see if type inference and generics would increase productivity but in the real world we are stuck with Java and Go anyway.

Other take home message is that the famous 10x programmer was found in both groups. The one with dynamic language was faster, just as the argument for dynamic typing goes.

You can review it by talking to people that inherit your code, especially if they're still acclimating to it :)

So you don't have any hard data either...

programming languages : diehard dynamic typing advocates :: global pandemic : mask mandate protesters

There is no conclusive and objective evidence that static typing helps at all. Studies are at best inconclusive, certainly a far cry from confirming the superiority of static typing. Everything else is subjective. To have a recent and complete opinion about the one thing you necessarily need to have less of a recent and complete experience with another.

The benefits of masks against spreading respiratory viruses are easily and objectively proven. Completely different thing.

Well, while you're waiting for that study to ride down from heaven on a white horse clad in gold, the rest of us are going to just quietly get on with being (subjectively) more productive.

https://link.springer.com/article/10.1007/s10664-013-9289-1

The number of times I've stared at some random Python function deep inside a library wondering what does this function return? Even the docs often don't say.

It was very productive for the person who wrote the library.

Would you be able to share an example of this?

I took a random stab in pandas but they’ve adopted type annotations so that defeats the point. So i thought old-school code bases - zope sprang to mind, but that’s not a good example either because they use docstrings and it’s kind of obvious. So i tried gunicorn on a whim and they have even more attention spent on their docstrings.

I just want to sample this feeling of lost confusion in python so that i can figure out how I’d deal with it.

I was actually looking at urllib3 yesterday trying to work out the return value from HTTPConnection.connect which calls this _new_conn function internally:

    def _new_conn(self):
        """Establish a socket connection and set nodelay settings on it.

        :return: New socket connection.
        """
  ...
        try:
            conn = connection.create_connection(
                (self._dns_host, self.port), self.timeout, **extra_kw
            )
  ...
        return conn

(I've chopped it down a bit to emphasise the important bits)

What's the type of "conn"? It certainly wasn't clear to me that it's a socket.

But just now I looked at upstream and I notice they've added type annotations, which do greatly improve things:

https://github.com/urllib3/urllib3/blob/e16beb210c03c6f5ce4e...

    def _new_conn(self) -> socket.socket:
  ...

So a small victory for type annotations there.

When i hover over connection.create_connection i get a docstring that says it returns a socket.

That docstring isn’t enough for the problem you had though, e.g. I wasn’t clear from that if they meant a socket.socket or maybe some special socket derivative type so i hit go to definition and create_connection is a short method - i can see it is indeed a socket.socket being created, configured and returned.

I’m guessing you’re not using any developer tooling, maybe a straight text editor i guess?

This kind of tooling has been around for a long time, i remember using rope and jedi in vim back around the late 2000’s i think. It’s gotten a LOT better since PyCharm appeared mid 2010’s i think - first i recall using it must have been around 2014-ish. These days, it’s even better. I would really strongly encourage adopting some kind of tooling that lets you navigate and has some basic refactoring - rename is usually 80%+ of the value there so it doesn’t need to be complex. A few ergonomics like having the ability to jump to test and call from repl with a keystroke - you’ll turbo charge your comfort and productivity.

That has to be our difference i think because it took one mouse move and one key chord to completely bottom out.

Well, the author of that undocumented function maybe did not mean for it to become widely used.

There are a lot of "libraries" people write for their use only, who then put them on Github as a token of good will.

You as a user of someone else's library can either contribute to it or learn to use it. Otherwise, write your own equivalent.

> Otherwise, write your own equivalent.

And be judged for wasting time reinventing a wheel?

Hey, it is still your wheel, built according to your use-cases.

That is never a waste of time.

On the small scale, Python is very productive. Once you get to large codebases with a rotating roster of many developers, it becomes a net negative, which is why type specification languages are gaining major inroads. I love Python, but I wouldn't write anything for production at any scale in it anymore. But for small scale stuff, it remains my favorite! (Although, I like static binaries languages, like Go, for a lot of things these days because of the deployment simplicity)

What's your definition of "large codebases" here? My experience is that on Python codebases large (~100k lines) and small, type annotations are generally a net negative, particularly with a "rotating roster of many developers", because of their complexity and detrimental effect they have on readability. As the OP says, incorrect types are worse than no types at all.

type hinting is a bandaid, I'm not going defend it. My argument is that statically typed languages are better for large scale development.

You still haven't defined "large scale" or "better". And you haven't backed up your argument with any evidence.

How is typing productive in large codebases? If I see a bunch of imports related to typing only, I have to juggle them around in my mind together with stuff that really matters.

Not to mention the notorious circular import problem, that is much more likely in a big codebase.

If I have a custom class, that class has to be passed as a type hint for functions. What If I use that class in another module, but have to import it inside this one that has a type-hint only?

Well, let me introduce you to their genious solution:

  from _future_ import annotations
  from foomod import FooClass

  def myfun(foo: FooClass):
    return foo.bar()

Wonderful, isn't it?

I also find most of the "import typing" stuff to be clutter. I worked at a place that was heavily into adding typing to existing code, some of which was almost a decade old. They spent more than a few person years on that effort, and it's still going on.

Not once did I find the additional typing useful in my actual day-to-day work.

Scaling a code base doesn't start or end with type checking. Some of the answers to what you are implying is: Use interfaces when using OOP. Consider dependency injection or other Inversion of Control patterns. Maybe don't use OOP as much...

What is "major inroads"? Python is actually rising in popularity and major companies are building big things entirely in Python...

In my opinion there is no excuse not to.

Python has a tremendous amount of momentum because it has become so popular outside of the traditional software development world, but other languages are picking away at it, even given that momentum. And while I am in a bubble, like everyone else, in my bubble, and those I talk to in my bubble, all see large a shift away from Python.

Adding stronger typing, like type hints, could reverse that, of course.

The reason not to is performance and reliability. Typing helps with the latter, Python is just bad at the former.

That "shift" away from Python wouldn't be seen in any particular data, right?

Major companies build things entirely in Javascript, too. Popularity doesn't mean anything. Honestly, for a small web app, I'd pick PHP / Laravel over Python. Deployment is way simpler.

What you both are experiencing is your bubbles clashing.

I have been developing almost exclusively in Python for the last 4 years (occasional C#, Java and PHP) and although my entire team disparages PHP it is really quicker and fewer characters for most stuff.

Luckily IDEs can auto add the imports, but sometimes a slightly mistyped piece of code auto adds an import I need to delete, I love avoiding imports and circular imports in PHP. The other nice thing is avoiding random python behaviour differences in MacOS, Windows and Ubuntu. Code that works fine in CircleCI but not locally. Works on a Mac but not on windows etc… I didn’t experience that with PHP.

Not sure there are a huge number of long term PHP devs who switch to Python or the other way around to have a reasonable opinion.

This is a rather uninteresting statement, as we all live in bubbles - knowledge of them helps, but really just puts you in a different bubble. Still a bubble.

I'd say all metrics point to the popularity of Python increasing, while there is no data indicating that people are fleeing Python en masse. Or at all, actually.

In my view it's both. I'm one of those "scientific" programmers. I've used type hints, just to learn it, but tend not to use them in practice. Bugs caused by typing errors seem to be extremely rare in my little world.

I've also programmed extensively in Pascal, assembly, and C. I get it about types. Don't forget C has 8 different types of integers that have to be kept straight. ;-)

On the other hand, I realize that any of my programs is but a little nub of code sitting on top of large and expertly maintained libraries. I'm grateful for whatever the authors of those libraries are doing to keep their sanity, and am not surprised when I see type hints in those codes.

If you have programmed extensively in Pascal, assembly and C, you aren't "one of those scientific programmers". Or at least not the newer generation that got started on R, Python and maybe SAS...

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%.

I disagree, dependencies can change causing types to change which requires you to alter hundreds of lines across multiple repos.

Each new line or character is a line to maintain, there is a cost associated with that. Tests have costs but are extremely valuable, they are a no brainer to me, types are way less obvious.

I have spent a lot of time maintaining python types. I have no idea how many bugs it has prevented. I am not sure it is a large number.

I know there have been bugs in types, bugs in mypy and dependency changes which created work which only existed because types were in place. There have definitely been days worth of types maintain.

There are the extra type imports, extra time to run tests and integration tests etc.

It is not as straightforward as you might initially assume.

I did not say type hints damaged productivity. There is no evidence to point either way, actually.

Gradual typing is based on effort. Most people won't spend the effort. And they don't need to, most of the time, either.

I have absolutely tried it and worked on many code bases big and small before typing happened. I've also worked on other languages and paradigms and seen what works and doesn't.

In my experience its the other way around. Most people who are a fan of dynamic typing have worked in systems with types. The world is largely coming around to the view that types make more consumable and safe software

As a data scientist, you make a strong point.

For me, python is mostly a calculator, and it seems faster to try a calculation and immediately see if it runs and/or looks correct, rather than try to implement type hints et al (though I still use type hints occasionally).

Yeah, especially types like:

  List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]

Oh, so I am supposed to make my own data structures now, just for typing?

How about no?

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".

It is a silly type for a function to return, because you have three levels of data structure nesting, with not one bit of information about the meaning of any of the values except their types. If I call your function and then do result[1][2], what does that mean?

This is exactly the kind of situation where you're supposed to use a named tuple or a data class to make it clear what's what.

With tuples inside of lists, you usually unpack them to variables in a for loop.

Named tuples are just immutable classes with slots. Unless you want to slow your code down considerably, it's best to avoid them.

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.

I am amazed at how much time some devs will waste on trying to figure out type annotations, at the expense of actual work time.

Learning any new syntax, feature, etc takes time. IME learning type annotations can pay major dividends. For example, I wrote some type-annotated code the other day and mypy pointed out a couple places where I was passing the wrong type, which saved me from having to fix those bugs later, thus saving time for "actual work."

There is a recurring cost to complex type annotations and that is that every single developer working on that repo (could be thousands) has to unravel the complex types, their aliases and the instance objects to modify any code.

This as opposed to a legitimate type system where complex types are classes themselves which don't need unraveling. There is no need to alias a type and there is no need to maintain separate complexities for the object and the type.

I agree that complexity could be an issue with Python's typing, which has some flaws, although it's been improving.

Type aliases are okay if they're not overly complex, having used them in Python and other languages to good effect, e.g. to avoid duplication or for clarity.

I'd suggest using type annotations where it's not overly onerous--which is probably most places--to get the benefits without much effort but perhaps avoid them or use simplified types where it's too complex.

I also agree that there are places where typing is unnecessary and doesn't add much value, such as in certain scripts.

Like many things in programming, it's all about finding the right trade-offs.

yeah it speaks to your ability to create code people can understand, that doesn't change with types, they just illuminate it

I, too, can write code that everyone understands! Behold it's beauty:

  Union[List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]], Iterator[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]]

Yep, that's gross. Having come from a position where people where forced to actually add typing like this to make it through code review, I feel the pain.

Seems to me you have a Data Structure problem. What type of data is this suppose to represent and why can a Class not fix it.

Why would I need a class for this?

It's literally a tuple containing two three-tuples inside a list.

Do a for loop over it, unpack it and you are done..

LOL, just assign that beast of a type to a name and roll with it:

  Thing = List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]
  
  def foo(t: Thing) -> Thing:
      ...

Totally agree. I'm on a project using python for the first time and really can't believe how horrible it is to not have type checking, especially given that it takes time to run the code as a glue job.

I use them for the same reason. I've started sprinkling them into projects where I can. Other devs on the team seem to like seeing them, but have higher inertia when it comes to writing them.

Have you (or anyone else on this thread) used retype or MonkeyType? We have a codebase right now that's mostly lacking type hints. But, now that we have added automatic flaking into our build (and pre-commit hooks), I'd like to get some more mileage out of that toolchain we just invested into, but it would be a hassle to go back and add type hinting to everything.

What I'd like to do is integrate something into our pre-commit hooks.

Actually depending on the LSP, you are using a type checker since Pyright is its own type checker and Pylsp has a mypy plugin

> I'm not even using mypy often, if ever.

Hopefully your CI does?

It's not really as necessary as you think -- making mypy/pyright pass your CI ends up being a lot of busy work to make the type checker happy when, to me, all the value is realized when it's used as a development aid. If your test suite passes that's honestly more than good enough.

You have the right attitude. I have worked with delusional individuals who one day "soon" expect to mypy check their entire several hundred thousand line legacy code base. This is supposed to be a boon to developer productivity. I hope it outweighs what was lost getting to this point.

Not yet, but that might be coming. I have one personal project set up to run mypy as a pre-commit, but I'm not (quite) ready to force that on my coworkers.

same, started using Objects and Classes more to get type hint support

Reply on news.ycombinator.com