How to pass class instance to a method?

[ALeX inSide]

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

 

[Steven D'Aprano]

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.

 

[Gregory Ewing]

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?

 

[Alain Ketterlin]

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.

 

[Nobody]

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.

 

[Ian Kelly]

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.

 

[Dave Angel]

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.

 

[Steven D'Aprano]

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/

 

[Ian Kelly]

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:
.... def method(self):
.... pass
....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.

 

[Hans Mulder]

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


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

... def method(self):
... pass
...
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

 

[Drew]

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?

 

[Dave Angel]

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

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

... def method(self):
... pass
...
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.

 

[Dave Angel]

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?

 

[Steven D'Aprano]

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?


[...]

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.

 

[Roy Smith]

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