-
Notifications
You must be signed in to change notification settings - Fork 234
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we encourage abstract types? #12
Comments
I don't think it's a problem if local variables or attributes have concrete types. Also, function return types should often be concrete, in my opinion, since dynamically typed code can easily make assumptions about the concrete types, and I don't want to make statically typed code unnecessarily restrictive compared to dynamically typed code. I think the biggest benefits of abstract types are for function argument types. I guess we can safely recommend using abstract types for argument types in public interfaces, at least. |
Yes, variables and attributes have concrete types and it's all good. Function return types might want to be concrete or abstract, depending on who defines the interface (see: Protocols). |
Łukasz, I think you can close this issue once you add a sentence to the PEP text. |
hmm, i don’t like non-abstract types here. what advantages does the existence of List, DIct, Set, and FrozenSet have? why not just use consistent abstract classes: in shell-expand: |
Remember that Python is pretty pragmatic. List has a sort() method, which MutableSequence does not (and should not) have. List+List works, while Sequence+Sequence doesn't. Etc. |
maybe we should add new mixin methods that address this?
alternatively, we could add new generic abstract classes that define the functionality not covered by the current ABCs, but not bound to concrete builtin types. |
Of course you could define Also, a mixin method for So, I think it's reasonable that methods should be able to specify concrete return types like |
I have a different worry here. Everyone seems to agree with this:
But every iteration of the proposal so far has left that out. If the docs don't recommend using abstract types for arguments in public interfaces, the concrete types will be an attractive nuisance; people will write functions that demand a And really, I think that's the core worry that flying-sheep has, even if he hasn't realized it yet. |
i understand your concerns except Another thing to do would be to specify something like
that’s my main worry as well. sorry for not saying that: |
This whole issue exists to remind us that the PEP should have some language encouraging abstract types over concrete types. (And for "that" a PR would be welcome.) However that doesn't mean we should not define concrete types. Nothing is gained if people decide to use |
See #48 for another angle to this issue. |
I've added some words to the PEP. Closing. |
In principle yes, in practice there are issues (long type names, strings and bytes being iterables and sequences).
The text was updated successfully, but these errors were encountered: