Jodenee
Jodenee
I'm not sure if a protocol would fit in this situation, as you know every class in python can be converted into a str with or without manually implementing the...
Forgot to mention this in my last message but the user wont be able to pass raw numbers and such as arguments. So they'll need to convert those values into...
> If the user is using a type checker, they would already see it only accepts `str`. For attributes yes, but the methods do not strictly only take strings as...
> Because `object` implements `__str__`, all classes also implement `__str__` But what about any objects the user creates? `SupportsStr` is meant to allow custom objects to be passed as args....
> Then I think they should be typed as str instead. > What I meant was that I could not think of any form of class which would satisfy `SupportsStr`...
> I think we have 2-3 possible options instead: > 1. accept all objects and just call str() on them (no changes) > 2. to avoid breaking changes, change the...
> I would go with option 3 since we're working on 3.0. Breaking changes don't matter all that much. Alright, I'll begin work on that then.
Forgot to mention but option 3 was implemented in the above commits, feel free to review.
> Has decent testing been done on all modified functions and things that call them? I wouldn't be surprised if NC internally relies on `str()` being used. I wasn't aware...
> Also, the PR summary probably should get updated? I'm not seeing a `SupportsStr` anywhere. Yeah, I'll get on that soon.