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

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

PyMyth: Global variables are evil... WRONG!

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

Contents

  PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-11 18:06 -0800
    Re: PyMyth: Global variables are evil... WRONG! Tim Daneliuk <tundra@tundraware.com> - 2013-11-11 20:47 -0600
      Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-11 20:46 -0800
        Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-12 16:02 +1100
        Re: PyMyth: Global variables are evil... WRONG! Ricardo Aráoz <ricaraoz@gmail.com> - 2013-11-12 07:15 -0300
        Re: PyMyth: Global variables are evil... WRONG! Tim Chase <python.list@tim.thechases.com> - 2013-11-12 05:32 -0600
        Re: PyMyth: Global variables are evil... WRONG! Terry Reedy <tjreedy@udel.edu> - 2013-11-12 20:20 -0500
        Re: PyMyth: Global variables are evil... WRONG! Tim Daneliuk <tundra@tundraware.com> - 2013-11-13 18:17 -0600
          Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 18:25 -0800
    Re: PyMyth: Global variables are evil... WRONG! jongiddy <jongiddy@gmail.com> - 2013-11-12 06:12 -0800
      Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-12 07:05 -0800
        Re: PyMyth: Global variables are evil... WRONG! jongiddy <jongiddy@gmail.com> - 2013-11-12 07:33 -0800
          Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-12 09:00 -0800
            Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-12 09:42 -0800
            Re: PyMyth: Global variables are evil... WRONG! Tim Chase <python.list@tim.thechases.com> - 2013-11-12 11:45 -0600
            Re: PyMyth: Global variables are evil... WRONG! jongiddy <jongiddy@gmail.com> - 2013-11-12 14:41 -0800
              Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-12 18:45 -0800
                Re: PyMyth: Global variables are evil... WRONG! Tim Chase <python.list@tim.thechases.com> - 2013-11-12 21:22 -0600
                Re: PyMyth: Global variables are evil... WRONG! Andrew Cooper <root@127.0.0.1> - 2013-11-13 22:00 +0000
                  Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 18:16 -0800
    Re: PyMyth: Global variables are evil... WRONG! Alister <alister.ware@ntlworld.com> - 2013-11-12 14:32 +0000
      Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-13 02:22 +1100
    Re: PyMyth: Global variables are evil... WRONG! "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2013-11-13 23:42 +0000
      Re: PyMyth: Global variables are evil... WRONG! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-13 23:57 +0000
      Re: PyMyth: Global variables are evil... WRONG! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-14 01:09 +0000
        Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 19:22 -0800
          Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-14 14:29 +1100
            Re: PyMyth: Global variables are evil... WRONG! Roy Smith <roy@panix.com> - 2013-11-13 23:33 -0500
              Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 20:40 -0800
              Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-14 15:53 +1100
              Re: PyMyth: Global variables are evil... WRONG! Steven D'Aprano <steve@pearwood.info> - 2013-11-14 06:25 +0000
            Re: PyMyth: Global variables are evil... WRONG! unknown <unknown@unknown.com> - 2013-11-14 09:41 +0000
      Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 18:10 -0800
        Re: PyMyth: Global variables are evil... WRONG! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-14 02:45 +0000
          Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 19:45 -0800
            Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-13 20:01 -0800
            Re: PyMyth: Global variables are evil... WRONG! Steven D'Aprano <steve@pearwood.info> - 2013-11-14 05:50 +0000
              Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-14 09:26 -0800
                Re: PyMyth: Global variables are evil... WRONG! Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-14 12:37 -0500
                Re: PyMyth: Global variables are evil... WRONG! Ethan Furman <ethan@stoneleaf.us> - 2013-11-14 09:56 -0800
                  Re: PyMyth: Global variables are evil... WRONG! Alister <alister.ware@ntlworld.com> - 2013-11-14 20:12 +0000
                    Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-15 09:43 +1100
                Re: PyMyth: Global variables are evil... WRONG! Joel Goldstick <joel.goldstick@gmail.com> - 2013-11-14 13:43 -0500
                Re: PyMyth: Global variables are evil... WRONG! Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-11-14 19:04 +0000
                Re: PyMyth: Global variables are evil... WRONG! Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-11-15 08:19 +0000
                  Re: PyMyth: Global variables are evil... WRONG! Tim Daneliuk <tundra@tundraware.com> - 2013-11-15 09:26 -0600
                    Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-16 02:42 +1100
                      Re: PyMyth: Global variables are evil... WRONG! Tim Daneliuk <tundra@tundraware.com> - 2013-11-15 17:33 -0600
                      Re: PyMyth: Global variables are evil... WRONG! Tim Daneliuk <tundra@tundraware.com> - 2013-11-15 17:33 -0600
                  Re: PyMyth: Global variables are evil... WRONG! Rick Johnson <rantingrickjohnson@gmail.com> - 2013-11-15 20:01 -0800
                    Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-16 15:19 +1100
                    Re: PyMyth: Global variables are evil... WRONG! Chris Angelico <rosuav@gmail.com> - 2013-11-16 15:14 +1100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#59199

On Mon, 11 Nov 2013 18:06:09 -0800, Rick Johnson wrote:

