What is the type of a parameter that is an abstract class name in Python docstrings?












0














EDITED: Let's say I have some classes that inherit from the SuperFoo abstract class:



from abc import ABCMeta, abstractmethod

class SuperFoo(object):
__metaclass__ = ABCMeta

@abstractmethod
def do_something():
pass

class Foo(SuperFoo):
def __init__(self):
pass

def do_something():
pass

class Bar(SuperFoo):
def __init__(self):
pass

def do_something():
pass


And a documented function that takes in a subclass of SuperFoo as a parameter:



def build(super_foo):
"""
Instantiate a SuperFoo class and do some other stuff.
@param super_foo: The subclass whose constructor will be called
@type super_foo: ??? <--- What to use here?
@return: An instance of a SuperFoo subclass
@rtype: SuperFoo
"""
# Do some stuff

instance = class_name() # Instantiate class
return instance

foo = build(Foo)
bar = build(Bar)


What @type should I use in the function's docstring? It cannot be SuperFoo because that would correspond to an instance of SuperFoo and not to the type itself.










share|improve this question




















  • 1




    1) Everything is an object in Python. 2) Its type is literally just ... type.
    – meowgoesthedog
    Dec 28 '18 at 9:40








  • 1




    A name would be a string, e.g. "Foo". You're actually passing an object.
    – deceze
    Dec 28 '18 at 9:40










  • In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
    – Aman Raparia
    Dec 28 '18 at 9:56






  • 1




    It is not the class name itself. It is the class object itself.
    – juanpa.arrivillaga
    Dec 28 '18 at 10:14






  • 1




    @GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
    – bruno desthuilliers
    Dec 28 '18 at 13:08


















0














EDITED: Let's say I have some classes that inherit from the SuperFoo abstract class:



from abc import ABCMeta, abstractmethod

class SuperFoo(object):
__metaclass__ = ABCMeta

@abstractmethod
def do_something():
pass

class Foo(SuperFoo):
def __init__(self):
pass

def do_something():
pass

class Bar(SuperFoo):
def __init__(self):
pass

def do_something():
pass


And a documented function that takes in a subclass of SuperFoo as a parameter:



def build(super_foo):
"""
Instantiate a SuperFoo class and do some other stuff.
@param super_foo: The subclass whose constructor will be called
@type super_foo: ??? <--- What to use here?
@return: An instance of a SuperFoo subclass
@rtype: SuperFoo
"""
# Do some stuff

instance = class_name() # Instantiate class
return instance

foo = build(Foo)
bar = build(Bar)


What @type should I use in the function's docstring? It cannot be SuperFoo because that would correspond to an instance of SuperFoo and not to the type itself.










share|improve this question




















  • 1




    1) Everything is an object in Python. 2) Its type is literally just ... type.
    – meowgoesthedog
    Dec 28 '18 at 9:40








  • 1




    A name would be a string, e.g. "Foo". You're actually passing an object.
    – deceze
    Dec 28 '18 at 9:40










  • In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
    – Aman Raparia
    Dec 28 '18 at 9:56






  • 1




    It is not the class name itself. It is the class object itself.
    – juanpa.arrivillaga
    Dec 28 '18 at 10:14






  • 1




    @GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
    – bruno desthuilliers
    Dec 28 '18 at 13:08
















0












0








0







EDITED: Let's say I have some classes that inherit from the SuperFoo abstract class:



from abc import ABCMeta, abstractmethod

class SuperFoo(object):
__metaclass__ = ABCMeta

@abstractmethod
def do_something():
pass

class Foo(SuperFoo):
def __init__(self):
pass

def do_something():
pass

class Bar(SuperFoo):
def __init__(self):
pass

def do_something():
pass


And a documented function that takes in a subclass of SuperFoo as a parameter:



def build(super_foo):
"""
Instantiate a SuperFoo class and do some other stuff.
@param super_foo: The subclass whose constructor will be called
@type super_foo: ??? <--- What to use here?
@return: An instance of a SuperFoo subclass
@rtype: SuperFoo
"""
# Do some stuff

instance = class_name() # Instantiate class
return instance

foo = build(Foo)
bar = build(Bar)


What @type should I use in the function's docstring? It cannot be SuperFoo because that would correspond to an instance of SuperFoo and not to the type itself.










share|improve this question















