Type annotations?

[jamesob]

What's the thinking around adding type annotations? I think in certain cases it could be very helpful, but don't want to start down that road if that's out of alignment with the goals of the project.

[jimmysong]

It could be useful, but honestly, I don't want to turn this into a strongly typed library.

[jamesob]

Makes sense - in certain cases it would be nice to have return values "documented" with annotations. You could optionally check that stuff with mypy, without modifying any kind of runtime behavior. Is that something you're amenable to or do you want to stay away from annotations altogether?

[jimmysong]

I can see the argument for it, but I'd rather document things more naturally through explicit documentation or implicit in the function/method names. Appreciate the advocacy, though!

[jamesob]

Gotcha, okay. I may end up just writing a separate lib then; I find stuff like this really helpful:

diff --git a/buidl/cecc.py b/buidl/cecc.py
index 5af5313..948005b 100644
--- a/buidl/cecc.py
+++ b/buidl/cecc.py
@@ -101,7 +101,7 @@ class S256Point:
             GLOBAL_CTX, sig.raw, msg, len(msg), xonly_key
         )

-    def sec(self, compressed=True):
+    def sec(self, compressed=True) -> bytes:
         """returns the binary version of the SEC format"""
         if compressed:
             if not self.csec:

But thanks for the consideration!

[jimmysong]

It's open source for that reason! Please feel free to fork!

[mflaxman]

@jamesob can you explain a little more why you like the annotations? I don't like them in general because they've always felt unpythonic to me: they're hard to read, not strictly enforced, and you don't get the performance benefits other languages get with strong typing.

It's not a knock on strong typing, it has tradeoffs that are often good for bitcoin apps. In some ways I feel more comfortable using golang with bitcoin for example.

I appreciate the signet PR so I don't want to be turning you off of buidl unnecessarily! I'd like to understand your perspective better.

[jamesob]

they're hard to read

Matter of personal preference I guess, but I find them really readable - I like having an unambiguous place to look that tells me the return type of a function, or what the expected type of a parameter is. Code winds up being much easier for me to explore and use that way.

not strictly enforced

Now that there's pretty decent third-party tooling, annotations can actually be checked in the development and linting phase. E.g., using pyright:

In my project coldcore (a kindred spirit to this library) for example, one of the CI steps is running mypy to check the annotations for correctness.