With some fiddling, I managed to both get Mypy to accept my code for now, and to produce an actually decently-small example of what's going on to file a bug report. It looks like that's getting looked at.
Anyway, let's take a look at some of the motrfile code I want to make an equivalent of in the new system.
yield from run_pytest( "profile", "profile", ( "pyinstrument", "--renderer", "html", "--outfile", profile_dir.map(INDEX).as_output("profile"), "-m", "pytest", ), "pytest-profile", (profile_dir,), )
I... hm. Just so we're clear, these functions that mostly take string arguments... kind of suck? Anyway, let's break it down.
The stuff I care about the most is the tuple in the middle.
- pyinstrument the executable
- --renderer html or --renderer=html is needed for output; other values are possible, but I'll leave it at this for the initial release
- --outfile <path/to/file> is the other part of output; the existing new-style code should handle the profile_dir input stuff later on
- -m module runner argument; this is proven out with the Python wrapper
I fiddled around, and got everything to a point that seems to make sense... and then it failed type checking because I hadn't accounted for placeholders in some of the utility code I'm trying to use. (Side note from looking at the names I'm using: wow, some of these names are bad. Like, there's a "Labeled" type that doesn't actually require a label???) Anyway, placeholders. In a fancier system, I would be lobbying for higher-kinded-typevars or something like that about now, but there's no point when there's only one instance to work with currently.
Hm. I appear to have dug myself deeper into a hole here. This helper code isn't really taking to the placeholders, and I'm going to need to think some more about how to address this, and avoid making any rash decisions. (I mean, I could make some, like, alternative methods to handle placeholder versions, but that would... sort of suck.)
I'm going to take a few days to ponder this, and try to wind down for now.