> 
> In this thread, i want to get to the bottom of this whole
> "global-phobia" thing once and for all, and hopefully help you folks
> understand that globals are not all that bad -- when DESIGNED and USED
> correctly that is!

it is the final part of that statement that is important

As a generality "Avoid Globals" is not a bad "rule".
there may be some occasions when breaking this rule may be acceptable but 
it requires great experience & detailed knowledge to know when this is 
the right thing to do.

As an analogy music has may general rules that musicians are wise to 
follow.
Some pieces of music that break these rules are great because they have 
broken the rules but most are not. those that are great are great because 
the musician in question understands the reasons for the rules & how 
breaking them will affect the end product, the ones that are bad are 
because the musician does not know enough about music to even know the 
rule exists.





-- 
Immutability, Three Rules of:
	(1)  If a tarpaulin can flap, it will.
	(2)  If a small boy can get dirty, he will.
	(3)  If a teenager can go out, he will.
	(3a) If a teenager cant go out, he will. :-)

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

#59204

On Wed, Nov 13, 2013 at 1:32 AM, Alister <alister.ware@ntlworld.com> wrote:
> As an analogy music has may general rules that musicians are wise to
> follow.
> Some pieces of music that break these rules are great because they have
> broken the rules but most are not. those that are great are great because
> the musician in question understands the reasons for the rules & how
> breaking them will affect the end product, the ones that are bad are
> because the musician does not know enough about music to even know the
> rule exists.

Agreed. Pieces of music that violate the rules arbitrarily are just
annoying to try to play (and nearly impossible for the church to
follow), but when you find those really brilliant pieces that do
something special (Sir Arthur Sullivan, I'm looking at you -
especially having just been reading the booklet that came with the new
Beauty Stone recording), it's magnificent.

Global variables basically don't exist in Python. You have per-module
state. And if you start monkey-patching, you're fiddling with someone
else's module. It's all fun and games till someone loses a function...

sys.stdout.write=None

ChrisA

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

#59357

On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson  
<rantingrickjohnson@gmail.com> wrote:

> PyMyth: Global variables are evil... WRONG!

That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good  
general Software Engineering guideline regardless of language.  Like all  
guidelines it can be broken, but people who break it should do so  
knowingly, aware that they have created potential problems for themselves.

> ============================================================
>  The denial of the 99%:
> ============================================================
> Python has globals, but we just can't admit it!

A different subject entirely, but no more accurately stated.

[snip]
> But even the "module level" globals can be accessed
> "globally" if the module they are contained in is imported
> everywhere.

Remember when I said that guidelines can be broken?

> Globals are justified when they are used to communicate
> information between scopes that otherwise were meant to be
> mutually exclusive. One good example would be package sub-
> modules.

Sometimes, yes.  As long as you don't mind not being thread-safe, etc,  
etc.  If you've designed your interface, you're probably fine.  If you've  
throw it together with globals because it's the easy way, you're about to  
find out why the guideline you're breaking is a good one.

>  "But Rick, even when we use globals, we don't need that many"
>
> Only if you consider the single package that represents your
> program, but what about the thousands of support libraries
> with millions of lines of code that work in the background
> to make your measly few thousand lines of code work?  What
> about all the globals that they have injected?

Didn't you just say that Python globals are really module-level globals?   
Isn't this a strawman you've already disallowed?  It sounds to me like  
you're complaining that Python is ahead of the curve here :-)

-- 
Rhodri James *-* Wildebeest Herder to the Masses

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

#59360

On 13/11/2013 23:42, Rhodri James wrote:
> On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>
>> PyMyth: Global variables are evil... WRONG!
>
> That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
> general Software Engineering guideline regardless of language.  Like all
> guidelines it can be broken, but people who break it should do so
> knowingly, aware that they have created potential problems for themselves.
>

A quote from a colleage of mine circa 1991 "Real time programming is 
easy, just make all the data global".  There you are everybody, problem 
solved :)

-- 
Python is the second best programming language in the world.
But the best has yet to be invented.  Christian Tismer

Mark Lawrence

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

#59379

On Wed, 13 Nov 2013 23:42:24 +0000, Rhodri James wrote:

> On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
> 
>> PyMyth: Global variables are evil... WRONG!
> 
> That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
> general Software Engineering guideline regardless of language.

To be precise, it's not a myth at all.

Just because there are occasional medical uses for digitalis doesn't make 
it a myth that it is deadly poison. Just because there are occasional 
programming uses for global variables doesn't make it a myth that they 
are poor practice and lead to hard-to-maintain, unsafe, buggy code.


> Like all
> guidelines it can be broken, but people who break it should do so
> knowingly, aware that they have created potential problems for
> themselves.

Absolutely correct.


>> ============================================================
>>  The denial of the 99%:
>> ============================================================ Python has
>> globals, but we just can't admit it!
> 
> A different subject entirely, but no more accurately stated.

