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
