Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #52628 > unrolled thread

Importing variables non-deterministic?

Back to article view | Back to comp.lang.python

Contents

  Importing variables non-deterministic? tmellman@googlemail.com - 2013-08-17 07:25 -0700
    Re: Importing variables non-deterministic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-17 15:01 +0000
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 09:14 +0200
      Re: Importing variables non-deterministic? Dave Angel <davea@davea.name> - 2013-08-19 07:45 +0000
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 10:16 +0200
        Re: Importing variables non-deterministic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-19 16:57 +0000
          Re: Importing variables non-deterministic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-19 17:16 +0000
            Re: Importing variables non-deterministic? Chris Angelico <rosuav@gmail.com> - 2013-08-19 18:25 +0100
          Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 19:40 +0200
      Re: Importing variables non-deterministic? Chris Angelico <rosuav@gmail.com> - 2013-08-19 09:32 +0100
        Re: Importing variables non-deterministic? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-08-19 17:05 +0000
          Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 22:34 +0200
            Re: Importing variables non-deterministic? Steven D'Aprano <steve@pearwood.info> - 2013-08-20 05:48 +0000
              Re: Importing variables non-deterministic? wxjmfauth@gmail.com - 2013-08-19 23:40 -0700
              Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-20 08:55 +0200
                Re: Importing variables non-deterministic? wxjmfauth@gmail.com - 2013-08-20 00:31 -0700
                  Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-20 09:55 +0200
                    Re: Importing variables non-deterministic? wxjmfauth@gmail.com - 2013-08-20 02:15 -0700
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 11:03 +0200
      Re: Importing variables non-deterministic? Chris Angelico <rosuav@gmail.com> - 2013-08-19 10:18 +0100
      Re: Importing variables non-deterministic? Peter Otten <__peter__@web.de> - 2013-08-19 11:49 +0200
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 13:54 +0200
      Re: Importing variables non-deterministic? Dave Angel <davea@davea.name> - 2013-08-19 12:33 +0000
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 16:55 +0200
      Re: Importing variables non-deterministic? Chris Angelico <rosuav@gmail.com> - 2013-08-19 16:04 +0100
      Re: Importing variables non-deterministic? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2013-08-19 19:25 +0200
      Re: Importing variables non-deterministic? Ben Finney <ben+python@benfinney.id.au> - 2013-08-20 11:14 +1000

Page 2 of 2 — ← Prev page 1 [2]

#52682

Chris Angelico wrote:

> On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> This is irrelevant. That some context defines a constant, and that you
>> can use a variable with the same name as a constant in python, doesn't
>> contradict the statement that python (as a language) doesn't has
>> constants. There is nothing in the language that would prevent buggy
>> code from changing any of those variables. So from a python point of
>> views these are just global variables. Just as the struct_global.y was
>> in the original contribution.
> 
> And there's nothing preventing a program from using ctypes to
> overwrite an object's refcount, thus causing a segfault. So? 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.

Come on, breaking a "gentlemen's agreement" by rebinding a name and using 
ctypes to manipulate the internal state of the cpython imlementation are 
very different things. If that proves anything I'll best you with a Python 
script that controls a robot which in turn destroys the computer running the 
script with a hammer ;)

If Antoon's point is that global "constants" in Python are only constants 
because the programmer thinks of them that way I'd say that's an important 
addition to put Steve's "global variables are considered harmful" into 
perspective.

[toc] | [prev] | [next] | [standalone]

#52687

Op 19-08-13 11:18, Chris Angelico schreef:
> On Mon, Aug 19, 2013 at 10:03 AM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> This is irrelevant. That some context defines a constant, and that you
>> can use a variable with the same name as a constant in python, doesn't
>> contradict the statement that python (as a language) doesn't has
>> constants. There is nothing in the language that would prevent buggy
>> code from changing any of those variables. So from a python point of
>> views these are just global variables. Just as the struct_global.y was
>> in the original contribution.
> 
> And there's nothing preventing a program from using ctypes to
> overwrite an object's refcount, thus causing a segfault. So?

Yes so? What is your point? Since Cpython caches small integers
there is probably nothing preventing a program from using ctypes
to make the number three behave as the number five. That doesn't
mean that the language define three and five to be equal.

A language having constants, does mean that the language can prevent
a name from being reassigned.

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

-- 
Antoon Pardon.

[toc] | [prev] | [next] | [standalone]

#52689

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

And if I subsequently change it in my calling code, it isn't a
constant any more.  If I rebind the name, it's not even the same
variable any more.

That's a bug, not an exception to the rule "don't use global variables."

I also accept as a constant those values which are initialized
sufficiently early in the code that most places will only ever see the
final value.  Those may be global without worry.

-- 
DaveA

[toc] | [prev] | [next] | [standalone]

#52691

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

[toc] | [prev] | [next] | [standalone]

#52692

On Mon, Aug 19, 2013 at 3:55 PM, Antoon Pardon
<antoon.pardon@rece.vub.ac.be> wrote:
> Pity enough they chose a
> way that didn't allow programmers to protect names they thought
> important enough to do so too.

As of Python 3, we can redefine something that used to be a keyword,
which is even stronger than a constant.

def print(*args,print=print,**kw):
	print("##",*args,**kw)

What easier way to tag all your print calls? And this is why it helps
to have nothing technically constant. You should be able to do the
same with anything, without having to go and edit someone else's code
to remove the 'const' keyword.

ChrisA

[toc] | [prev] | [next] | [standalone]

#52701

Op 19-08-13 17:04, Chris Angelico schreef:
> On Mon, Aug 19, 2013 at 3:55 PM, Antoon Pardon
> <antoon.pardon@rece.vub.ac.be> wrote:
>> Pity enough they chose a
>> way that didn't allow programmers to protect names they thought
>> important enough to do so too.
>
> As of Python 3, we can redefine something that used to be a keyword,
> which is even stronger than a constant.
>
> def print(*args,print=print,**kw):
> 	print("##",*args,**kw)
>
> What easier way to tag all your print calls? And this is why it helps
> to have nothing technically constant. You should be able to do the
> same with anything, without having to go and edit someone else's code
> to remove the 'const' keyword.

But what you are showing here is shadowing, not redefintion and you can
do that even if the shadowed name would be a constant.

-- 
Antoon Pardon

[toc] | [prev] | [next] | [standalone]

#52710

Antoon Pardon <antoon.pardon@rece.vub.ac.be> writes:

> Op 19-08-13 09:45, Dave Angel schreef:
> > Antoon Pardon wrote:
> >> I think you are overstating your case. Classes and functions are
> >> variables too and in general nobody seems to have a problem with
> >> them being global.
> > 
> > It's global *variables* that are to be avoided. constants like
> > clsases and functions are fine. On the other hand, class attributes
> > can be variable, and thus are to be avoided when reasonable.
>
> Python has no constants. Classes and functions can be changed just like
> any other variable. I agree that classes and function are generally
> meant to be constant, but often enought so are global int variables.

I take this as yet another data point that speaking about “variables”
leads mostly to confusion.

What Python has are bindings. Those bindings can change (what Antoon
calls “changed just like any other variable”).

Many objects are immutable (what Dave calls “constants like classes and
functions”), even if the bindings can vary and even if they contain
attributes which are themselves bindings that can change.

So, you're both right. The terminology is leading you both astray and
having you talk past each other. Now go forth and speak of variables no
more :-)

-- 
 \         “We demand rigidly defined areas of doubt and uncertainty!” |
  `\    —Vroomfondel, _The Hitch-Hiker's Guide To The Galaxy_, Douglas |
_o__)                                                            Adams |
Ben Finney

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web