EDITED: Let's say I have some classes that inherit from the SuperFoo abstract class:



from abc import ABCMeta, abstractmethod

class SuperFoo(object):
__metaclass__ = ABCMeta

@abstractmethod
def do_something():
pass

class Foo(SuperFoo):
def __init__(self):
pass

def do_something():
pass

class Bar(SuperFoo):
def __init__(self):
pass

def do_something():
pass


And a documented function that takes in a subclass of SuperFoo as a parameter:



def build(super_foo):
"""
Instantiate a SuperFoo class and do some other stuff.
@param super_foo: The subclass whose constructor will be called
@type super_foo: ??? <--- What to use here?
@return: An instance of a SuperFoo subclass
@rtype: SuperFoo
"""
# Do some stuff

instance = class_name() # Instantiate class
return instance

foo = build(Foo)
bar = build(Bar)


What @type should I use in the function's docstring? It cannot be SuperFoo because that would correspond to an instance of SuperFoo and not to the type itself.







python class types docstring






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Dec 28 '18 at 12:56







Gerardo Figueroa

















asked Dec 28 '18 at 9:38









Gerardo FigueroaGerardo Figueroa

312313




312313








  • 1




    1) Everything is an object in Python. 2) Its type is literally just ... type.
    – meowgoesthedog
    Dec 28 '18 at 9:40








  • 1




    A name would be a string, e.g. "Foo". You're actually passing an object.
    – deceze
    Dec 28 '18 at 9:40










  • In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
    – Aman Raparia
    Dec 28 '18 at 9:56






  • 1




    It is not the class name itself. It is the class object itself.
    – juanpa.arrivillaga
    Dec 28 '18 at 10:14






  • 1




    @GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
    – bruno desthuilliers
    Dec 28 '18 at 13:08
















  • 1




    1) Everything is an object in Python. 2) Its type is literally just ... type.
    – meowgoesthedog
    Dec 28 '18 at 9:40








  • 1




    A name would be a string, e.g. "Foo". You're actually passing an object.
    – deceze
    Dec 28 '18 at 9:40










  • In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
    – Aman Raparia
    Dec 28 '18 at 9:56






  • 1




    It is not the class name itself. It is the class object itself.
    – juanpa.arrivillaga
    Dec 28 '18 at 10:14






  • 1




    @GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
    – bruno desthuilliers
    Dec 28 '18 at 13:08










1




1




1) Everything is an object in Python. 2) Its type is literally just ... type.
– meowgoesthedog
Dec 28 '18 at 9:40






1) Everything is an object in Python. 2) Its type is literally just ... type.
– meowgoesthedog
Dec 28 '18 at 9:40






1




1




A name would be a string, e.g. "Foo". You're actually passing an object.
– deceze
Dec 28 '18 at 9:40




A name would be a string, e.g. "Foo". You're actually passing an object.
– deceze
Dec 28 '18 at 9:40












In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
– Aman Raparia
Dec 28 '18 at 9:56




In python everything is an object. That being said when we write a Class in your example Foo, then all the class in python inherit the Meta Class type. @type means that the class you are passing should be class which inherit the Meta Class type. To check this behaviour try to run type(Foo) >>> <class 'type'>. I hope I was able to explain your problem
– Aman Raparia
Dec 28 '18 at 9:56




1




1




It is not the class name itself. It is the class object itself.
– juanpa.arrivillaga
Dec 28 '18 at 10:14




It is not the class name itself. It is the class object itself.
– juanpa.arrivillaga
Dec 28 '18 at 10:14




1




1




@GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
– bruno desthuilliers
Dec 28 '18 at 13:08






@GerardoFigueroa an object INSTANCE is not callable. The object class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
– bruno desthuilliers
Dec 28 '18 at 13:08














2 Answers
2






active

oldest

votes


















3














The simple technical answer has already been posted by motyzk - in your example, what you pass to build are classes so the the (ill-named) class_name param is of type type - with the restriction that (based on your code snippet) this class shouldn't expect any parameter, which doesn't correspond to any unambigous well-defined existing builtin "type".



Now as mentionned in comments, in Python




  • everything is an object (and as such an instance of a class),

  • instanciating a class is done by calling the class object just like you'd call any function,

  • all callables DO return an object, even if implicitely (None is an object too)


so your build function would technically work just the same with just any callable that doesn't expect a param. As an example, this:



