You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The actual implementation of pexpect.SpawnBase does not contain these functions but it is an abstract class and all children have these write methods.
Since almost all interesting pexpect code does some form of writing it is impractical to use SpawnBase as an annotation. The only viable solution seem to be annotating with PopenSpawn or maybe an union if you actually want to be generic?
Perhaps it would be acceptable to add these stubs to SpawnBase despite what is written in the implementation.
The text was updated successfully, but these errors were encountered:
I'm generally not a fan of diverging from the implementation when it can be avoided, but I see some merit in this case. An alternative would be to define a stubs-only type alias with all the alternatives, or maybe even better a stubs-only protocol that defines all the methods required by clients.
The actual implementation of pexpect.SpawnBase does not contain these functions but it is an abstract class and all children have these write methods.
Since almost all interesting pexpect code does some form of writing it is impractical to use SpawnBase as an annotation. The only viable solution seem to be annotating with PopenSpawn or maybe an union if you actually want to be generic?
Perhaps it would be acceptable to add these stubs to SpawnBase despite what is written in the implementation.
The text was updated successfully, but these errors were encountered: