On 1/8/07, Anthony Baxter <[EMAIL PROTECTED]> 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 _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
