Author belopolsky
Recipients belopolsky, lemburg, loewis
Date 2009-01-07.15:49:53
SpamBayes Score 0.314144
Marked as misclassified No
Message-id <d38f5330901070749h44ae6b4bk18948db57b435156@mail.gmail.com>
In-reply-to <496476FD.6090906@v.loewis.de>
Content
On Wed, Jan 7, 2009 at 4:33 AM, Martin v. Löwis <report@bugs.python.org> wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> .. Furthermore, they all have names that are
> unlikely to collide. Even if they get a _Py_ prefix, there could
> still be a conflict.
>

My main interest in this patch are the type and %d to %zd change, but
by throwing in the name change, I unintentionally made it more
controversial.   Would it help if I resubmit the patch without name
changes or is this something that a committer can take care of if the
patch is partially accepted?

I already stated that I am only +0 on the name change and that "+" is
mostly motivated by the fact that I already made the changes in my
sandbox.   Other than that, I don't think it matters.   Let's stop
here and refocus the type change.

>> Even production builds contain a few such symbols which require
>> the _Py or Py prefix (or need to be made static) - these are for
>> Python 2.6 and 2.7:
>>
>> * asdl_int_seq_new
>> * asdl_seq_new
>
> No. They don't require the Py_ prefix, because they already
> have the asdl_ prefix.

That's true, but asdl_ prefix is not a well-known prefix reserved for
Python symbols.  Someone who is debugging linker errors and sees
something like "asdl_seq_new: symbol not found" will be hard pressed
to realize that he/she forgot to link python library or linked an old
version.

Also a grep through nm output that Marc-Andre did is a good check to
run from time to time and there is no reason to have false positives.
History
Date User Action Args
2009-01-07 15:49:55belopolskysetrecipients: + belopolsky, lemburg, loewis
2009-01-07 15:49:54belopolskylinkissue4850 messages
2009-01-07 15:49:53belopolskycreate