Completely inaccurately stated. It certainly isn't true that "99%" of 
people (who exactly? Rick doesn't say) claim that Python has no globals. 
That would be a stupid thing to say for a language with a "global" 
keyword, a "globals" function, and a built-in module that is shared 
across the entire process.


> [snip]
>> But even the "module level" globals can be accessed "globally" if the
>> module they are contained in is imported everywhere.
> 
> Remember when I said that guidelines can be broken?

I think you know the following, but for anyone else reading...

Just because a module global alpha.spam is accessible to anything that 
imports the module doesn't make it a process-wide global. The ability to 
do this:

import alpha
alpha.spam = 23

does not make "spam" a process-wide global. It just means that attribute 
access on the module object is the supported interface for manipulating 
names in namespaces which are modules.

There is very little practical difference apart from convenience between 
directly manipulating attributes as above, and using a setter function 
like "setattr(alpha, 'spam', 23)". Python tries to avoid boilerplate. 
Since manipulating attributes is useful, a philosophy of consenting 
adults applies and we have direct access to those attributes, with an 
understanding that we should use this power with care. With great power 
comes great responsibility -- if you're going to reach inside another 
module and manipulate things, you ought to know what you're doing.

One of the numerous problems with process-wide globals is that there's no 
encapsulation and consequently one package's use of "spam" clobbers 
another package's use of "spam" for a different purpose. But that's not 
the case here: alpha's "spam" is separate from module omega's "spam" 
variable.

To give an analogy: just because I can walk through the door of number 23 
Alpha Street and rummage through their fridge, and walk through the door 
of number 42 Omega Road and do the same, doesn't mean that the two 
fridges are actually the same fridge.



-- 
Steven

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

#59401

On Wednesday, November 13, 2013 7:09:42 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 23:42:24 +0000, Rhodri James wrote:
> > On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson wrote:
> >> Python has globals, but we just can't admit it!
> > A different subject entirely, but no more accurately stated.
> Completely inaccurately stated. It certainly isn't true
> that "99%" of people  claim that Python has no globals.
> That would be a stupid thing to say for a language with a
> "global" keyword, 

Yeah, a "global" keyword that extends access ONLY as far as
module level scope -- hardly a *true* global.

> a "globals" function, 

Yeah, a "globals function" that returns the MODULE LEVEL
globals symbol table.

> and a built-in module that is shared across the entire
> process.

Now your thinking clearly. This is where Python's dirty
little "secret globals" live.

> Just because a module global alpha.spam is accessible to
> anything that imports the module doesn't make it a
> process-wide global. The ability to do this: import alpha
> alpha.spam = 23 does not make "spam" a process-wide
> global.

Oh lord, back to the fuzzy logic again :(
 
> It just means that attribute access on the module object
> is the supported interface for manipulating names in
> namespaces which are modules.

HUH? Was this last sentence an attempt to distract? We are
all quite aware that DOT access is the interface for
accessing module members, but what the hell does that have
to do with "process wide globals"?

No, your not going to so easily fool this audience with
slight of hand! In your generalized code example:

    import alpha
    alpha.spam = 23
    
Yes. "spam" is an attribute of module "alpha", however, it is
also a global variable. Why?
 
  BECAUSE "alpha.spam" CAN BE MUTATED FROM ANYWHERE!

> There is very little practical difference apart from
> convenience between directly manipulating attributes as
> above, and using a setter function like "setattr(alpha,
> 'spam', 23)". Python tries to avoid boilerplate.

Here you go again. Steven, we are ALL quite aware of these
facts, how is "setattr" germane to my complaints about globals?

> Since manipulating attributes is useful, a philosophy of
> consenting adults applies and we have direct access to
> those attributes, 

We don't have "direct access", but access is an import away.

> with an understanding that we should use this power with
> care. With great power comes great responsibility -- if
> you're going to reach inside another module and manipulate
> things, you ought to know what you're doing.

Yes we must be careful, because these attributes are
ACTUALLY global. The fact that you have to use an import
statement to reach them does not alter the fact that they are
globally mutable.

> One of the
> numerous problems with process-wide globals is that
> there's no encapsulation and consequently one package's
> use of "spam" clobbers another package's use of "spam" for
> a different purpose. 

Exactly. That's why globals should be used intelligently.
There are many methods of creating an intelligent ordering
of global names so they don't clash. One of the most
simplistic is to tag all names with a prefix.

The best method is to have a namespace for globals that is
available everywhere WITHOUT import and accessed via a
single letter (you could emulate this now in Python by
injecting a namespace into sys.modules). In this manner,
globals will be both easily accessible, qualified (no need
for prefixes), and available WITHOUT messy imports

> But that's not the case here: alpha's "spam" is separate
> from module omega's "spam" variable. To give an analogy:
> [snip analogy]

Steven you're going off into "la-la land" man. Are you
suggesting that because two modules can contain the same
name that module attributes are not global?

I love how you support the duck typing paradigm UNTIL it
interferes with your argument. Sure, under Python's current
implementation of "globally mutable module attributes" you
can have the same name stored in different modules all with
different values, but they're still GLOBALS!

Because I can reach in and access them OR mutate them from
ANYWHERE! That's the very definition of a "globally
accessible variable" (aka: global variable)

    AND THIS IS WERE THE HYPOCRISY COMES IN. 
    
Since python modules have no set/get interface restrictions,
ALL attributes are globals!

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

#59402

On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Yeah, a "global" keyword that extends access ONLY as far as
> module level scope -- hardly a *true* global.

I have yet to see any language that gives true globals. At very best,
they're just process-wide! Honestly. How am I supposed to write code
that accesses variables running on my New York server?

Now, of course, if I had a server on Mars, that would be completely
different. They're only globals, after all.

ChrisA

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

#59409

In article <mailman.2580.1384399784.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> I have yet to see any language that gives true globals. At very best,
> they're just process-wide! Honestly. How am I supposed to write code
> that accesses variables running on my New York server?

Any one of a slew of remote procedure call protocols.  These days, the 
cool kids are using REST, but people have been doing RPC-ish things ever 
since the first guy to connect two computers with a piece of wire.

Wait, aren't you the guy who's into MUDs?

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

#59410

On Wednesday, November 13, 2013 10:33:22 PM UTC-6, Roy Smith wrote:
> Wait, aren't you the guy who's into MUDs?

Yes he is. 

But that's his second favorite hobby. 

His first is filling the "Devils Advocate" slot when 
Steven is too busy -- doing WHATEVER Steven does when 
he's not here. God only knows.

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

#59411

On Thu, Nov 14, 2013 at 3:33 PM, Roy Smith <roy@panix.com> wrote:
> In article <mailman.2580.1384399784.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
>
>> I have yet to see any language that gives true globals. At very best,
>> they're just process-wide! Honestly. How am I supposed to write code
>> that accesses variables running on my New York server?
>
> Any one of a slew of remote procedure call protocols.  These days, the
> cool kids are using REST, but people have been doing RPC-ish things ever
> since the first guy to connect two computers with a piece of wire.
>
> Wait, aren't you the guy who's into MUDs?

Yeah, I am. But there's this annoying difficulty with accessing
variables. I have to send messages around the world and get responses
back, I can't just type "global foo" and have foo be the same thing
here and everywhere else. I mean, it's called "global" for a reason,
why can't it be the same "foo" for every single process in the world?

Or if it's okay for "globals" to not be globally shared, then why is
it a problem for them to be per-module?

ChrisA

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

#59413

On Wed, 13 Nov 2013 23:33:22 -0500, Roy Smith wrote:

> In article <mailman.2580.1384399784.18130.python-list@python.org>,
>  Chris Angelico <rosuav@gmail.com> wrote:
> 
>> I have yet to see any language that gives true globals. At very best,
>> they're just process-wide! Honestly. How am I supposed to write code
>> that accesses variables running on my New York server?
> 
> Any one of a slew of remote procedure call protocols.  These days, the
> cool kids are using REST, but people have been doing RPC-ish things ever
> since the first guy to connect two computers with a piece of wire.

Nice Devil's Advocacy :-)

But of course, there are differences between the two situations. In a RPC, 
you have to use a defined interface to reach across the wire, so to 
speak, rather than have the two machines intimately coupled in a single 
namespace.

It is true that you can write RPC code that is highly coupled. Such 
highly coupled code is harmful whether it occurs due to global variables 
or via RPC calls or some other mechanism. But the difference is you have 
to work at it to write such highly coupled code with RPC calls, while 
with single-process globals such coupling occurs naturally without effort.


-- 
Steven

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

#59421

On Thu, 14 Nov 2013 14:29:41 +1100, Chris Angelico wrote:

> On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson
> <rantingrickjohnson@gmail.com> wrote:
>> Yeah, a "global" keyword that extends access ONLY as far as module
>> level scope -- hardly a *true* global.
> 
> I have yet to see any language that gives true globals. At very best,
> they're just process-wide! Honestly. How am I supposed to write code
> that accesses variables running on my New York server?
> 
> Now, of course, if I had a server on Mars, that would be completely
> different. They're only globals, after all.
> 
> ChrisA

+ networking computers on Mars is impossible (with TCP/IP at least)

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

#59389

On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote:
> On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson wrote:
> > PyMyth: Global variables are evil... WRONG!
> That's not a PyMyth.  It's a CompSciMyth, or to be more
> accurate a good general Software Engineering guideline
> regardless of language.  Like all guidelines it can be
> broken, but people who break it should do so knowingly,
> aware that they have created potential problems for
> themselves.

You speak as if using globals are inhabited by gremlins
just wanting to get out and run a muck. There are no
"inherent" problems in the global interface design except
those that programmer inserts himself.

Real global variable interfacing is no different than
python object member interfacing, or module interfacing,
except that the latter two are encapsulated by inside a
namespace, and the former (historically) are unprotected and
available everywhere; hence the name "global" :-)

