Importing variables non-deterministic?

Antoon Pardon antoon.pardon at rece.vub.ac.be
Mon Aug 19 10:55:46 EDT 2013


Op 19-08-13 14:33, Dave Angel schreef:
> Antoon Pardon wrote:
> 
>> Op 19-08-13 11:18, Chris Angelico schreef:
>     <snip>
>>> The issue
>>> was regarding imports, and it's perfectly safe to import a constant,
>>> even if the interpreter doesn't protect you from then being a total
>>> idiot and changing it.
>>
>> Python doesn't have constants, so you statement about importing a
>> constant doesn't make sense. The point is that python doesn't provide
>> the mechanism for protecting names against reassignments. So you
>> don't know whether the variable you think of as a constant is so
>> in reality. And this from a pure language definition point of view.
>> That you can use tools that make the interpreter no longer behave
>> as the language should, doesn't negate that.
>>
> 
> Who cares what the language "protects?"  I don't know any language
> whose protections can't be at least partially bypassed by clever
> foot-shooters.

So? A number of language designers seem to think it is still worth
while. And even as it may be possible to circumvent it, when we are
talking about whether a language has constants or not, we are
talking about this language feature. Whether you think this
feature is worth having or not, doesn't change that this is
what is meant when people talk about a language having constants
or not.

> In any case, we all know that Python doesn't protect
> constants, so we're free to use the word in a friendlier way.
> 
> A Python constant is what I use as a constant.

No it is not. It can be a project constant, but it is not a
python constant. As it turns out, python does have some constants
if the version is high enough, being True, False and None. So
for those values the python designers thought it valuable enough
to protect them against reassignment. Pity enough they chose a
way that didn't allow programmers to protect names they thought
important enough to do so too.


> I follow Pep-8 and make
> it all caps.  So in any library I write struct_global.y  would be a bug
> or a design flaw.

No it is not. People are not obligated to follow pep-8 in their
projects and not following pep-8 doesn't imply a design flaw.

> (And with a single character name like that, it
> wouldn't be global in any case.  Single character names are reserved
> for play code and for short loops)

So? What if it is play code. You still don't know whether this person
meant this variable in his play code to be used as a constant or not.

-- 
Antoon Pardon



More information about the Python-list mailing list