GetChatList() in python returns wrong type.

If no connection available,
chatList = world.GetChatList()

returns wrong type:
Execution of line 1 column 0
Immediate execution
Traceback (most recent call last):
File "<Script Block 6>", line 1, in <module>
chatList = world.GetChatList()
TypeError: 'NoneType' object is not callable

NoneType isn't correct, it should be "None".

This might very well be another quirk in the Python <-> WSH bindings.

Are there any other functions in MUSHclient that ought to return 'None' at a certain point, and actually do that right?

I haven't tried that much tbh, but it seems wrong to return a type that python can't handle at all. There should be functions that returns nil or none, I'll try to see if I can find any.

There are quite a few functions that have that sort of code. For example:



This is used fairly extensively and doesn't seem to cause problems in VBscript. So it seems that Python is mapping a COleSafeArray with no elements to some unknown type. However the test is there because you can't create a zero-length array.

Does WSH support explicitly adding a NULL parameter, or something along those lines?

Maybe the fact you do not add any value is the reason Python interprets the return value as 'having no type', rather than 'a value'. VBScript might not have such a distinction, and thus map both to the same thing.

COM VARIANT types default to VT_EMPTY, and the VARIANT inside COleSafeArray is no exception. If you don't dimension the array before you detach it, it seems likely that Detach() would return VT_EMPTY, rather than VT_NULL.

I don't know which one is what we want, but maybe that will help.

According to the docs for COleSafeArray:


All of these constructors create new COleSafeArray objects. If there is no parameter, an empty COleSafeArray object is created (VT_EMPTY).


I don't see why I can't return an empty variant, as that is a well-defined variant type. It would be different if the variant type was some undefined random value, but VT_EMPTY is a documented value, and can be tested in VBscript.

Doing a Google for "TypeError: 'NoneType' object is not callable" seems to return quite a few results, nothing to do with MUSHclient.

My guess is that the empty variant returned by the call cannot be assigned to another variable (because it is empty?) and thus the error. If there was a way of testing for NoneType that might help.

I would guess that it depends solely on the script engine in question, and how it implements its WSH interface. WSH defines a language-agnostic API for users, but the engine implementors have to bind it to the specific scripting engine. If they do something wrong - like not handle VT_EMPTY values properly - it'll reflect in the engine's behavior.

Does VT_NULL work as expected?

I did some searching of my own, and it looks like NoneType is just the type that None is a [pseudo-]instance of. This is similar to Ruby, which has true, false, and nil, all instances of TrueClass, FalseClass, and NilClass respectively.

I expect that the error really isn't anything out of the ordinary, especially because if I run 'python' from the command line and type "None()", I get "TypeError: 'NoneType' object is not callable". In other words, world.GetChatList() is in fact returning None, and everything is as it should be.

[EDIT]: stupidly used "Null" when I meant "None". Fixed.

Look at the error and the line only, I get a totally different impression, but of course it all depends on the exact line in the WSH bindings where the error occurs.

My instinctive way to read the TypeError: 'NoneType' object is not callable error is that Python looks up the world object for a GetChatList attribute, is not able to find it and it returns NoneType instead of throwing an AttributeError as Python ought to do when trying to access attributes that do not exist. Then, due to the (), it tries to _call_ said NoneType, which gives the error you see.

Alternatively, the error is indeed in decoding the result from the GetChatList() call in the WSH bindings, meaning it does get executed but gives a really weird and cryptic error.

Can you try



and show the result?

Well, I'm confused. I set up a chat session so the call *would* return an array, and then did:



and got:




Well what is this: "'tuple' object is not callable"?

Who is calling it?

I'm pretty sure the method -does- exist, because it's on the world object, whether it's connected or not. I'm pretty sure that's guaranteed by the IDL that defines the world object's bound methods and attributes.

When it's called, it returns None. Calling a None value gives the error described. I can replicate this in non-WSH python: I have Python installed on my Ubuntu partition and doing this from the REPL has the same effect.

You're probably right, I must be overanalyzing the error message.

Either way, that _does_ remind me of something else which is likely at the very root of this issue.

Try leaving the () off, which basically signify a callable. Some functions like Connect that lack parameters have never needed the () in Python, whereas the moment they were needed, you had to put them in.

Basically, rather than calling the function when you treat it as a callable, it calls it when you try to access the attribute, which is very unpythonic and has disgusted me pretty much always. Only good part is that you pretty much never run into functions without parameters when dealing with scripting in MUSHclient, so you tend not to notice it. But the few times it is an issue, it is ugly.

So... try:



Probably that is the quirk the WSH bindings are pushing on us. In anything actually Python, that would be a totally wrong syntax. :/

(How much a good night worth of sleep can help when analyzing this stuff, heh.)

Actually, you're probably spot on. Somehow I managed to miss that my explanation of the issue would involve two calls, when there's only one set of ()'s. It would also explain Nick's problem with calling a tuple.

I was right and wrong, depending on how you read my post exactly. :) I wrote it while really sleepy, and while I meant it the wrong way, it ends up being written the way you get the 'correct' answer.

My most recent post is 100% correct though, pretty sure of that one. :)

It is all pretty much the same thing, there's just some odd stuff going on in the bindings where you'd not really expect it as a simple user.

Yeah, world.GetChatList in python is not a function. It's a variable. That's why it didn't work. I have encountered a few others like these.

Thanks for the help!