def bar():
return

whatever = build(bar)


is technically correct.



Now you mention in the function's docstring (emphasis is mine):




Instantiate a class and do some other stuff




Since your function would just be totally useless as shown in the snippet you posted, I assume that in your real code the important part is in the (not shown) "do some other stuff", and that this "do some other stuff" part relies on some specific property of the class being passed.



In this case, you should document those specificities, either informally (textually, in the docstring itself) or formally using the abc module. This won't solve your question actually - your function expects a class, not instance, so theoritically @type should be type(YourABC), but then what you get is abc.ABCMeta. At this point, you either have to write a custom metaclass (inherithing from abc.ABCMeta) and specify it as the proper @type - but this won't say anything useful as far as documentation is concerned - or just textually describe it as "a MyABC subclass" (which is the correct description but not usable for code instrumentation).






share|improve this answer























  • Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
    – Gerardo Figueroa
    Dec 28 '18 at 12:58










  • @GerardoFigueroa cf my edited answer.
    – bruno desthuilliers
    Dec 28 '18 at 13:08






  • 1




    But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
    – Gerardo Figueroa
    Dec 28 '18 at 13:15










  • Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
    – bruno desthuilliers
    Dec 28 '18 at 14:02










  • I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
    – bruno desthuilliers
    Dec 28 '18 at 14:16



















2














The type is "type", as can be seen, running this:



class Foo(object):
def __init__(self):
pass


def f(t):
print(type(t)) # <class 'type'>

f(Foo)





share|improve this answer























  • This answer along with the my comment and bruno. Can explain this question properly.
    – Aman Raparia
    Dec 28 '18 at 11:02











Your Answer






StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");

StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53956402%2fwhat-is-the-type-of-a-parameter-that-is-an-abstract-class-name-in-python-docstri%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes









3














The simple technical answer has already been posted by motyzk - in your example, what you pass to build are classes so the the (ill-named) class_name param is of type type - with the restriction that (based on your code snippet) this class shouldn't expect any parameter, which doesn't correspond to any unambigous well-defined existing builtin "type".



Now as mentionned in comments, in Python




  • everything is an object (and as such an instance of a class),

  • instanciating a class is done by calling the class object just like you'd call any function,

  • all callables DO return an object, even if implicitely (None is an object too)


so your build function would technically work just the same with just any callable that doesn't expect a param. As an example, this:



def bar():
return

whatever = build(bar)


is technically correct.



Now you mention in the function's docstring (emphasis is mine):




Instantiate a class and do some other stuff




Since your function would just be totally useless as shown in the snippet you posted, I assume that in your real code the important part is in the (not shown) "do some other stuff", and that this "do some other stuff" part relies on some specific property of the class being passed.



In this case, you should document those specificities, either informally (textually, in the docstring itself) or formally using the abc module. This won't solve your question actually - your function expects a class, not instance, so theoritically @type should be type(YourABC), but then what you get is abc.ABCMeta. At this point, you either have to write a custom metaclass (inherithing from abc.ABCMeta) and specify it as the proper @type - but this won't say anything useful as far as documentation is concerned - or just textually describe it as "a MyABC subclass" (which is the correct description but not usable for code instrumentation).






share|improve this answer























  • Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
    – Gerardo Figueroa
    Dec 28 '18 at 12:58










  • @GerardoFigueroa cf my edited answer.
    – bruno desthuilliers
    Dec 28 '18 at 13:08






  • 1




    But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
    – Gerardo Figueroa
    Dec 28 '18 at 13:15










  • Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
    – bruno desthuilliers
    Dec 28 '18 at 14:02










  • I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
    – bruno desthuilliers
    Dec 28 '18 at 14:16
















3














The simple technical answer has already been posted by motyzk - in your example, what you pass to build are classes so the the (ill-named) class_name param is of type type - with the restriction that (based on your code snippet) this class shouldn't expect any parameter, which doesn't correspond to any unambigous well-defined existing builtin "type".



Now as mentionned in comments, in Python




  • everything is an object (and as such an instance of a class),

  • instanciating a class is done by calling the class object just like you'd call any function,

  • all callables DO return an object, even if implicitely (None is an object too)


so your build function would technically work just the same with just any callable that doesn't expect a param. As an example, this:



def bar():
return

whatever = build(bar)


is technically correct.



