How to pass class instance to a method?

Discussion in 'Python' started by ALeX inSide, Nov 25, 2012.

  1. ALeX inSide

    ALeX inSide Guest

    How to "statically type" an instance of class that I pass to a method of other instance?

    I suppose there shall be some kind of method decorator to treat an argument as an instance of class?

    Generally it is needed so IDE (PyCharm) can auto-complete instance's methods and properties.

    Pseudo-python-code example:

    i = MyClass()

    xxx(i, 1, 2);

    ....
    def xxx(self, MyClass myclass, number, foobar):
    myclass.classsmethod() #myclass - is an instance of known class
    ALeX inSide, Nov 25, 2012
    #1
    1. Advertising

  2. On Sun, 25 Nov 2012 04:11:29 -0800, ALeX inSide wrote:

    > How to "statically type" an instance of class that I pass to a method of
    > other instance?


    Please explain what you mean by this.

    What do you think "statically type" means?


    > I suppose there shall be some kind of method decorator to treat an
    > argument as an instance of class?



    Python does not allow you to lie about the type of an argument. All
    objects are strongly typed. If an object is a Spam instance, it is a Spam
    instance, you can't pretend that it is a Cheese instance.[1]



    > Generally it is needed so IDE (PyCharm) can auto-complete instance's
    > methods and properties.
    >
    > Pseudo-python-code example:
    >
    > i = MyClass()
    >
    > xxx(i, 1, 2);
    >
    > ...
    > def xxx(self, MyClass myclass, number, foobar):
    > myclass.classsmethod() #myclass - is an instance of known class



    I do not understand what you are saying here. Please try to explain more
    carefully.






    [1] You cannot lie about the type of an instance, but sometimes you can
    actually change its type. Use this feature with care, since it rarely is
    useful.



    --
    Steven
    Steven D'Aprano, Nov 25, 2012
    #2
    1. Advertising

  3. ALeX inSide wrote:
    > I suppose there shall be some kind of method decorator to treat an argument as an
    > instance of class?


    You can do this:

    xxx = MyClass.some_method

    and then

    i = MyClass()
    xxx(i, foo, bar)

    Does that help?

    --
    Greg
    Gregory Ewing, Nov 25, 2012
    #3
  4. ALeX inSide <> writes:

    > How to "statically type" an instance of class that I pass to a method
    > of other instance?


    Python does not do static typing.

    > I suppose there shall be some kind of method decorator to treat an
    > argument as an instance of class?


    Decorators are an option. Another is the use of the new parameter
    annotations (param : expr) in function/method parameters. (That's python
    3, not 2).

    > Generally it is needed so IDE (PyCharm) can auto-complete instance's
    > methods and properties.


    You can't expect static info on the class of the object referenced by
    any name, unless you impose strong conventions on the code.

    > Pseudo-python-code example:
    >
    > i = MyClass()
    >
    > xxx(i, 1, 2);
    >
    > ...
    > def xxx(self, MyClass myclass, number, foobar):
    > myclass.classsmethod() #myclass - is an instance of known class


    Could: xxx(self,myclass : MyClass, ...)

    -- Alain.
    Alain Ketterlin, Nov 26, 2012
    #4
  5. ALeX inSide

    Nobody Guest

    On Sun, 25 Nov 2012 04:11:29 -0800, ALeX inSide wrote:

    > How to "statically type" an instance of class that I pass to a method of
    > other instance?


    Python isn't statically typed. You can explicitly check for a specific
    type with e.g.:

    if not isinstance(arg, SomeType):
    raise TypeError('expected SomeType but got %s' % type(arg))

    But this defeats duck typing. If you do this a lot, you're using the wrong
    language.

    > I suppose there shall be some kind of method decorator to treat an
    > argument as an instance of class?
    >
    > Generally it is needed so IDE (PyCharm) can auto-complete instance's
    > methods and properties.


    You have it backwards.

    In a dynamically-typed language such as Python, the set of acceptable
    types for an argument is determined by the operations which the function
    performs on it. This is in direct contrast to a statically-typed language,
    where the set of acceptable operations on an argument is determined by the
    type of the argument.
    Nobody, Nov 26, 2012
    #5
  6. ALeX inSide

    Ian Kelly Guest

    On Mon, Nov 26, 2012 at 9:56 AM, Nobody <> wrote:
    > In a dynamically-typed language such as Python, the set of acceptable
    > types for an argument is determined by the operations which the function
    > performs on it. This is in direct contrast to a statically-typed language,
    > where the set of acceptable operations on an argument is determined by the
    > type of the argument.


    Not how I would put it. In a statically typed language, types are
    checked at compile-time (which does not necessarily imply that useful
    type information can be made available to an IDE), whereas in a
    dynamically typed language, some or all type checking is deferred to
    run-time.

    The description that "the set of acceptable types for an argument is
    determined by the operations which the function performs on it" sounds
    to me more like type inference, as exemplified by Haskell, which is
    nonetheless a statically typed language.
    Ian Kelly, Nov 26, 2012
    #6
  7. ALeX inSide

    Dave Angel Guest

    On 11/26/2012 03:51 PM, Ian Kelly wrote:
    > On Mon, Nov 26, 2012 at 9:56 AM, Nobody <> wrote:
    >> In a dynamically-typed language such as Python, the set of acceptable
    >> types for an argument is determined by the operations which the function
    >> performs on it. This is in direct contrast to a statically-typed language,
    >> where the set of acceptable operations on an argument is determined by the
    >> type of the argument.

    > Not how I would put it. In a statically typed language, types are
    > checked at compile-time (which does not necessarily imply that useful
    > type information can be made available to an IDE), whereas in a
    > dynamically typed language, some or all type checking is deferred to
    > run-time.


    Not how I would put it. In a statically typed language, the valid types
    are directly implied by the function parameter declarations, while in a
    dynamic language, they're defined in the documentation, and only
    enforced (if at all) by the body of the function.


    --

    DaveA
    Dave Angel, Nov 26, 2012
    #7
  8. On Mon, 26 Nov 2012 16:58:47 -0500, Dave Angel wrote:

    > In a statically typed language, the valid types
    > are directly implied by the function parameter declarations, while in a
    > dynamic language, they're defined in the documentation, and only
    > enforced (if at all) by the body of the function.



    Well that certainly can't be true, because you can write functions
    without *any* documentation at all, and hence no defined type
    restrictions that could be enforced:

    def trivial_example(x):
    return x+1

    No documentation, and so by your definition above this should be weakly
    typed and operate on any type at all. Since there are no type
    restrictions defined, the body cannot enforce those type restrictions.
    But that's clearly not true.

    Please, everybody, before replying to this thread, please read this:

    http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/



    --
    Steven
    Steven D'Aprano, Nov 26, 2012
    #8
  9. ALeX inSide

    Ian Kelly Guest

    On Mon, Nov 26, 2012 at 2:58 PM, Dave Angel <> wrote:
    > Not how I would put it. In a statically typed language, the valid types
    > are directly implied by the function parameter declarations,


    As alluded to in my previous post, not all statically typed languages
    require parameter type declarations to perform static checking.

    > while in a
    > dynamic language, they're defined in the documentation, and only
    > enforced (if at all) by the body of the function.


    That's not even true for Python. The following example uses Python 2.x:

    >>> class Foo(object):

    .... def method(self):
    .... pass
    ....
    >>> Foo.method(4)

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: unbound method method() must be called with Foo instance as
    first argument (got int instance instead)

    That's a run-time check, and it's not enforced by the body of the function.
    Ian Kelly, Nov 26, 2012
    #9
  10. ALeX inSide

    Hans Mulder Guest

    On 27/11/12 00:07:10, Ian Kelly wrote:
    > On Mon, Nov 26, 2012 at 2:58 PM, Dave Angel <> wrote:
    >> Not how I would put it. In a statically typed language, the valid types
    >> are directly implied by the function parameter declarations,

    >
    > As alluded to in my previous post, not all statically typed languages
    > require parameter type declarations to perform static checking.
    >
    >> while in a
    >> dynamic language, they're defined in the documentation, and only
    >> enforced (if at all) by the body of the function.

    >
    > That's not even true for Python. The following example uses Python 2.x:
    >
    >>>> class Foo(object):

    > ... def method(self):
    > ... pass
    > ...
    >>>> Foo.method(4)

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > TypeError: unbound method method() must be called with Foo instance as
    > first argument (got int instance instead)
    >
    > That's a run-time check, and it's not enforced by the body of the function.


    As Ian already knows, this problem has been fixed in Python 3.

    -- HansM
    Hans Mulder, Nov 27, 2012
    #10
  11. ALeX inSide

    Drew Guest

    On Sunday, November 25, 2012 7:11:29 AM UTC-5, ALeX inSide wrote:
    > How to "statically type" an instance of class that I pass to a method of other instance?
    >
    >
    >
    > I suppose there shall be some kind of method decorator to treat an argument as an instance of class?
    >
    >
    >
    > Generally it is needed so IDE (PyCharm) can auto-complete instance's methods and properties.
    >
    >
    >
    > Pseudo-python-code example:
    >
    >
    >
    > i = MyClass()
    >
    >
    >
    > xxx(i, 1, 2);
    >
    >
    >
    > ...
    >
    > def xxx(self, MyClass myclass, number, foobar):
    >
    > myclass.classsmethod() #myclass - is an instance of known class


    I'm not sure I understand exactly what you sre asking. Python uses "ducktyping". As far as Python is concerned, you can pass in any class object and so long as it has the needed methods, it'll suffice ("If it walks like a duck and it quacks like a duck, then it is a duck."). The down side to that is that if you hand an object as an argument and the method you pass doesn't behave like the expected method class would, then bad things may happen at run time. It would be a bit of a hassle to check types to make surethings at least smell OK before execution goes possibly awry, but you are certainly free to write guard code that makes those sort of checks.

    My reply here is a bit different from the other replies I see so far. I worry that may mean I mis-understood your question. Has this been at all helpful an answer?
    Drew, Nov 27, 2012
    #11
  12. ALeX inSide

    Dave Angel Guest

    On 11/26/2012 06:07 PM, Ian Kelly wrote:
    > On Mon, Nov 26, 2012 at 2:58 PM, Dave Angel <> wrote:
    >> Not how I would put it. In a statically typed language, the valid types
    >> are directly implied by the function parameter declarations,

    > As alluded to in my previous post, not all statically typed languages
    > require parameter type declarations to perform static checking.
    >
    >> while in a
    >> dynamic language, they're defined in the documentation, and only
    >> enforced (if at all) by the body of the function.

    > That's not even true for Python. The following example uses Python 2.x:
    >
    >>>> class Foo(object):

    > ... def method(self):
    > ... pass
    > ...
    >>>> Foo.method(4)

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > TypeError: unbound method method() must be called with Foo instance as
    > first argument (got int instance instead)
    >
    > That's a run-time check, and it's not enforced by the body of the function.


    We were talking about function arguments. I don't know of any place
    where they get their types declared.

    --

    DaveA
    Dave Angel, Nov 27, 2012
    #12
  13. ALeX inSide

    Dave Angel Guest

    On 11/26/2012 05:18 PM, Steven D'Aprano wrote:
    > On Mon, 26 Nov 2012 16:58:47 -0500, Dave Angel wrote:
    >
    >> In a statically typed language, the valid types
    >> are directly implied by the function parameter declarations, while in a
    >> dynamic language, they're defined in the documentation, and only
    >> enforced (if at all) by the body of the function.

    >
    > Well that certainly can't be true, because you can write functions
    > without *any* documentation at all, and hence no defined type
    > restrictions that could be enforced:


    That's backwards. Any body should be a bug in that case. It doesn't
    matter what you pass to a function that is unspecified, it's behavior is
    undefined. Calling it is inherently illegal.

    >
    > def trivial_example(x):
    > return x+1
    >
    > No documentation, and so by your definition above this should be weakly
    > typed and operate on any type at all. Since there are no type
    > restrictions defined, the body cannot enforce those type restrictions.
    > But that's clearly not true.
    >
    > Please, everybody, before replying to this thread, please read this:
    >
    > http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/


    I read part of it, and it's more than I care to read tonight. It seems
    to be written by an anonymous person. By jumping around in his blog, I
    see a lot of interesting articles, but i haven't yet figured out who he
    is. Does he have a name? A degree, a job in computers, a reputation?





    --

    DaveA
    Dave Angel, Nov 27, 2012
    #13
  14. On Mon, 26 Nov 2012 22:14:59 -0500, Dave Angel wrote:

    > On 11/26/2012 05:18 PM, Steven D'Aprano wrote:
    >> On Mon, 26 Nov 2012 16:58:47 -0500, Dave Angel wrote:
    >>
    >>> In a statically typed language, the valid types are directly implied
    >>> by the function parameter declarations, while in a dynamic language,
    >>> they're defined in the documentation, and only enforced (if at all) by
    >>> the body of the function.

    >>
    >> Well that certainly can't be true, because you can write functions
    >> without *any* documentation at all, and hence no defined type
    >> restrictions that could be enforced:

    >
    > That's backwards. Any body should be a bug in that case. It doesn't
    > matter what you pass to a function that is unspecified, it's behavior is
    > undefined. Calling it is inherently illegal.


    Have you ever programmed before? *wink*

    Seriously, as much as we would like to have full documentation of every
    piece of code before it is written, such a thing is awfully heavyweight
    for all but the biggest projects.

    In practice, many functions never get documented at all, or only
    partially documented. Whether this is a good thing or not, it is a fact,
    and no mainstream language *requires* you to write documentation, nor is
    the documentation is used to determine runtime behaviour. If it did, it
    would be code, not documentation.

    In lightweight or agile software development methodologies ("Bingo!") or
    exploratory development, you often write the code before you know what it
    does, or even what you want it to do. E.g. I'll sometimes have a vague
    idea of what I want a function or method to do, and go through three or
    four iterations of writing code before it is stable enough to begin
    documenting it.

    Given the practical reality that documentation is often neglected, there
    is a school of thought that says that *code* is the One True source of
    information about what the code does, that documentation is at best a
    hint or at worst completely redundant. While I think that's a bit
    extreme, I can see the point. If function f() puts the cat on the mat,
    but is documented as putting the hat on the cat, how do you know whether
    the documentation is wrong or the code?


    [...]
    >> Please, everybody, before replying to this thread, please read this:
    >>
    >> http://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

    >
    > I read part of it, and it's more than I care to read tonight. It seems
    > to be written by an anonymous person. By jumping around in his blog, I
    > see a lot of interesting articles, but i haven't yet figured out who he
    > is. Does he have a name? A degree, a job in computers, a reputation?


    Does it matter? Surely what he says should stand or fail on its own
    merits, not by who he is.

    He has a name, although it seems to be hard to find on his current blog:
    Chris Smith. As for the rest, I don't know.



    --
    Steven
    Steven D'Aprano, Nov 27, 2012
    #14
  15. ALeX inSide

    Roy Smith Guest

    Steven D'Aprano <> wrote:
    > Given the practical reality that documentation is often neglected, there
    > is a school of thought that says that *code* is the One True source of
    > information about what the code does, that documentation is at best a
    > hint or at worst completely redundant.


    Yes, there is such a school. Those people are full of bovine excrement.

    > If function f() puts the cat on the mat, but is documented as putting
    > the hat on the cat, how do you know whether the documentation is
    > wrong or the code?


    Documentation should describe intent and interface. Yes, the code says
    what the code does. But, the interface description says what it's
    supposed to do. Can the docs be wrong? Of course they can. Usually
    because somebody changed the code and didn't bother to change the docs.

    My take on people who never document anything is that they're just plain
    lazy.

    Go ahead, ask me how I really feel about the topic :)
    Roy Smith, Nov 27, 2012
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. marekw2143
    Replies:
    3
    Views:
    1,351
    marekw2143
    Jul 25, 2009
  2. David Garamond
    Replies:
    5
    Views:
    225
    Ara.T.Howard
    Jun 8, 2004
  3. Raj Singh
    Replies:
    2
    Views:
    189
    Rick DeNatale
    May 29, 2008
  4. Greg Hauptmann
    Replies:
    9
    Views:
    233
    Loren Segal
    Jun 16, 2008
  5. Chuck Remes
    Replies:
    3
    Views:
    172
    hemant
    Aug 12, 2010
Loading...

Share This Page