Re: zed: When will the new PI be done?

[Gustavo Niemeyer <niemeyer@conectiva.com>]

> I don't know if I like this idea. Why not just make xchat.get_info(ph, id)
> available under python? Trying to make all these objects like User,
> Channel etc, seems like too much work for little effect. 

Peter, we're talking about lists, right? xchat.get_info() is already
available under python. Also, there won't be a specific object for each
list. It will be a dynamic type, handling any kind of list. That's why
I really need a function to get the field name and type list. Again, if
you need help because you're busy, I can provide it.

> Can fields of a class/object be dynamic anyway? What if someone does
> user.abc (abc being a new field added later) on an older version of
> xchat? Under the C-plugin interface, it'd just return NULL and no
> problem, but wouldn't python throw an error?

No doubts. Python is a highly dynamic language. You may test for an
attribute with hasattr(user, "abc"), or just access it using user.abc in
a try block, and catch an AttributeError exception.

> > PS. The documentation mentions dcc->context list attribute as being
> > a string. This should probably be a long, given the data nature.
> 
> dcc->context? Where do you see that?

Sorry, you're right. It was channel->context

> If you mean "channels"->context, it's really a (void *) just like all
> xchat_get_context, xchat_find_context etc. So returning it as (char *) is good
> enough, while returning it as an int could fail on 64-bit machines. Don't
> think of it as a string, it's more like:
[...]

Please, notice I've suggested a "long", not an "int". But the way it is
returned is not important. The real problem is classifying it as a
string. A C string is '\0' terminated. Calling it a string may suggest
to high level interfaces that it should be accessed as a real string,
and crash the application.

OTOH, I realize this specific parameter will probably need special
handling anyway, since it's a context pointer. So, if you really want
to call it a string, it's not going to be a problem for me.

------

As a side note, I'd like to share my enthusiasm. Yesterday I've worked
in the thread support. It's working perfectly! This means one will be
able to use the native python threading support just like if it was a
real interpreter. Each module, and the interactive interpreter as well,
has it's own interpreter state, so one may have multiple threads running
for each loaded module, and in the interactive interpreter. The
interactive console is already working. Any text typed into a
">>python<<" query (which may be conveniently opened by a "/py console"
command) will be considered a python command, and will be processed by
the interactive interpreter in its own environment. Running something
like "/py exec <python statement>" is another way of talking to the
interactive interpreter.  Unloading of individual modules is working
just fine, including unhooking of callbacks for that specific module.

I'll let you all know of future enhancements!

-- 
Gustavo Niemeyer

[ 2AAC 7928 0FBF 0299 5EB5  60E2 2253 B29A 6664 3A0C ]
--
XChat-discuss: mailing list for XChat users
Archive:       http://mail.nl.linux.org/xchat-discuss/