Const in python?

David Brown david at no.westcontrol.spam.com
Tue Mar 25 04:44:58 EST 2003


"Dave Brueck" <dave at pythonapocrypha.com> wrote in message
news:mailman.1048535019.5217.python-list at python.org...
> On Mon, 24 Mar 2003, Anand wrote:
>
> > Wouldn't it be a nice idea to have constants in Python?
>
> IMO, no. (BTW, this has come up many times before - check the Google
> archives).
>
> > I think when programmers intend some of the variables to be const, the
> > behavior shouldn't be allowed to be altered.
>
> When I intend a variable to be constant it is spelled
>
> LIKE_THIS
>
> otherwise it is spelled
>
> likeThis

There is just one little problem with ALL CAPS conventions - they look ugly,
like something written in FORTRAN or ancient ASSEMBLER (I write lots of
assembly code for various micros - and I never write in ALL CAPS).
Conventions that make code obvious are generally a good thing, but ALL CAPS
distracts the reader and changes the emphasis of the code, which is contrary
to the spirit of Python ("write once, read as often as you like", as
distinct from Perl's "write once, read never").

Assigning to constants should not really be a problem - after all, you don't
assign to variables unless you know what the variable is, and that the
assignment is correct in the program.  Why treat constants any other way?
In a language like C, using constant declarations can let the compiler
notify you of some silly mistakes, but in Python, the run-time typing and
binding means that you can make so many silly mistakes (it's the price you
pay for the power and flexibility) that assigning to constants is a minor
issue.


>
> This works very well in practice and I highly recommend it - no problems
> yet! :)
>
> > It would be nice to declare 'maxint' in sys to be a const rather than
> > allowing programmers to change the value and cause the program to fail
> > as a result of this change.
>
> I disagree. Assume you have a variable SOME_CONST. By it's spelling I can
> see that it is constant, so changing it is a no-no. Now, if I go and
> change it anyway, then one of these is probably true:
>
> #1 I know what I'm doing, and realize that changing it might be dangerous,
> but for some reason I need to change it anyway (e.g. I'm debugging a
> problem in a production system and changing this value will really help me
> out of a jam).
>
> #2 I am a sloppy programmer and lack the discipline to follow coding
> standards, good practicies, common conventions, etc.
>
> #3 I'm ignorant of the "all caps means constant" convention.
>
> If #1 is true, then not being able to change the "constant" is a real
> bummer, and really annoying. If #2 is true, then my sloppiness will be
> manifest in so many other areas that changing constants will be the least
> of my problems, and I'll weasle my way around all sorts of "best practice"
> fences you put up anyway. If #3 is true, it's trivial to educate me.
>
> At least in this respect (and I suppose others, like "private" members of
> classes), Python caters to the programmer in #1. Thank goodness it does
> not cater more towards the #2 programmer (something that would be
> especially annoying to the #1 type of programmers) it's no fun to be
> restricted because _somebody else_ is a bozo.
>
> -Dave
>






More information about the Python-list mailing list