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 3 of 3 — ← Prev page 1 2 [3]

#59473

On Thu, 14 Nov 2013 09:56:04 -0800, Ethan Furman wrote:

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

I don't think there is any comparison.
Ricks trolls do at least promote intelligent discussion & cause the 
reader to re-asses preconceptions if only to confirm them.

Ricks non trolling posts do give him enough credibility to avoid 
dismissing his ideas out of hand





-- 
Go away! Stop bothering me with all your "compute this ... compute that"!
I'm taking a VAX-NAP.

logout

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

#59484

On Fri, Nov 15, 2013 at 7:12 AM, Alister <alister.ware@ntlworld.com> wrote:
> Ricks non trolling posts do give him enough credibility to avoid
> dismissing his ideas out of hand

When he's talking about Tkinter, he knows his stuff, and is orders of
magnitude more helpful than I would be (as I don't know Tkinter). When
he's talking about warts in Python, he sometimes knows what he's
talking about, often ignores facts, and generally is more stirring the
pot than actually being productive. But hey, they can still be fun
threads.

Now, I'm just waiting for the thread in which Nikos has problems with
Tkinter not working with Greek characters as of Python 3.3, and a
singularity is formed that results in the destruction of the known
universe...

ChrisA

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

#59463

On Thu, Nov 14, 2013 at 12:56 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
> 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~
> --
> https://mail.python.org/mailman/listinfo/python-list

Ah, thanks.  A tag team .. oh my!

-- 
Joel Goldstick
http://joelgoldstick.com

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

#59465

On 14/11/2013 17:56, Ethan Furman wrote:
> 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~

But he's not 100% troll as he has published some useful stuff on 
IDLE/tkinter, that's why he's only on the subs bench for my Trolls Dream 
Team.  No guesses who the captain is now :)

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

#59505

On Thu, 14 Nov 2013 09:26:18 -0800, Rick Johnson wrote:

> On Wednesday, November 13, 2013 11:50:40 PM UTC-6, Steven D'Aprano
> wrote:
[...]
>> 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.

I wasn't taking about genius programmers like you Rick, that would be 
silly. I'm talking about mere mortals like the rest of us.


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

Nobody sets out to *design* a tangled mess. What normally happens is that 
a tangled mess is the result of *lack of design*.


>> The more global variables you have, the worse the tangle.
> 
> Complete illogic.
> 
> What if all the globals are only accessed and never mutated? 

Then they aren't global VARIABLES. You'll note that I was very careful to 
refer to "variables".

Read-only global constants don't increase coupling to anywhere near the 
same degree as writable global variables. As such, they're far less 
harmful.

Of course, there is still some degree of coupling -- suppose one chunk of 
code wants a global constant X=23 and another chunk of code wants a 
global constant X=42? But such issues are generally easy to spot and easy 
to fix.


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

In this thread, I have never called global variables "evil". I have 
called them *harmful*, and tried to make it clear that harm is not a 
dichotomy "zero harm" versus "infinite harm", but a matter of degree. I 
stand by that.


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

Heh. 

Sorry, I can't find the link. It was well over five years ago, probably 
more like ten. But whether deliberate or accidental, that's the sort of 
thing I mean when I talk about excessive coupling. Note that coupling in 
and of itself is not harmful -- for example, you want the brake pedal of 
your car to be coupled to the brakes. Excess and inappropriate coupling 
is harmful: pressing the brake pedal shouldn't turn off the headlights, 
nor should a blown brake light stop the brakes from working. Hence we try 
to minimize coupling to only those areas that actually need them.

With physical devices, that's often -- not always -- trivial. The 
constraints of physical matter makes it natural to keep things loosely 
coupled. When you're building a car, the hard part is getting the 
coupling that you actually do want, not avoiding coupling you don't. 
Physical devices are, as a general rule, inherently and naturally 
encapsulated: the brake pedal is physically uncoupled from the brakes 
unless you literally connect them with steel cables and wires. Your 
fridge isn't connected to anything except the power supply, so it 
physically can't flush the toilet. Since the toilet and fridge are made 
in different factories and installed by different people, there's no 
motivation to couple them. Even if some bright spark decided that since 
opening the fridge door turns on the fridge light, and pressing the 
toilet button opens the cistern value, the two operations are related and 
therefore "Don't Repeat Yourself" applies and there should be a single 
mechanism to do both, it is impractical to build such a system. (And 
thank goodness. But just wait until we have internet-enabled fridges and 
toilets...)

