Fragile code and lots of trial and error #8081
mtomassoli
started this conversation in
General
Replies: 1 comment
-
You're abusing the Python static type system here. It's unclear to me what you're trying to do, but I can say with high confidence that this approach won't work well. This is not a use case that pyright is designed to handle. I think it's safe to say the same about other Python static type checkers like mypy. I recommend looking for an alternate approach to whatever problem you're trying to solve. |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Maybe I'm asking too much of Pyright, but even when I find a mathematically correct way to get the result I want, I have then to try out lots of equivalent formulations to make it work.
Here's an example. Suppose we have unlifted and lifted types. An unlifted type is a built-in or pre-existing type, whereas the associated lifted type is a type we created and thus control.
For instance,
list[T]
is an unlifted type, andmy_list[T]
is the corresponding lifted type.Let's say the function that does the lifting is called
lift
: it takes an unlifted object and returns the corresponding lifted object.A simple solution to write
lift
would be to create an overload for each "unlifted_type -> lifted_type" correspondence, but that's inefficient. Iflift
has 1k overloads, 1k uses take minutes on my PC.I did manage to bring the time down to 2-3 secs by building an n-ary tree of types and then doing an n-ary search.
The code is a little involved. Here's an example for 1k elements:
This code is generated programmatically, of course :)
I've experimented with lots of other ideas, but this is one of the most performant.
I then realized that I had to import all the unlifted and lifted types to make this work, so I gave up on this approach.
The new idea is to create small custom
lift
right when they're needed.For instance, if a file uses 5 unlifted types, then one can just add support for them this way:
A1
, ...,A5
are the lifted types, and theAny
s can be omitted.One may then
lift
a supported unlifted type this way:Again, all this is necessary because we have no control over
Unlifted1
so how can we find the correspondingA1
? We have to search for it, of course.Here's the full code, including the tests:
My problem with this is that the method
__call__
right before the tests is extremely fragile. Getting it to work was extremely painful, and every little change breaks the code. For instance, swapping 2__f?
is enough to break it.The versions with a single
f
didn't work, the ones with 2f
s worked but gave weird error messages, and, finally, the current version with 3f
s works. But it feels like I'm exploiting implementation details.Am I doing something wrong or are these limitations of Pyright?
Beta Was this translation helpful? Give feedback.
All reactions