What is the type of a parameter that is an abstract class name in Python docstrings?
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
|
show 3 more comments
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
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 anobject
INSTANCE is not callable. Theobject
class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
– bruno desthuilliers
Dec 28 '18 at 13:08
|
show 3 more comments
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
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
python class types docstring
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 anobject
INSTANCE is not callable. Theobject
class IS - of course - callable. ALL classes are callable, that's how you instanciate them.
– bruno desthuilliers
Dec 28 '18 at 13:08
|
show 3 more comments
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 anobject
INSTANCE is not callable. Theobject
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
|
show 3 more comments
2 Answers
2
active
oldest
votes
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).
Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract classSuperFoo
, sotype
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 ofSuperFoo
, when it should really expect theSuperFoo
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: aSuperFoo 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
add a comment |
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)
This answer along with the my comment and bruno. Can explain this question properly.
– Aman Raparia
Dec 28 '18 at 11:02
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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).
Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract classSuperFoo
, sotype
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 ofSuperFoo
, when it should really expect theSuperFoo
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: aSuperFoo 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
add a comment |
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).
Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract classSuperFoo
, sotype
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 ofSuperFoo
, when it should really expect theSuperFoo
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: aSuperFoo 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
add a comment |
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).
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).
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 classSuperFoo
, sotype
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 ofSuperFoo
, when it should really expect theSuperFoo
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: aSuperFoo 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
add a comment |
Thanks for the clarifications. I edited the question to indicate that the parameter is a subclass of an abstract classSuperFoo
, sotype
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 ofSuperFoo
, when it should really expect theSuperFoo
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: aSuperFoo 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
add a comment |
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)
This answer along with the my comment and bruno. Can explain this question properly.
– Aman Raparia
Dec 28 '18 at 11:02
add a comment |
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)
This answer along with the my comment and bruno. Can explain this question properly.
– Aman Raparia
Dec 28 '18 at 11:02
add a comment |
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)
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)
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
add a comment |
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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
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. Theobject
class IS - of course - callable. ALL classes are callable, that's how you instanciate them.– bruno desthuilliers
Dec 28 '18 at 13:08