Comments (12)
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. MutableSequence
, for example, has a smaller interface than list
, so this is a non-trivial issue. Since MutableSequence
does not define __add__
, if a function returns a MutableSequence
, the return value cannot be concatenated to a list. Thus if I write a function that always returns a list, I'd probably declare the return type as a list to enable concatenation (and other list-specific operations).
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.
from typing.
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). __add__
in lists is a good example to show how this might be an issue. Can mypy discover this? If not, we might want to warn about this subtlety.
from typing.
Łukasz, I think you can close this issue once you add a sentence to the PEP text.
from typing.
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: {Mutable,}{Sequence,Mapping,Set}
from typing.
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.
from typing.
maybe we should add new mixin methods that address this?
Sequence
could define __add__
, and MutableSequence
could define sort
(should be no problem as it already does define reverse
)
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.
from typing.
[1] + (2, 3)
is a TypeError
. I don't think you're suggesting to change that. (Otherwise, ['abc'] + 'def'
would succeed, presumably returning ['abc', 'd', 'e', 'f']
, and I doubt you want that?)
Of course you could define Sequence.__add__
requires the other
parameter to be covariant with self
instead of contravariant (although I don't think there's any way to write that in the current syntax, but it's actually a general problem with __add__
and other operator methods that are effectively multiple dispatch…). But that still wouldn't help. If a user writes f() + [1, 2]
, and f
is only defined to return MutableSequence
instead of list
, it will fail the check.
Also, a mixin method for sort
would be a pretty ugly thing, because anyone calling x.sort()
is presumably expecting an in-place sort, but the only way MutableSequence.sort
could be implemented i something like self[:] = sorted(self)
.
So, I think it's reasonable that methods should be able to specify concrete return types like list
, or List[int]
.
from typing.
I have a different worry here.
Everyone seems to agree with this:
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.
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 List
when they really only need a Sequence
or Iterable
.
And really, I think that's the core worry that flying-sheep has, even if he hasn't realized it yet.
from typing.
[1] + (2, 3)
is aTypeError
i understand your concerns except MutableSequence.sort
. As said: MutableSequence.reverse
exists, and i don’t see a difference here. both modify the sequence by changing the order of its elements.
Another thing to do would be to specify something like ConcatenableSequence[Self]
or ConcatenableSequence[Sequence]
, where Self
would mean “the concrete type of this sequence”. problem here is that noone will use this, and therefore the linter will warn everyone who uses +
with a method return value, even if that return value is a buitin list
.
I have a different worry here…
that’s my main worry as well. sorry for not saying that: List
is of course useful for local variables, and returning a List
is also fine for things like the mentioned __add__
concatenation, but list sucks for function arguments, as they will almost always only expect a Sequence
or at most a MutableSequence
.
from typing.
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 Any
or plain list
because they can't write List[AnyStr]
.
from typing.
See #48 for another angle to this issue.
from typing.
I've added some words to the PEP. Closing.
from typing.
Related Issues (20)
- Out-of-date description of how to indicate positional-only parameters
- Typing spec should be clearer that type checkers are not expected to support PEP 3141 HOT 22
- Incorporate PEP 483 into the spec HOT 5
- Conformance tests: Add mechanism to allow errors on one of multiple lines HOT 2
- Conformance tests: Add mechanism to ignore errors
- Conformance tests: Align automated and manual scoring HOT 1
- Introduce a `Language` type to provide consistent language information of strings. HOT 5
- Spec: Version and platform checking underspecified HOT 6
- Support list comprehension for `TypeVarTuple` HOT 2
- Clarify the float/int/complex special case HOT 5
- Clarify the implications of subclassing Any HOT 1
- Allow multiple `TypeVarTuple` in Generic Classes when they are wrapped. HOT 5
- pytype conformance tests crash if no `python3.11` executable is in `PATH` HOT 5
- Conformance test: make dataclass_hash.py not rely on `typing.Hashable`? HOT 1
- Proposal: Add coerced type narrowing similar to 'cast' HOT 1
- Idenity Type HOT 2
- [spec] clarify assert_type behavior as asserting type equivalence
- [spec] better clarify the difference between a runtime type object and a static type HOT 1
- [spec] a protocol type should be assignable to object? HOT 1
- [spec] define or replace the term "concrete type" HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typing.