But with software, coupling is *easy*. By default, code in a single 
process is completely coupled. Think of a chunk of machine code running 
in a single piece of memory. We have to build in our own conventions for 
decoupling code: subroutines, local variables, objects, modular code, and 
so forth. Physical objects are inherently decoupled. Code is inherently 
coupled, and we need conventions to decouple it. One of those conventions 
is to prefer local variables to global variables, and another is to limit 
the scope of global variables to per module rather than process-wide.



-- 
Steven

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

#59537

On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
> Nobody sets out to*design*  a tangled mess. What normally happens is that
> a tangled mess is the result of*lack of design*.

This has been an interesting thread - to me anyway - but this bit
above caught my eye.  People write programs for lots of reasons -
personal, academic, scientific, and commercial - but I actually
don't thing the resultant messes are caused by a "lack of
design" most of the time.  In my experience they're caused by only two things:

1) A lack of skill by inexperienced programmers who've been
    given more to do than they're yet ready to do and whose
    senior colleagues are not mentoring them (or such mentoring
    is being rejected because of ego and/or politics).

2) An evolving set of requirements.

#2 is particularly prevalent in commercial environments.  Modern
business is forced to respond to changing commercial conditions
in nearly realtime these days.   The pace of required innovation is
fast that - all too often - no one actually knows what the "requirements"
are during the design phase.  Requirements get *discovered* during the
coding phase.  This is not a moral failing or lack of discipline, it's
the simple reality that what you thought you needed to deliver changed
in the intervening 6 months of coding because the business changed.

  
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#59540

On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk <tundra@tundraware.com> wrote:
> On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
>> Nobody sets out to*design*  a tangled mess. What normally happens is that
>> a tangled mess is the result of*lack of design*.
>
> This has been an interesting thread - to me anyway - but this bit
> above caught my eye.  People write programs for lots of reasons -
> personal, academic, scientific, and commercial - but I actually
> don't thing the resultant messes are caused by a "lack of
> design" most of the time.  In my experience they're caused by only two
> things:
>
> 2) An evolving set of requirements.

This can be an explanation for a lack of design, but it's no less a
lack. Sometimes, something just grows organically... from a nucleus of
good design, but undesigned growth. Maybe it's time it got redesigned;
or maybe redesigning would take too much effort and it's just not
worth spending that time on something that's going to be phased out by
the next shiny thing in a couple of years anyway. Doesn't change the
fact that the current state is not the result of design, but of
disorganized feature creep. That's not necessarily a terrible thing,
but Steven's point still stands: such lack of design often results in
a tangled mess, and a tangled mess can often be blamed on lack of
design.

ChrisA

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

#59571

On 11/15/2013 09:42 AM, Chris Angelico wrote:
> On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk <tundra@tundraware.com> wrote:
>> On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
>>> Nobody sets out to*design*  a tangled mess. What normally happens is that
>>> a tangled mess is the result of*lack of design*.
>>
>> This has been an interesting thread - to me anyway - but this bit
>> above caught my eye.  People write programs for lots of reasons -
>> personal, academic, scientific, and commercial - but I actually
>> don't thing the resultant messes are caused by a "lack of
>> design" most of the time.  In my experience they're caused by only two
>> things:
>>
>> 2) An evolving set of requirements.
>
> This can be an explanation for a lack of design, but it's no less a
> lack. Sometimes, something just grows organically... from a nucleus of
> good design, but undesigned growth. Maybe it's time it got redesigned;
> or maybe redesigning would take too much effort and it's just not
> worth spending that time on something that's going to be phased out by
> the next shiny thing in a couple of years anyway. Doesn't change the
> fact that the current state is not the result of design, but of
> disorganized feature creep. That's not necessarily a terrible thing,
> but Steven's point still stands: such lack of design often results in
> a tangled mess, and a tangled mess can often be blamed on lack of
> design.
>
> ChrisA
>

A fair point.  Perhaps a better way to say this would be "Code that
is a tangled mess is often so because good design was not possible
during its creation."

The problem, of course, is that in almost all circumstances there is usually
not a lot of economic benefit to redesign and restructure the code
once you *do* know the requirements.  Other projects compete for attention
and fixing old, ugly stuff rarely gets much attention.  This is particularly
true insofar as most organizations do a lousy job of tracking what it
is really costing them to operate that kind of code.  If they did, cleaning
things up would become a much bigger priority.

Oh, and inevitably, the person that wrote the code without stable requirements
and without being given time to go back, refactor, cleanup, and restructure the
code ... gets blamed by the people that have to run and maintain it.

<Old Coders Love To Tell Stories Warning>

