Any other Python flaws?

Isaac To kkto at csis.hku.hk
Sun Jun 17 03:14:34 EDT 2001


>>>>> "Michael" == Michael Chermside <mcherm at destiny.com> writes:

    Michael> Gee... I had no idea this was possible. Surely it's a bad
    Michael> idea... right?

I object.  Making it otherwise would make the language very inconsistent.

Consider this.  How often do you want to name a local variable as "len" in
Python?  How about "buffer" or "chr"?  Perhaps you never.  I do this
regularly, though.  I expect that if I don't need to use these built-in
names in a function, I can use the name in whatever way I'd like.

"None" is no different.  You are not assigning to the system "None", but
instead you're creating a new local variable called "None".  I don't know
why it has anything to do with the global None.

So you can have two different but consistent rules: allow assignments to
variables which have default built-in bindings, and ignore the issue
completely.  Python developers like the latter, and so do I.  Just think
about what will happen for the first choice.  Programmers have to remember
all the built-in names, other than the reserved words.  Once a new built-in
name is added, program can break.  If you embed Python to make an extended
interpretor, you'll have to think about whether you want to forbid changing
the new built-in names in that extension.  And then you get some
inconsistencies either way.  I don't like any of these ideas.

If you don't know there is a thing in Python called "None", and thus assign
something as the local value, chances are that your function simply don't
need the global None value, so that assignment is actually quite safe.

Regards,
Isaac.



More information about the Python-list mailing list