Timeline for How many types of polymorphism are there in the Python language?
Current License: CC BY-SA 3.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jun 16, 2020 at 10:01 | history | edited | CommunityBot |
Commonmark migration
|
|
| Nov 10, 2016 at 15:44 | history | edited | JimmyJames | CC BY-SA 3.0 |
typos, added clarifications
|
| Nov 9, 2016 at 20:35 | comment | added | JimmyJames |
@Pythonist The second parameter needs to be a classinfo object. See the docs.
|
|
| Nov 9, 2016 at 20:30 | comment | added | Pythonist | one confusion why you use "print isinstance(bar, type(foo))" when i am doing print isinstance(bar, foo) its giving error ? saying it should be type why its so? | |
| Nov 9, 2016 at 20:22 | comment | added | Pythonist | Glad i asked haha :D | |
| Nov 9, 2016 at 20:13 | comment | added | gardenhead | Glad it's informative. I use Python everyday but never really think about these issues as it "just works" most of the time. The wiki page specifically contrasts structural and duck-typing - they are similar, but not equal. Duck-typing can only be implemented in dynamic languages. As to static vs dynamic typing, that is a whole 'nother discussion / debate / flamewar. I get very fired up about the topic so I'm not sure if this is the best place to proselytize ;) | |
| Nov 9, 2016 at 20:02 | comment | added | JimmyJames | @gardenhead I appreciate the discussion. It has been informative and made me look at things a little differently. As far as "structural subtyping" goes, this wiki page and this wiki page suggest that duck typing is stuctural subtyping. I guess I don't see static and dynamic typing being so different. The difference seems, to me, to be about the constraints and their related costs and benefits. | |
| Nov 9, 2016 at 19:52 | history | edited | JimmyJames | CC BY-SA 3.0 |
added clarification based on discussion
|
| Nov 9, 2016 at 19:48 | comment | added | gardenhead | Thanks for that latest link; I think it was a pretty good overview and I mostly agree with what the author said. This discussion is honestly too subtle to be resolved through comments. The crux of the issue is that these terms, which are well-defined for static types, do not have an agreed-upon definition for dynamic types. Thus, we're all just making up our own slightly different definitions. For example, I know perfectly well what "structural subtyping" is in a static language, but how do we extend that to dynamic languages? | |
| Nov 9, 2016 at 19:34 | comment | added | JimmyJames | @gardenhead So I can buy that duck-typing is the primary form of subtyping in Python. I'll even agree it's preferable. But I don't see how you get from there to (what I think you are saying): Python doesn't have types or that subclasses are not subtypes. You said in your post that "subtype polymorphism are meaningless in the context of duck-typing" but it would seem now that your argument is that duck-typing is subtype inheritance if we agree that duck-typing is subtyping. | |
| Nov 9, 2016 at 19:24 | comment | added | JimmyJames | @gardenhead My link to the paper "Inheritance is subtyping" might have come off the wrong way, I linked to if because it contains the text "and reached a profoundly different conclusion: inheritance is not subtyping." Here's another reference that comes at it more from where you are sitting. I think makes the point that subclasses are inherently subtypes: "That's because duck typing, not subclassing, is the normal way to represent subtyping; inheritance is only one of three equally valid ways to implement subclassing;" | |
| Nov 9, 2016 at 19:23 | comment | added | gardenhead |
To be honest, I don't have enough understanding the the Python interpreter to be able to make sense of that post. But that's implementation anyway, so it shouldn't be relevant. I'll provide an example of what I mean. Let's say I have three classes: class A: foo = 1, class B(A), class C: foo = 2. So B inherits from A while C does not, but all three define member foo. If I have a function def do(a): a.foo. then I can pass an object of any of the three classes to do; it is allowed because of duck-typing. The fact that B inherits from A is irrelevant.
|
|
| Nov 9, 2016 at 19:10 | comment | added | JimmyJames | @gardenhead I'm not really sure I understand your point. While you can make the argument that not all subtypes are subject to inheritance, all subclasses are subtypes of their parent classes in Python as in most OO languages. See this page on type objects. The word "inherited by subtypes" appears 36 times. I'm not sure how to square this with what you are saying. | |
| Nov 9, 2016 at 18:53 | comment | added | gardenhead |
Yeah, I still disagree on subtype polymorphism. Don't confuse inheritance with subtyping; inheritance is a (bad) way to implement programs, subtyping is a way to extend the set of well-typed programs. Python surely has inheritance, and the isinstance built-in checks for inheritance, not subytping. I mean, taking a step back, these concepts are really only typically defined for statically-typed languages, but even if we extend the definition in some natural way to dynamically-typed languages, Python still doesn't fit the bill.
|
|
| Nov 9, 2016 at 18:31 | history | answered | JimmyJames | CC BY-SA 3.0 |