Now you mention in the function's docstring (emphasis is mine):




Instantiate a class and do some other stuff




Since your function would just be totally useless as shown in the snippet you posted, I assume that in your real code the important part is in the (not shown) "do some other stuff", and that this "do some other stuff" part relies on some specific property of the class being passed.



In this case, you should document those specificities, either informally (textually, in the docstring itself) or formally using the abc module. This won't solve your question actually - your function expects a class, not instance, so theoritically @type should be type(YourABC), but then what you get is abc.ABCMeta. At this point, you either have to write a custom metaclass (inherithing from abc.ABCMeta) and specify it as the proper @type - but this won't say anything useful as far as documentation is concerned - or just textually describe it as "a MyABC subclass" (which is the correct description but not usable for code instrumentation).






share|improve this answer























  • Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
    – Gerardo Figueroa
    Dec 28 '18 at 12:58










  • @GerardoFigueroa cf my edited answer.
    – bruno desthuilliers
    Dec 28 '18 at 13:08






  • 1




    But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
    – Gerardo Figueroa
    Dec 28 '18 at 13:15










  • Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
    – bruno desthuilliers
    Dec 28 '18 at 14:02










  • I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
    – bruno desthuilliers
    Dec 28 '18 at 14:16














3












3








3






The simple technical answer has already been posted by motyzk - in your example, what you pass to build are classes so the the (ill-named) class_name param is of type type - with the restriction that (based on your code snippet) this class shouldn't expect any parameter, which doesn't correspond to any unambigous well-defined existing builtin "type".



Now as mentionned in comments, in Python




  • everything is an object (and as such an instance of a class),

  • instanciating a class is done by calling the class object just like you'd call any function,

  • all callables DO return an object, even if implicitely (None is an object too)


so your build function would technically work just the same with just any callable that doesn't expect a param. As an example, this:



def bar():
return

whatever = build(bar)


is technically correct.



Now you mention in the function's docstring (emphasis is mine):




Instantiate a class and do some other stuff




Since your function would just be totally useless as shown in the snippet you posted, I assume that in your real code the important part is in the (not shown) "do some other stuff", and that this "do some other stuff" part relies on some specific property of the class being passed.



In this case, you should document those specificities, either informally (textually, in the docstring itself) or formally using the abc module. This won't solve your question actually - your function expects a class, not instance, so theoritically @type should be type(YourABC), but then what you get is abc.ABCMeta. At this point, you either have to write a custom metaclass (inherithing from abc.ABCMeta) and specify it as the proper @type - but this won't say anything useful as far as documentation is concerned - or just textually describe it as "a MyABC subclass" (which is the correct description but not usable for code instrumentation).






share|improve this answer














The simple technical answer has already been posted by motyzk - in your example, what you pass to build are classes so the the (ill-named) class_name param is of type type - with the restriction that (based on your code snippet) this class shouldn't expect any parameter, which doesn't correspond to any unambigous well-defined existing builtin "type".



Now as mentionned in comments, in Python




  • everything is an object (and as such an instance of a class),

  • instanciating a class is done by calling the class object just like you'd call any function,

  • all callables DO return an object, even if implicitely (None is an object too)


so your build function would technically work just the same with just any callable that doesn't expect a param. As an example, this:



def bar():
return

whatever = build(bar)


is technically correct.



Now you mention in the function's docstring (emphasis is mine):




Instantiate a class and do some other stuff




Since your function would just be totally useless as shown in the snippet you posted, I assume that in your real code the important part is in the (not shown) "do some other stuff", and that this "do some other stuff" part relies on some specific property of the class being passed.



In this case, you should document those specificities, either informally (textually, in the docstring itself) or formally using the abc module. This won't solve your question actually - your function expects a class, not instance, so theoritically @type should be type(YourABC), but then what you get is abc.ABCMeta. At this point, you either have to write a custom metaclass (inherithing from abc.ABCMeta) and specify it as the proper @type - but this won't say anything useful as far as documentation is concerned - or just textually describe it as "a MyABC subclass" (which is the correct description but not usable for code instrumentation).







share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 28 '18 at 14:12

























answered Dec 28 '18 at 10:51









bruno desthuilliersbruno desthuilliers

48.4k54263