With Python, i can still reassign a value to class attribute
and break code that depends on that attribute, of course,
doing so is not a good idea; but it's allowed nonetheless!

The programmer can break ANY interface in Python, be it
accessing a module attribute he shouldn't touch or via a
"real global" variable (if Python had that functionality).

So that renders this whole argument of "global gremlins" as
FUD. The gremlins don't exist until the programmer creates
them. Just because one programmer is unable to create a
logical global implementation, does not mean another cannot.

All you need to do is adopt the principles of consistency.

But i'm not here to convince you that globals are correct
for you, nor do i want you to use them if you feel
uncomfortable (lord knows there's enough bad code
circulating already!) i just want people to stop propagating
this myth that globals are evil.

And i also want to point out the hypocrisy of Python's
design. Python DOES have globals

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

#59396

On Wed, 13 Nov 2013 18:10:59 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote:
>> On Tue, 12 Nov 2013 02:06:09 -0000, Rick Johnson wrote:
>> > PyMyth: Global variables are evil... WRONG!
>> That's not a PyMyth.  It's a CompSciMyth, or to be more accurate a good
>> general Software Engineering guideline regardless of language.  Like
>> all guidelines it can be broken, but people who break it should do so
>> knowingly, aware that they have created potential problems for
>> themselves.
> 
> You speak as if using globals are inhabited by gremlins just wanting to
> get out and run a muck. There are no "inherent" problems in the global
> interface design except those that programmer inserts himself.
> 
> Real global variable interfacing is no different than python object
> member interfacing, or module interfacing, except that the latter two
> are encapsulated by inside a namespace, and the former (historically)
> are unprotected and available everywhere; hence the name "global" :-)