Years ago I worked for a company that did embedded banking software that
ran on high speed check readers.  It was an "application" that had been
undergoing constant feature creep and change during about an 18 month period
because the woman in marketing running the program get getting
Bright New Ideas (tm) to peddle.

The programmer - frustrated by this - began adding increasingly direct,
personal, and biological comments about said marketing person in the
comments of his assembler code.  Anyway, the new feature requests finally
stopped, and she came in one day to briskly inform us that the code
had been sold to one of our customers and she'd need a tape by end of
week.  The guy who'd been writing all this turned sheet white and scrambled
over the next few days to expunge all his nasty comments from thousands
of lines of assembler.  It was most entertaining to watch ...

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#59573

On 11/15/2013 09:42 AM, Chris Angelico wrote:
> On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk <tundra@tundraware.com> wrote:
>> On 11/15/2013 02:19 AM, Steven D'Aprano wrote:
>>> Nobody sets out to*design*  a tangled mess. What normally happens is that
>>> a tangled mess is the result of*lack of design*.
>>
>> This has been an interesting thread - to me anyway - but this bit
>> above caught my eye.  People write programs for lots of reasons -
>> personal, academic, scientific, and commercial - but I actually
>> don't thing the resultant messes are caused by a "lack of
>> design" most of the time.  In my experience they're caused by only two
>> things:
>>
>> 2) An evolving set of requirements.
>
> This can be an explanation for a lack of design, but it's no less a
> lack. Sometimes, something just grows organically... from a nucleus of
> good design, but undesigned growth. Maybe it's time it got redesigned;
> or maybe redesigning would take too much effort and it's just not
> worth spending that time on something that's going to be phased out by
> the next shiny thing in a couple of years anyway. Doesn't change the
> fact that the current state is not the result of design, but of
> disorganized feature creep. That's not necessarily a terrible thing,
> but Steven's point still stands: such lack of design often results in
> a tangled mess, and a tangled mess can often be blamed on lack of
> design.
>
> ChrisA
>

A fair point.  Perhaps a better way to say this would be "Code that
is a tangled mess is often so because good design was not possible
during its creation."

The problem, of course, is that in almost all circumstances there is usually
not a lot of economic benefit to redesign and restructure the code
once you *do* know the requirements.  Other projects compete for attention
and fixing old, ugly stuff rarely gets much attention.  This is particularly
true insofar as most organizations do a lousy job of tracking what it
is really costing them to operate that kind of code.  If they did, cleaning
things up would become a much bigger priority.

Oh, and inevitably, the person that wrote the code without stable requirements
and without being given time to go back, refactor, cleanup, and restructure the
code ... gets blamed by the people that have to run and maintain it.

<Old Coders Love To Tell Stories Warning>

Years ago I worked for a company that did embedded banking software that
ran on high speed check readers.  It was an "application" that had been
undergoing constant feature creep and change during about an 18 month period
because the woman in marketing running the program get getting
Bright New Ideas (tm) to peddle.

The programmer - frustrated by this - began adding increasingly direct,
personal, and biological comments about said marketing person in the
comments of his assembler code.  Anyway, the new feature requests finally
stopped, and she came in one day to briskly inform us that the code
had been sold to one of our customers and she'd need a tape by end of
week.  The guy who'd been writing all this turned sheet white and scrambled
over the next few days to expunge all his nasty comments from thousands
of lines of assembler.  It was most entertaining to watch ...

-- 
----------------------------------------------------------------------------
Tim Daneliuk     tundra@tundraware.com
PGP Key:         http://www.tundraware.com/PGP/

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

#59589

On Friday, November 15, 2013 2:19:01 AM UTC-6, Steven D'Aprano wrote:

> But with software, coupling is *easy*. By default, code in
> a single process is completely coupled. Think of a chunk
> of machine code running in a single piece of memory. We
> have to build in our own conventions for decoupling code:
> subroutines, local variables, objects, modular code, and
> so forth. Physical objects are inherently decoupled. Code
> is inherently coupled, and we need conventions to decouple
> it. One of those conventions is to prefer local variables
> to global variables, and another is to limit the scope of
> global variables to per module rather than process-wide.

You're thoughts on "coupling" and "decoupling"
of design architecture is correct, but you only argue for
your side :-). Allow me to now argue for my side now.

And i want to leave the "safe" world of general analogies
and enter the dark esoteric word of flawed software design.

And since people only want to give me credit when i talk
about Tkinter, well then, what better example of bad design
is there than Tkinter? Hmm, well there's IDLE but that will
have to wait for another thread.