48.4k54263












  • Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
    – Gerardo Figueroa
    Dec 28 '18 at 12:58










  • @GerardoFigueroa cf my edited answer.
    – bruno desthuilliers
    Dec 28 '18 at 13:08






  • 1




    But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
    – Gerardo Figueroa
    Dec 28 '18 at 13:15










  • Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
    – bruno desthuilliers
    Dec 28 '18 at 14:02










  • I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
    – bruno desthuilliers
    Dec 28 '18 at 14:16


















  • Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
    – Gerardo Figueroa
    Dec 28 '18 at 12:58










  • @GerardoFigueroa cf my edited answer.
    – bruno desthuilliers
    Dec 28 '18 at 13:08






  • 1




    But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
    – Gerardo Figueroa
    Dec 28 '18 at 13:15










  • Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
    – bruno desthuilliers
    Dec 28 '18 at 14:02










  • I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
    – bruno desthuilliers
    Dec 28 '18 at 14:16
















Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
– Gerardo Figueroa
Dec 28 '18 at 12:58




Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract class SuperFoo, so type would be too broad here.
– Gerardo Figueroa
Dec 28 '18 at 12:58












@GerardoFigueroa cf my edited answer.
– bruno desthuilliers
Dec 28 '18 at 13:08




@GerardoFigueroa cf my edited answer.
– bruno desthuilliers
Dec 28 '18 at 13:08




1




1




But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
– Gerardo Figueroa
Dec 28 '18 at 13:15




But if I do @type super_foo: SuperFoo the function would expect an instance of SuperFoo, when it should really expect the SuperFoo type. The IDE complains as well.
– Gerardo Figueroa
Dec 28 '18 at 13:15












Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
– bruno desthuilliers
Dec 28 '18 at 14:02




Duh - you're right of course - what the function expects is a SuperFoo subclass, not a SuperFoo instance, my bad (time for a coffee I think <g>).
– bruno desthuilliers
Dec 28 '18 at 14:02












I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
– bruno desthuilliers
Dec 28 '18 at 14:16




I edited my answer again. I'm sorry to have to say that I can't think of any formal unambiguous answer here... OTHO if it's only for documentation, just stating "@type: a SuperFoo subclass is more than enough. Python is a dynamic language and has used "implied interfaces" (ie "a file-like object" or "a dict-like object" for decades, so "A SuperFoo subclass" is rather more explicit than what you'll find in most docs.
– bruno desthuilliers
Dec 28 '18 at 14:16













2














The type is "type", as can be seen, running this:



class Foo(object):
def __init__(self):
pass


def f(t):
print(type(t)) # <class 'type'>

f(Foo)





share|improve this answer























  • This answer along with the my comment and bruno. Can explain this question properly.
    – Aman Raparia
    Dec 28 '18 at 11:02
















2














The type is "type", as can be seen, running this:



class Foo(object):
def __init__(self):
pass


def f(t):
print(type(t)) # <class 'type'>

f(Foo)





share|improve this answer























  • This answer along with the my comment and bruno. Can explain this question properly.
    – Aman Raparia
    Dec 28 '18 at 11:02














2












2








2






The type is "type", as can be seen, running this:



class Foo(object):
def __init__(self):
pass


def f(t):
print(type(t)) # <class 'type'>

f(Foo)





share|improve this answer














The type is "type", as can be seen, running this:



class Foo(object):
def __init__(self):
pass


def f(t):
print(type(t)) # <class 'type'>

f(Foo)






share|improve this answer














share|improve this answer



share|improve this answer








edited Dec 28 '18 at 10:13

























answered Dec 28 '18 at 10:07









motyzkmotyzk

1844




1844












  • This answer along with the my comment and bruno. Can explain this question properly.
    – Aman Raparia
    Dec 28 '18 at 11:02


















  • This answer along with the my comment and bruno. Can explain this question properly.
    – Aman Raparia
    Dec 28 '18 at 11:02
















This answer along with the my comment and bruno. Can explain this question properly.
– Aman Raparia
Dec 28 '18 at 11:02




This answer along with the my comment and bruno. Can explain this question properly.
– Aman Raparia
Dec 28 '18 at 11:02


















draft saved

draft discarded




















































Thanks for contributing an answer to Stack Overflow!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53956402%2fwhat-is-the-type-of-a-parameter-that-is-an-abstract-class-name-in-python-docstri%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Monofisismo

Angular Downloading a file using contenturl with Basic Authentication

Olmecas