A fully-auto machine gun with a hair-trigger and no safety is no 
different from a single-barrel shotgun with a safety and a trigger lock! 
You can blow your foot off with both!

Yes, but in the first case you can do it by accident, while with the 
second you have to work hard to blow your foot off.


> So that renders this whole argument of "global gremlins" as FUD. The
> gremlins don't exist until the programmer creates them.

Wait... are you saying that software bugs only occur because the coder 
writes buggy software? I thought bugs came into existence via spontaneous 
generation, like viruses, bacteria, pigeons and Marine Corps sergeants.


> And i also want to point out the hypocrisy of Python's design. Python
> DOES have globals

Is that why it has a global keyword and a globals() function? Thanks for 
the information, I never would have worked that out without your keen 
insight.


-- 
Steven

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

#59404

On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>  A fully-auto machine gun with a hair-trigger and no
> safety is no  different from a single-barrel shotgun with
> a safety and a trigger lock!  You can blow your foot off
> with both!  

Yes. But in the case of the shotgun you'd have to find the
key, unlock the trigger, unset the safety, and aim REALLY
well... because your only getting off one shot, and if you
miss or only wound me, i've got that full auto machine gun
with hair trigger and no safety -- i won't need to live very
long to return the favor. >:)

> Yes, but in the first case you can do it by
> accident, while with the  second you have to work hard to
> blow your foot off.

Uh huh. 

And why do i have the sneaking suspicion that the BIG SCARY
ASSAULT WEAPON is referring to my argument and the "old
shot-gun that Grandpa has in the closet under lock and key"
is your argument.

But more importantly, why is all this straw scattered across
the floor? 

Very strange.

Very strange indeed.

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

#59406

And what's this?

    *picks up hat*

Where did this hat come from???

Spectator interrupts: Maybe Steven threw his hat in?

No, no. 

Can't be. 

Steven would not wear something this old. 

I mean, it looks like something a farmer would put on a
scarecrow or something???

    *scratched head*

OH MY GAWD!

    *throws hat on floor*

That hat has crow poop on it!

Could someone PLEASE get a janitor in here to clean this
mess up! 

For Christs sakes we're trying to have a technical
discussion here and some prankster goes and tosses a
straw grenade right in the middle of it!

How rude!

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

#59412

On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>>  A fully-auto machine gun with a hair-trigger and no
>> safety is no  different from a single-barrel shotgun with a safety and
>> a trigger lock!  You can blow your foot off with both!
> 
> Yes. But in the case of the shotgun you'd have to find the key, unlock
> the trigger, unset the safety, and aim REALLY well... because your only
> getting off one shot, and if you miss or only wound me, i've got that
> full auto machine gun with hair trigger and no safety -- i won't need to
> live very long to return the favor. >:)

I think you're missing the point that we're talking about the coder 
shooting themselves in the foot, not Gunfight At The OK Corral. There's 
no "favour" to return. 


>> Yes, but in the first case you can do it by accident, while with the 
>> second you have to work hard to blow your foot off.
> 
> Uh huh.
> 
> And why do i have the sneaking suspicion that the BIG SCARY ASSAULT
> WEAPON is referring to my argument and the "old shot-gun that Grandpa
> has in the closet under lock and key" is your argument.

That's the most insightful observation you've made in this thread so far.

Yes, the point is that process-wide global variables are demonstrated by 
50+ years of programming experience to be best avoided (in general -- 
there are caveats and exceptions of course). We're talking about probably 
millions of person-hours of experience leading to the conclusion that 
"globals are harmful".

It isn't that global variables will leap out of the computer and attack 
you while you sleep, of course, but that in general *its too damn hard* 
for human programmers to write good, reliable, maintainable, correct 
(i.e. bug-free) code using process-wide global variables. Global 
variables are the spaghetti code of namespacing -- everything is mixed up 
together in one big tangled mess.

