[Python-3000] Warning for 2.6 and greater

[Anthony Baxter]

On Monday 08 January 2007 22:53, Thomas Wouters wrote:
> (Also on my warn-TODO for 2.6 are coerce(), __get/set/delslice__

Should we warn on use of the __slice__ methods and the __cmp__ 
method, or hook into the object code to warn when they're defined?
I guess the latter would be more proactive. Or we could do both.

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)

On Tuesday 09 January 2007 00:08, Thomas Wouters wrote:
> Well, yes, that's why I want to add it to -W :) I mean to suggest
> that 'py3k' should just be a warning category. And not a special
> case.

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...

> Yes, I mean for the warnings for ``, tabmixing and input() to be
> enabled always, and the rest just when enabling py3k warnings.
> And yes, we'd need a way to turn the tabmix-warnings off; in the
> p3yk branch, I made '-t' and '-tt' be a no-op (since it errors by
> default), and introduces '-ttt' to turn tab-errors into warnings.

Why not -T for "suppress the errors"? 
So for 2.6, we'd make -t the default (and a single -t be a no-op).

> 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.

> > I'm not sure whether we should try and warn about 'print'
> > becoming a function. We should also consider things like
> > intern() and compile() (if they are to move to sys).
>
> For p3yk-warnings, we should warn about both, but I'm not sure
> about the usefulness of warning about print... there's no upgrade
> path, as such. At least not for all print's features.

There's also the problem that 
print ("hello world") 
is valid both for print-as-function and print-as-statement.

But let's leave print until 2.7. Hopefully by then we'll have some 
vague sense of an upgrade path, perhaps. 

> > Do we also want to add an option to promote these warnings to
> > actual errors? I think leaving that for 2.7 is a good idea...
>
> We have that: -W error :)

Well, yes, except that -W error would need some special magic to not 
just fall over on all Warnings. Maybe we could make it only raise 
for DeprecationWarnings. ("I break for DeprecationWarnings")

-- 
Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.