[Python-3000] Warning for 2.6 and greater

Tue Jan 9 07:35:26 CET 2007

On 1/8/07, Anthony Baxter <anthony at interlink.com.au> wrote:
>> Do we also want to warn about use of sq_slice and sq_ass_slice with
> C-code objects? (And yes, my inner 12 year old still giggles about
> sq_ass_slice)

Sometimes it's nice to know you aren't alone. :-)
> My concern is that having to dive into the warnings code could cause
> terrible slowdowns in places that are heavily used. The major
> concern I have is dict.has_key() - a quick audit of a bunch of code
> shows that it's used heavily inside inner loops. This is mostly for
> 2.6 - this is the first time we're going to be (optionally) issuing
> these warnings, and it seems a little user-hostile to suddenly make
> their code suck. Checking for a single global C variable is going
> to add a very slight overhead (particularly compared to the method
> call cost). Making an additional call into the warnings code is
> going to be a lot heavier...

Sure, for really heavy places we can also use a static int (bool)
check. Not really sure of the best way to handle this. There was a
warning for apply() that was removed because it was too slow.
My general preference as a user is to have more warnings. My
preference as a maintainer is to have less.
> > It doesn't use the warnings mechanism (mostly because
> > it has to warn during parsing, when usually no python code is
> > running) so '-W tabs:ignore' doesn't work. Then again, maybe with
> > Neal's warning framework in C, we can make it work for the
> > parser, too. Would be luvly for SyntaxWarnings too :)
>> I'm not sure whether reimplementing warnings in C is going to add
> this - I guess we can ask Neal nicely to add this functionality. Hi
> Neal.

http://python.org/sf/1631171
I'll be gone for a few days, so probably won't get a chance to respond
until this weekend.
n