The more global variables you have, the worse the tangle. One or two is 
not too bad. With good conventions for encapsulation to limit the amount 
of tangled, coupled code (e.g. naming conventions, or limiting globals to 
a single module at a time by default) the amount of harm can be reduced 
to manageable levels.

Global variables increases coupling between distant parts of the code. I 
remember a nasty little bug in Windows where removing IE stopped copy-and-
paste from working everywhere. That's a sign of excess coupling between 
code -- there's no logical reason why removing a web browser should cause 
copying text in Notepad to fail. We want to avoid unnecessary coupling: 
opening your fridge door shouldn't flush the toilet.

Since global variables increase coupling, and coupling is often harmful, 
one way to avoid unnecessary coupling is to avoid unnecessary global 
variables. Think of them as leaches. Even today, there are good uses for 
medical leaches:

http://en.wikipedia.org/wiki/Hirudo_medicinalis


One or two leaches is hardly noticeable. Ten or twenty starts being a bit 
of a problem. A few dozen and you'll certainly notice, and if you're 
covered in multiple hundreds of them, you're at risk of dying from blood 
loss, never mind the risk of infection.


-- 
Steven

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

#59457

On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano wrote:
> On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:
> > On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
> >>  A fully-auto machine gun with a hair-trigger and no
> >> safety is no  different from a single-barrel shotgun with a safety and
> >> a trigger lock!  You can blow your foot off with both!
> > Yes. But in the case of the shotgun you'd have to find the key, unlock
> > the trigger, unset the safety, and aim REALLY well... because your only
> > getting off one shot, and if you miss or only wound me, i've got that
> > full auto machine gun with hair trigger and no safety -- i won't need to
> > live very long to return the favor. >:)
> I think you're missing the point that we're talking about the coder 
> shooting themselves in the foot, not Gunfight At The OK Corral. There's 
> no "favour" to return. 

And you missed the point that i took your straw-man and
converted him into satire. You owe me gratitude for
*politely* ignoring your repeated logical fallacies.

> Yes, the point is that process-wide global variables are
> demonstrated by 50+ years of programming experience to be
> best avoided (in general -- there are caveats and
> exceptions of course). We're talking about probably
> millions of person-hours of experience leading to the
> conclusion that "globals are harmful".

But yet Python has globals, you just have to *import* them.
But that design is flawed

> It isn't that global variables will leap out of the
> computer and attack you while you sleep,

Funny, that sounds like my argument from earlier. Something
about "gremlins".

> of course, but that in general *its too damn hard* for
> human programmers to write good, reliable, maintainable,
> correct (i.e. bug-free) code using process-wide global
> variables.

Complete FUD. Maybe for you. Not for me.
 
> Global variables are the spaghetti code of namespacing --
> everything is mixed up together in one big tangled mess.

It's a tangled mess if you design it to be a tangled mess. 

> The more global variables you have, the worse the tangle. 

Complete illogic. 

