Assigning to True of False should raise at least a Py3K warning (maybe
something more severe?).

I would like to review the patch on this one.

I think it should limit itself to the True and False in builtin.  It
would be *very* expensive to check for every assignment in every
possible namespace.

On Mon, Mar 17, 2008 at 3:41 PM, Raymond Hettinger
<report@bugs.python.org> wrote:
>
>  Raymond Hettinger <rhettinger@users.sourceforge.net> added the comment:
>
>  I would like to review the patch on this one.
>
>  I think it should limit itself to the True and False in builtin.  It
>  would be *very* expensive to check for every assignment in every
>  possible namespace.
>

It shouldn't be expensive when the parser does the check (just like
with SyntaxError for None).

The parser approach should be fine.

I'm working on it.

This patch alters the parser to warn for assignment to True and False.
Enjoy!

Looks fine.  Please apply.

Sorry, I don't permission.

I'll apply when I get a chance.

This is a minor concern, but existing -3 warnings refer to python 3.0
and above as "3.x", not 'Py3K'.  It would be nice to preserve consistency.

"A Foolish Consistency is the Hobgoblin of Little Minds"
This update makes the warnings say 3.x.

Back to Brett for application.

Actually, the patch is incomplete. You can still do assignment through
things such as ``def True(): pass``. If you go through ast.c and find
the various places None is protected (search for \"None\" and note the
places where an ast_error() call is made) you should put the warnings there.

Wow! I never realized how many ways you could possibly assign to
something. I found all the None assignments and put the True/False ones
under it.

I just added on a test.

FWIW, I don't think it's important to catch every possible assignment. 
Add warnings for the common cases and declare victory.

Do you think we should remove some?

Keep what you've got but don't lose sleep if some offbeat case is not 
covered.

Brett, shall I apply?

If Raymond says it's fine, then it's also fine by me.

As I looked over the code again, I realized that it doesn't help to just
do a normal warning while compiling because the line number isn't
supplied. You have to use PyWarn_Explicit for that (see the warning
about backquotes). Since the filename (in the compiling struct) isn't
passed around to all ast helpers, you can't warn in every function.
Therefore, I have #2720.

Okay, now that #2720 was dealt with, here's another (close to final)
patch. I added an ast_warn help function. When -Werror is used, the
warnings are converted to SyntaxErrors. Raymond or Brett, if you could
take a look, that would be great. Thanks!

I'm attaching a new patch with changes made from the Georg's comments.

Georg, can I apply?

Hmm, I'd even go a step further and factor out the whole checking for
invalid/warnable names, like in Py3k's forbidden_name.

Also the warning text shouldn't start with uppercase and end in a full stop.

Here's a much better patch that delegates checking to a helper.

The macro at the top of the patch should be removed, then this can be
checked in.

Done in r64044.