Let's see... Tkinter's design today is a single module
containing a staggering:
    
    155,626 chars
    
    3,733 lines
    
    30 classes 
    
    16 functions
    
    4 "puesdo-constants" (Python does not support true
    constants!)
    
    10 "module level" variables (3 of which are mutated from
    nested scopes within the module itself)
    
    Unwise use of a global import for the types module, even
    though only a few names are used -- AND there are
    better ways to test type nowadays!
            
    Unwisely auto-imports 82 Tkinter constants.
    
Only OpenGL is more promiscuous than Tkinter!  

But let's stay on subject shall we!

============================================================
  The Road To Recovery:
============================================================

The very first thing a wise programmer would do is create a
package called "tkinter". Then, he would export all class
source code to individual sub-modules -- each module being
the class name in lowercase.

    AND VOILA! 
    
Even after only a simple half hour of restructuring, the
code is starting to become maintainable -- IMAGINE THAT!


    BUT DON'T GET YOUR ASTROGLIDE OUT YET FELLA! 

    WE'VE GOT MORE WORK TO DO!

Just as the programmer thought "all was well" in "toon
town", he quickly realizes that since Python has no
intelligent global variable access, and his sub-modules need
to share data with the main tkinter module (and vise versa),
he will be forced to write:

    from tkinter import var1, var2, ..., varN
    
    IN EVERY DAMN SUBMODULE that needs to access or
    mutate one of the shared variables or shared
    functions.

Can anyone tell me why sharing globals between sub-packages
is really so bad that we have to import things over and
over?

And if so, would you like to offer a cleaner solution for
the problem? 

And don't give me the messy import thing, because that's 
not elegant!

    WHY IS IT NOT ELEGANT RICK?
    
Because when i see code that accesses a variable like this:

    var = value
    
I have no way of knowing whether the mutation is happening
to a local variable, a module level variable, or even a true
global level variable (one which extends beyond the
containing module).

Sure, i could search the file looking for imports or
global declarations, but why not use "self documenting
paths" to global variables?

The best solution is to create a global namespace. You could
name it "G". So when i see a mutation like this:

    G.var = value:
    
I will know that the mutation is happening to a REAL global
variable. But, even that information is lacking. I need
more... What i really want to see is this:

    G.tkinter.var = value
  
Boom baby! Every thing i need to know is contained within
that single line without "import everywhere".

   I am accessing a global variable
   I am accessing a global variable for the tkinter package
   The variable's name is "var"
  
It's explicit, but it's not SO explicit that it becomes
excessive, no. I would much rather type just a FEW more
characters than scour source code looking for obscure clues
like global declarations, imports, or whatever foolish
design you can pull out of your arse!

    And what about the mysterious "run-time injected
    global", how the heck are you planning to handle
    that one with imports?

I just want to access globals in an logical and consistent
manner via a clean interface which will alleviate all the
backtracking and detective work that causes us to lose focus
on the main architecture of our software.

Because,

    EXPLICIT IS BETTER THAN IMPLICIT.
 
And, 
    
    FOCUS IS BETTER THAN FRUSTRATION!

Is that really too much to ask? 

Must i create a hack (C.py and G.py) for every missing or
broken feature in this damn language?

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

#59590

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Let's see... Tkinter's design today is a single module
> containing a staggering:
>
>     155,626 chars
>
>     3,733 lines

Also: I see nothing wrong with a single module having 3-4K lines in
it. Hilfe, the Pike REPL/interactive interpreter, is about that long
and it's not a problem to maintain. The Python decimal module (as
opposed to CDecimal) is twice that, in the installation I have here to
check. My primary C++ module from work was about 5K lines, I think -
of that order, at least.

Python modules don't need to be split up into tiny fragments.
Flat is better than nested.

ChrisA

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

#59591

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson
<rantingrickjohnson@gmail.com> wrote:
> Because when i see code that accesses a variable like this:
>
>     var = value
>
> I have no way of knowing whether the mutation is happening
> to a local variable, a module level variable, or even a true
> global level variable (one which extends beyond the
> containing module).

If it's in a function, and there's no global/nonlocal declaration,
it's local. Otherwise, it's module level. It can't be process-level in
Python, so you don't need to worry about that.

It doesn't get much simpler than that without variable declarations
(in which case it's "scan surrounding scopes till you find a
declaration, that's it" - and it's arguable whether that's simpler or
not). Really Rick, you're clutching at straws here.

ChrisA

[toc] | [prev] | [standalone]

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

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

csiph-web