[PEP 483] I think that 'being a subtype of' in this PEP are wrong

Typing
1

I’ve just read PEP-483 and I found this:

Subtype relationships

(…)
By this definition:

  • (…)
  • The set of values becomes smaller in the process of subtyping, while the set of functions becomes larger.

It seems like if the author(s) thought that if we do class Derive(Base): then the numbers of all possible instances of Derive is smaller than Base. Later we read:

An intuitive example: Every Dog is an Animal, also Dog has more functions, for example it can bark, therefore Dog is a subtype of Animal.

Well…it is clear that dogs are a kind of animal, so the set of all dogs is smaller than the set of all animals. But this doesn’t work the same with a computer’s objects.

Consider this:

class Vector2D:
     x: int
     y: int

class Vector3D(Vector2D):
     z: int

According to the “the set of functions becomes larger” part of the sentence, Vector3D has more functions than Vector2D: it can get/set the z field (this can be considered a ‘function’ of sort…). HOWEVER the set of all possible values of Vector3D is bigger than the set of Vector2D values: 2D vector has got all_values_of_int ^ 2 while 3D vector has all_values_of_int ^ 3. It thus violates the “The set of values becomes smaller” part.

Therefore, according of that way of thought Vector3D is not a subtype of Vector2D, which is not only counter-intuitive but it is impossible to find any static type checker that would say the same.

Am I right?

2

This is incorrect. Every instance of Vector3D is also an instance of Vector2D, and some instances of Vector2D are not instances of Vector3D, so the set of instances of Vector2D is indeed a superset of the set of instances of Vector3D.

2 Likes
3

OK so adding fields to a derived class makes its set of values smaller than its base class? :thinking:

*facepalm* OK, I get it! :blush: Silly me… :sweat_smile: