On 2007-01-16, klappnase <[EMAIL PROTECTED]> wrote:

>> Solutions:
>>
>>     a) convince Python developers to prefix ALL new (wrt. 2.5)
>>        global symbols with a prefix like "_PyAST_" or equivalent;
>>        this would be consistent with how it is done anyway,
>>        unfortunately the new AST symbols deviate from this practise
>>        (there are symbols like "Assert", "If", "Then", ...)
>>
>>  or b) apply an equivalent rule to the global symbols in
>>        tktreectrl that are global by accident, i.e. because
>>        of the way the library is structured and built
>>
>
> Anton, you're cool,

Well :) understanding this bug required a looong stare at the
gdb stacktrace and a short experiment with loading shared libraries
to verify my understanding with a simple example.

>
> actually renaming Ellipsis to Py_Ast_Ellipsis in ast.c and Python-ast.c
> seems to fix this.

Alternatively renaming Ellipsis to TkTc_Ellipsis in tktreectrl
works too;  that's what I did :)

> What I don't understand, isn't it very likely that such things will
> happen when names like "Ellipsis" or "Slice" and "Index" (which I also
> found in Python-ast.c) are being used, or are the treectrl people doing
> something they should avoid?

IMHO global symbols that do not actually have any use outside
the respective library should follow a naming convention that
minimizes the probablity of name clashes like this.  I.e. both
the new AST symbols in Python 2.5 and the global symbols in
tktreectrl should be prefixed appropriately.

> I think the answer to this might be important when deciding to whom I
> should send a bug report :)

The bug report should go to both;  I actually contacted Jeremy Hylton
as a main contributor of the new AST code two weeks ago but didn't
get any response.

Regards,
    Anton

PS
Thanks for your work on TkinterTreectrl!
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to