What if all the globals are only accessed
and never mutated? You could have a million globals that never
change (of course they'd technically be constants) and never
suffer a single error from globals EVEN IF your an incompetent
software designer.

> One or two is not too bad. With good conventions for
> encapsulation to limit the amount of tangled, coupled code
> (e.g. naming conventions, or limiting globals to a single
> module at a time by default) the amount of harm can be
> reduced to manageable levels.

> SO now your agreeing that globals are not evil again. I
> positied an anaology in a passed thred that went something
> like this:

ManufacurerA claims his car is the safest on the road.

ManfacturerB drives ManfacturerA's car into a ditch and then
claims ManfacturerA is a liar.

Result: Who is wrong?

> Global variables increases coupling between distant parts
> of the code. I remember a nasty little bug in Windows
> where removing IE stopped copy-and- paste from working
> everywhere. That's a sign of excess coupling between code
> -- there's no logical reason why removing a web browser
> should cause copying text in Notepad to fail.

Do you have link describing this bug? I am not aware of such
bug ,but uh, i would not at all be surprised that windows
could break from removing that gawd awful IE.

Come to think of it, i'll bet it's not even a bug at all,
but a feature to prevent "wise users" from removing IE,
thereby maintaining IE's footprint in the wild. 

Steven, this sounds more like Fascism than "clumsy use of
globals" to me.

But even IF globals are to blame, by removing IE, you have
removed a large chunk of code from a code base that was not
designed for modularity. (We could argue whether or not
windows should allow removal of IE, but ultimately that is
M$ decision)

No developer could possibly forecast every possible "bad
thing" a user might decide to do. Especially when we're
talking about ripping components of the software out
completely.

Do i think IE should be a removal component? HECK YEAH, and
i would have designed it that way. But IS is not my baby, it
belongs to Mr. Gates, and he designs his software any way he
damn well pleases, and you and i can choose not to use it.

Image if someone downloaded Python and just started ripping
out source files willy-nilly because they did not like them
for whatever reason. Then, they came to this list and start
bitching because Python was blowing chunks. And don't give
examples of things that can be ripped out without breaking
Python, because that is germane either.

How would you respond to such complaints? 

Hmm...never thought you'd be agree with Mr. Gates did ya?

> We want to avoid unnecessary coupling: opening your fridge
> door shouldn't flush the toilet.

*KAH-BOOM* (Straw-bomb expodes)(AGAIN!)

> Since global variables increase coupling, and coupling is
> often harmful, one way to avoid unnecessary coupling is to
> avoid unnecessary global variables.

Nice! Your attempts to posit that "harmful coupling" is the
almost unavoidable outcome of "globals" is not fooling me.
Here's another way to phrase:

    Since transportation increases chances of death or
    injury from accidents, and death or injury is often
    harmful, one way to to avoid unnecessary death or injury
    is to avoid transportation.  
    
There are two logical ways to react to such grim reality:

    We could become consumed with fear and destroy all motor
    vehicles, bicycles, skateboards, etc...  and instead
    adopt the locomotion of our forefathers by utilizing our
    feet. or,
    
    We reduce the risks to almost nothing by designing and
    implementing globals via a logical and consistent
    interface. Then, to be sure, we test religiously
    (psst:we should be doing this anyway!!!)
    
But what we don't want to do is lull ourselves into a false
sense of security by "hiding" globals behind a pseudo
interface and thinking we have solved the problem of
globals. 

And this is what Python modules are doing! 

No, you've solved nothing. All you've done is to
stick you head in the sand.

============================================================
 It's my code, my problem, not yours!
============================================================    

Yes, you are correct. 

If you want to go on using globals in a dangerous way, or
using module attributes and believing falsely they're not
global, then by all means go on. HOWEVER, don't infect the
world with your sloppy architecture. KEEP YOU CODE TO
YOURSELF!

But that's not the case is it, NO, many of you are infecting
Python's code base with horrible code. 

Python's warts are *really* exposed when Python is embedded
as a scripting language. Since multiple scripts from
multiple authors will be running under the same process, any
one of them can bring the whole house of cards crashing
down. And with Python's current design, that possibility is
more likely.

It's sad, because Python is a great choice for scripting,
but the major design flaws are self defeating. Even
the best syntax ever created cannot make up for such
illogical inconsistencies at the core.

> Think of them as leaches. [snip remaining straw-bombs]

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

#59459

On Thu, Nov 14, 2013 at 12:26 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano wrote:
>> On Wed, 13 Nov 2013 19:45:42 -0800, Rick Johnson wrote:
>> > On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote:
>> >>  A fully-auto machine gun with a hair-trigger and no
>> >> safety is no  different from a single-barrel shotgun with a safety and
>> >> a trigger lock!  You can blow your foot off with both!
>> > Yes. But in the case of the shotgun you'd have to find the key, unlock
>> > the trigger, unset the safety, and aim REALLY well... because your only
>> > getting off one shot, and if you miss or only wound me, i've got that
>> > full auto machine gun with hair trigger and no safety -- i won't need to
>> > live very long to return the favor. >:)
>> I think you're missing the point that we're talking about the coder
>> shooting themselves in the foot, not Gunfight At The OK Corral. There's
>> no "favour" to return.
>
> And you missed the point that i took your straw-man and
> converted him into satire. You owe me gratitude for
> *politely* ignoring your repeated logical fallacies.
>
>> Yes, the point is that process-wide global variables are
>> demonstrated by 50+ years of programming experience to be
>> best avoided (in general -- there are caveats and
>> exceptions of course). We're talking about probably
>> millions of person-hours of experience leading to the
>> conclusion that "globals are harmful".
>
> But yet Python has globals, you just have to *import* them.
> But that design is flawed
>
>> It isn't that global variables will leap out of the
>> computer and attack you while you sleep,
>
> Funny, that sounds like my argument from earlier. Something
> about "gremlins".
>
>> of course, but that in general *its too damn hard* for
>> human programmers to write good, reliable, maintainable,
>> correct (i.e. bug-free) code using process-wide global
>> variables.
>
> Complete FUD. Maybe for you. Not for me.
>
>> Global variables are the spaghetti code of namespacing --
>> everything is mixed up together in one big tangled mess.
>
> It's a tangled mess if you design it to be a tangled mess.
>
>> The more global variables you have, the worse the tangle.
>
> Complete illogic.
>
> What if all the globals are only accessed
> and never mutated? You could have a million globals that never
> change (of course they'd technically be constants) and never
> suffer a single error from globals EVEN IF your an incompetent
> software designer.
>
>> One or two is not too bad. With good conventions for
>> encapsulation to limit the amount of tangled, coupled code
>> (e.g. naming conventions, or limiting globals to a single
>> module at a time by default) the amount of harm can be
>> reduced to manageable levels.
>
>> SO now your agreeing that globals are not evil again. I
>> positied an anaology in a passed thred that went something
>> like this:
>
> ManufacurerA claims his car is the safest on the road.
>
> ManfacturerB drives ManfacturerA's car into a ditch and then
> claims ManfacturerA is a liar.
>
> Result: Who is wrong?
>
>> Global variables increases coupling between distant parts
>> of the code. I remember a nasty little bug in Windows
>> where removing IE stopped copy-and- paste from working
>> everywhere. That's a sign of excess coupling between code
>> -- there's no logical reason why removing a web browser
>> should cause copying text in Notepad to fail.
>
> Do you have link describing this bug? I am not aware of such
> bug ,but uh, i would not at all be surprised that windows
> could break from removing that gawd awful IE.
>
> Come to think of it, i'll bet it's not even a bug at all,
> but a feature to prevent "wise users" from removing IE,
> thereby maintaining IE's footprint in the wild.
>
> Steven, this sounds more like Fascism than "clumsy use of
> globals" to me.
>
> But even IF globals are to blame, by removing IE, you have
> removed a large chunk of code from a code base that was not
> designed for modularity. (We could argue whether or not
> windows should allow removal of IE, but ultimately that is
> M$ decision)
>
> No developer could possibly forecast every possible "bad
> thing" a user might decide to do. Especially when we're
> talking about ripping components of the software out
> completely.
>
> Do i think IE should be a removal component? HECK YEAH, and
> i would have designed it that way. But IS is not my baby, it
> belongs to Mr. Gates, and he designs his software any way he
> damn well pleases, and you and i can choose not to use it.
>
> Image if someone downloaded Python and just started ripping
> out source files willy-nilly because they did not like them
> for whatever reason. Then, they came to this list and start
> bitching because Python was blowing chunks. And don't give
> examples of things that can be ripped out without breaking
> Python, because that is germane either.
>
> How would you respond to such complaints?
>
> Hmm...never thought you'd be agree with Mr. Gates did ya?
>
>> We want to avoid unnecessary coupling: opening your fridge
>> door shouldn't flush the toilet.
>
> *KAH-BOOM* (Straw-bomb expodes)(AGAIN!)
>
>> Since global variables increase coupling, and coupling is
>> often harmful, one way to avoid unnecessary coupling is to
>> avoid unnecessary global variables.
>
> Nice! Your attempts to posit that "harmful coupling" is the
> almost unavoidable outcome of "globals" is not fooling me.
> Here's another way to phrase:
>
>     Since transportation increases chances of death or
>     injury from accidents, and death or injury is often
>     harmful, one way to to avoid unnecessary death or injury
>     is to avoid transportation.
>
> There are two logical ways to react to such grim reality:
>
>     We could become consumed with fear and destroy all motor
>     vehicles, bicycles, skateboards, etc...  and instead
>     adopt the locomotion of our forefathers by utilizing our
>     feet. or,
>
>     We reduce the risks to almost nothing by designing and
>     implementing globals via a logical and consistent
>     interface. Then, to be sure, we test religiously
>     (psst:we should be doing this anyway!!!)
>
> But what we don't want to do is lull ourselves into a false
> sense of security by "hiding" globals behind a pseudo
> interface and thinking we have solved the problem of
> globals.
>
> And this is what Python modules are doing!
>
> No, you've solved nothing. All you've done is to
> stick you head in the sand.
>
> ============================================================
>  It's my code, my problem, not yours!
> ============================================================
>
> Yes, you are correct.
>
> If you want to go on using globals in a dangerous way, or
> using module attributes and believing falsely they're not
> global, then by all means go on. HOWEVER, don't infect the
> world with your sloppy architecture. KEEP YOU CODE TO
> YOURSELF!
>
> But that's not the case is it, NO, many of you are infecting
> Python's code base with horrible code.
>
> Python's warts are *really* exposed when Python is embedded
> as a scripting language. Since multiple scripts from
> multiple authors will be running under the same process, any
> one of them can bring the whole house of cards crashing
> down. And with Python's current design, that possibility is
> more likely.
>
> It's sad, because Python is a great choice for scripting,
> but the major design flaws are self defeating. Even
> the best syntax ever created cannot make up for such
> illogical inconsistencies at the core.
>
>> Think of them as leaches. [snip remaining straw-bombs]
> --
> https://mail.python.org/mailman/listinfo/python-list

I've been following along this thread a little bit.  From what I get
out of it that the OP thinks only lousy coders can't write good code
with globals. If you are skilled (as he claims) they are useful.  The
con argument says that over 50 years of learning how to make better
more productive computer languages, globals end up causing certain
problems.

So, beyond that, what is the point of the thread?  Is it about python?
 Just barely I guess

-- 
Joel Goldstick
http://joelgoldstick.com

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

#59462

On 11/14/2013 09:37 AM, Joel Goldstick wrote:
>
> So, beyond that, what is the point of the thread?

You haven't met Ranting Rick yet?  He's a troll's troll, outdone only by one other whose name I don't remember.

His posts are, amazingly enough, rants.  Usually about his (mis)perceptions of the failures of:

   - Python
   - The Python Leaders
   - Good Coding Practices
   - Everyone but himself (and the "Silent Majority" he represents)

He has been on vacation for a few months, but, alas, he is back.  Interestingly, even though he is still in my kill file 
I could tell the thread was his just from the subject title.

--
~Ethan~

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web