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

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

Re: Python handles globals badly.

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-11 14:26 -0700
    Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-11 23:50 +0200
      Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-11 18:01 -0600
        Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-12 07:22 +0200
          Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 18:05 +0100
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:04 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-13 22:06 +1000
                Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:11 +0200
                  Re: Python handles globals badly. Ned Batchelder <ned@nedbatchelder.com> - 2015-09-13 05:17 -0700
                    Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-15 05:36 +0200
          Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-12 10:18 -0700
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:06 +0200
              Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:10 +0200
          Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-12 20:32 -0600
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:05 +0200
      Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 20:11 -0400
      Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-11 18:34 -0600
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:57 +0100
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 04:01 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:06 -0400
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:16 -0400
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:17 +0100
      Terminology: “reference” versus “pointer” (was: Python handles globals badly.) Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 14:27 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:34 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:34 -0400
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 00:42 -0400
        Re: Terminology: “reference” versus “pointer” Steven D'Aprano <steve@pearwood.info> - 2015-09-13 02:32 +1000
          Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 09:54 -0700
            Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 03:06 +1000
            Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-12 10:14 -0700
            Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:24 +1000
              Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 03:34 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:45 +0100
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 14:52 +1000
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 01:03 -0400
        Re: Terminology: “reference” versus “pointer” Steven D'Aprano <steve@pearwood.info> - 2015-09-13 02:50 +1000
          Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:04 -0700
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 01:07 -0400
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 15:20 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 06:25 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 01:35 -0400
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 01:42 -0400
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 06:54 +0100
      Re: Terminology: “reference” versus “pointer” Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:02 +1000
      Re: Terminology: “reference” versus “pointer” Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 07:05 +0100
      Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:13 +1000
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 02:15 -0400
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 02:25 -0400
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 16:26 +1000
        Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 05:46 -0700
          Re: Terminology: "reference" versus "pointer" Laura Creighton <lac@openend.se> - 2015-09-12 16:41 +0200
            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 08:13 -0700
              Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 09:17 -0700
                Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:12 -0700
                  Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 04:14 +1000
                Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:48 +1000
                  Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 11:45 -0700
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 22:50 +1000
                      Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 23:29 +1000
                      Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 18:34 -0700
                        Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-14 04:34 +0100
                  Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 12:58 -0700
                    Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-12 15:14 -0700
                      Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 15:34 -0700
                        Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-13 00:14 +0100
                          Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-12 17:02 -0700
                            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 17:28 -0700
                            Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:44 -0700
                              Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-13 03:22 +0100
                                Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-12 19:25 -0700
                              Re: Terminology: "reference" versus "pointer" Michael Torrie <torriem@gmail.com> - 2015-09-12 20:35 -0600
                              Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-13 12:42 +1000
                                Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 08:31 -0700
                                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 01:39 +1000
                                  Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-14 06:48 +1000
                                    Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 18:13 -0700
                              Re: Terminology: "reference" versus "pointer" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-13 12:32 -0400
                          Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:23 -0700
                        Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 16:39 -0700
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 10:19 +1000
                          Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:25 -0700
                            Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 18:07 -0700
              Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-12 20:54 +0300
                Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 11:21 -0700
                  Re: Terminology: "reference" versus "pointer" Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-12 23:02 +0300
                    Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-12 17:10 -0400
                      Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 12:30 +1000
                      Re: Terminology: "reference" versus "pointer" Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-13 09:40 +0300
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-12 23:13 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-12 17:27 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-13 21:04 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 05:03 +1000
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-13 15:04 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 02:17 +0300
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-14 11:10 +1000
                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 04:22 +0300
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-14 12:38 +1000
                          Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 06:23 +0300
                            Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-15 02:59 +1000
                              Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 20:24 +0300
                                Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-14 11:29 -0700
                                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 22:30 +0300
                                    Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-14 13:16 -0700
                                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 23:32 +0300
                      Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 11:30 +1000
                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 05:26 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 09:52 +1000
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 03:30 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 10:58 +1000
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-13 19:38 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 17:48 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 11:10 -0400
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-15 03:03 +1000
                      Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 13:34 -0400
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-16 00:26 +1000
                      Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-14 10:51 -0700
                        Re: Terminology: "reference" versus "pointer" Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-16 20:14 +1200
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-16 18:18 +1000
                          Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-16 18:24 +1000
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-16 18:33 +1000
                      Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-15 03:59 +1000
                      Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 14:02 -0400
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-16 00:14 +1000
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 20:45 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 14:00 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 21:17 +0300
          Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:08 +1000
            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:26 -0700
          Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-13 11:13 +1000
      Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:27 +1000
      Re: Terminology: “reference” versus “pointer” Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:31 +1000
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 16:10 -0600
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 00:03 +0100

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

#96368 — Re: Python handles globals badly.

Reflecting latest answers to global and "proposals"


Ad hominem. 
There is a slogan: "There are always two persons involved"
This I dont want talk about. I dont go into such a discussion.
It seems more a problem of misinterpretations.


Proofs. 
Not really proofs. I meant more or less proofs. Proofs in "Proofs".
Proofs from my point of view or you can say from my understanding 
(or say also high level position view) and from the answers given so far


Samples 
(+main discussion "global"). 
Samples are often as text only in this thread. 
I think it is clear when you have followed the thread.
But the thread has now taken some new directions.
Yes, it is litte awkward searching back now.

But you can say, the "general" sample is:
You have to specify global that the compiler can distinguish
between local and global
Other words: global is needed to distinct global from local.

But this is "not" true.
You specify global cause you want write access.
Even the rules specified proves it:

> 1) If it's in the function's argument list, it's an argument (and
> therefore local).
> 2) If it's explicitly declared global, then it's global.
> 3) If it's never assigned within the function, then it's global.
> 4) Otherwise, it's local.

Take step 2 out than it is again recognized as global.  
So the global keyword is not needed to distinguish global from local.
Rule 3 proves it.



Identation.
It is stated
> It is correct that there have to be a decision for spaces or tabs.

With that I meant clearly no mixing of tabs and spaces.
So forget tabs (tabs changed to spaces) and take spaces.

The meaning is clearly:

def x():
  pass         2 spaces to the right

def y():
   pass        3 spaces to the right


Surprisingly this runs now.
Sometimes I run into indentations errors similiar to sample above for no reasons 
(maybe cause of existing spaces on the end of a line - next occurences I will try to note it down)
But I have to remove this proposal for now.
Sorry.


PEP.
As previously stated I am not in the position (and/or knowledge)
to write a PEP. I wanted only to start a general (high-level point of view) 
discussion about it, in the hope there is somehow an agreement which starts 
somehow a PEP.

But from answers in this list I would say: No chance.
Practically no agreements. This I have to accept, although 
I cannot understand it (reasons given in previous post:
it was/is nothing more than to enhance and give even more flexibility 
to the language as with all the other features already available in 
parallel for the same reasons).


Conclusion.
I will use Python, but never become a Pythonier, 
although quite conform with its philosophy "One best way".
But even a traditional switch is denied, although much clearer
in reading and writing than any if-else construct.
I can and will not understand it.


Thanks for your answers.

[toc] | [next] | [standalone]

#96369

Hello,

I'll add some arguments to the global discussion for you.

First a look back at the origin of this "global" keyword, basically it's 
idea behind it, which is probably a flawed assumption.

The origin/purpose of global as I now understand it is to give "write" 
access to globally declared variables.

This is first of all something unusual. Which other programmer language has 
this weird/whacky inconsistency ?

In general I believe inconsistent behaviour should be prevented in 
programming languages.

Anyway... having written/said that... there is a flawed assumption with this 
idea.

The assumption is that: "writing to globals is bad and can lead to bugs".

The further assumption is that: "denieing write access to globals prevents 
bugs".

Especially the last assumption is just plain wrong.

Not giving write access to globals can also lead to even much harder to find 
bugs.

The unaware programmer may assume that a global was changed, while in 
reality it was not.

How will such a bug be found ? Very hard to do in general, especially in an 
interpreter like python... where these bugs will need to be catched at run 
time.

Catching these bugs at runtime is far more difficult than bugs/errors which 
show up during compile time.

Thus forgetting "global" is going to be a far worse mistake... then actually 
overwritten or re-using some global accidently.

This kind of mistake can be checked by the programmer without requiring 
runtime inspection.

As soon as the programmer notices that some global is being re-used 
abusively the programmer can correct the situation.

With forgetting the global keyword not so... much harder to find.

Only possibility is to add "global" everywhere out of paranoya... which 
prevents the programmer from having to inspect every possibly line of code.

The global/write access requirement right now basically forces the 
programmer to check EVERY line of python code to see if a global is being 
written to which actually does not have the required write permission ?!?

How can anybody in their right mind think that is is somehow an improvement 
? It simply is not... unless the interpreter at runtime would start to BEEP 
or show ERROR messages in some log... that a global is being written too 
which actually does not have WRITE permissions ?

So far I have only used Sikuli to develop in Python... so let me ask a 
question here: Is there ANY Python IDE that actually produces such a warning 
or error message at runtime ????

Is there any IDE which outputs:

"Error: GLOBAL variable being written too without WRITE permission ?!?".

How would the interpreter know that it is a global variable ? Well it's 
declared somewhere outside the scope of the function... so that's not the 
issue... issue is missing GLOBAL declaration inside the function... so it's 
more of a "WRITE" permission than "global permission".

So the name itself: "GLOBAL" is somewhat misleading... it's more a "WRITE" 
permission lol.

Just that reason alone is enough to remove "GLOBAL" from python language and 
replace it with: "WRITE".

or if it has to be: "GLOBAL-WRITE".

But any programmer would probably find that ridicilous.

So that basically proves that this GLOBAL requirement in itself is pretty 
ridicilous... though it does give a nice hint that this variable is a global 
variable ?! But is that really necessary ?!?

Perhaps, perhaps not... in PASCAL one would simply look at the top section 
of the function... where all variable must be declared, python lacks this 
feature which is kinda nice... but it does make it a bit problematic to spot 
if something is local or global.

While the next best thing the python programmer can do is: inspect the 
entire function to see if the variable is being written to or read from 
somewhere... but in reality this is no garantuee that it is local or 
global... so hence a little bit of a problem... adding global to the 
language is not really going to solve that... since programmer will have to 
add that manually to a variable... might forget it... and then the variable 
will actually still be a global variable.. and any bug fixer will still need 
to inspect code.

So basically this global requirement doesn't really help that much... as 
some say... it's a bit of a hint... a shitty one for that... it's almost 
like fuzzy logic... 50% chance that it's gonna help... 50% it's not gonna 
help ;) or might even lead to problems if read-only behaviour was actually 
required.

So when it comes to assumptions which bug is worse:

1. Willfully writing to a read-only global variable. (assignment failed-bug)
2. Mistakenly writing to a writeable global variable. (overwrite-bug)

As I already wrote before I think bug1 is much harder to spot then bug 2 by 
pure code inspection.

Ask yourself one question:

How many times does a programmer actually want a "read-only" global variable 
? This seems very weird to me.

Pascal solves this very nicely for "constants" with constant declaration.

If a global variable is to remain "read-only" then a better approach would 
be pascal's way:

Simply declaring the global variable as "constant"

constant MyGlobal = 5

Writing to MyGlobal would then produce an error.

This can probably be checked at compile time too.

Something which python does not seem to do currently ?!

So that's weird.

I will leave it at that for now.

Bye,
  Skybuck. 

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

#96375

On 09/11/2015 03:50 PM, Skybuck Flying wrote:
> Something which python does not seem to do currently ?!
> 
> So that's weird.
> 
> I will leave it at that for now.

Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.

In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.

When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.

When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.

You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.

Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!

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

#96403

"Michael Torrie"  wrote in message 
news:mailman.384.1442016089.8327.python-list@python.org...

On 09/11/2015 03:50 PM, Skybuck Flying wrote:
> Something which python does not seem to do currently ?!
>
> So that's weird.
>
> I will leave it at that for now.

"
Seems to me you have a completely mistaken understanding of how
variables work in Python.  This is one of the reasons why I have said in
the past, erroneously, that Python does not have variables.  It does of
course but not in the same way as C or Pascal.  In those languages names
are source-code abstractions only, and irrelevant to the compiler and
machine code.  C and Pascal define variables as boxes that can be
written to.  Not so in Python.
"

Well you basically said it yourself:

" irrelevant to the compiler and machine code".

That's kinda nice about a high level language.

Programmer does not need to understand anything below the language.

A python programmer shouldn't need to understand a damn thing to write:

A  =  10
A = A + 1
print A

However for sake of your discussion I will continue your arguments below, 
since I get the impression you guys are clueless how to change python 
implementation ;)

"
In Python most common objects are immutable. Meaning they can never
change or be overwritten.  They are bound to names.  This binding is
what makes names look like and act like traditional variables.

The secret to understanding the global keyword is to understand how
Python namespaces work.  The statement "a=5" does not assign a 5 to the
box called "a."  Rather it binds the name "a" to the "5" object, which
is immutable and called into existence by the interpreter
implementation.  Subsequently "a=6" disconnects a from the 5 object,
casting the 5 object loose to be reclaimed in some fashion that doesn't
matter at this point.  "a" is then rebound to a new object, 6.
"

What happens for following code:

A=1234567890111111

Are you going to claim it's going to bind to all these numbers and then also 
multiple times ?

Sounds a bit shady ?! ;)

Perhaps python considers it a string ?

Python applies math to strings ?

Sounds a bit slow... therefore perhaps you're wrong...

"
When doing a look-up on a name, the interpreter first checks the local
scope's dictionary and if it does not find the name there there, goes to
the outer scope and so forth until you get to the module global
namespace.  So we don't need any special keywords to do Pascal-style
constants.  We just define them in the module and they work.  Usually we
name them in all caps so we have a bit of a convention as to where they
come from.  And yes we're talking about looking up strings in a
dictionary here.
"

So big deal, solution is easy to see, invert interpreter logic:

Everything declared is "not constant".

Everything declared as "constant" suddenly becomes constant.

And thus everything declared as not constant behaves the same way as 
"global", problem solved.

"
When binding a name to an object, the interpreter always binds a name in
the local namespace, unless the global keyword has been used previously
and then it goes right to the global namespace.  As has been said
numerous times on this thread, how else would the interpreter do this?
There simply isn't any other way that makes sense. Certainly you haven't
made the case for it, seeing as you have some fundamental
misunderstandings about variables in Python.
"

You didn't completely explain how the global namespace becomes writeable ? 
or re-bindeable ?

(It seems not necessary to explain it you implement the constant idea, as 
explained above already).

Do I have to assume that global namespace is "re-bindeable" = writeable ?

"
You keep saying things like "writing to a variable" or "declared
variables" which just don't apply to Python because that's not how
Python variables work.  It may appear this way on the surface, but the
differences are subtle yet important.  Namespaces are written to, not
variables, some objects can be mutated. Names are bound to objects, but
variables are not declared, as a name can be bound to an object of any type.
"

Well again you didn't explain how using namespaces suddenly lead to 
"rewritable" and/or "rebinding"

if A is declared as global as follows:

global A

and then code is written as follows:

A = 10
A = 20

def Test()
    global A = 30
    return

How does this make A "rewriteable" ? Or "rebindable" to 30 ?

"
Namespaces are powerful constructs that give Python much of its dynamic
nature and expressivity. Learn to use them!
"

I didn't learn anything from this posting, sorry ! ;)

Bye,
  Skybuck. 

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

#96432

On 2015-09-12 06:22, Skybuck Flying wrote:
>
>
> "Michael Torrie"  wrote in message
> news:mailman.384.1442016089.8327.python-list@python.org...
>
> On 09/11/2015 03:50 PM, Skybuck Flying wrote:
>> Something which python does not seem to do currently ?!
>>
>> So that's weird.
>>
>> I will leave it at that for now.
>
> "
> Seems to me you have a completely mistaken understanding of how
> variables work in Python.  This is one of the reasons why I have said in
> the past, erroneously, that Python does not have variables.  It does of
> course but not in the same way as C or Pascal.  In those languages names
> are source-code abstractions only, and irrelevant to the compiler and
> machine code.  C and Pascal define variables as boxes that can be
> written to.  Not so in Python.
> "
>
> Well you basically said it yourself:
>
> " irrelevant to the compiler and machine code".
>
> That's kinda nice about a high level language.
>
> Programmer does not need to understand anything below the language.
>
> A python programmer shouldn't need to understand a damn thing to write:
>
> A  =  10
> A = A + 1
> print A
>
> However for sake of your discussion I will continue your arguments below,
> since I get the impression you guys are clueless how to change python
> implementation ;)
>
> "
> In Python most common objects are immutable. Meaning they can never
> change or be overwritten.  They are bound to names.  This binding is
> what makes names look like and act like traditional variables.
>
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.  Subsequently "a=6" disconnects a from the 5 object,
> casting the 5 object loose to be reclaimed in some fashion that doesn't
> matter at this point.  "a" is then rebound to a new object, 6.
> "
>
> What happens for following code:
>
> A=1234567890111111
>
> Are you going to claim it's going to bind to all these numbers and then also
> multiple times ?
>
"all these numbers"? I see only one number there.

At runtime, it'll bind the name to the number, putting the pair into a
dict. (Actually, in a function, it can determine the names of all of
the local variables, so it uses 'slots' instead, as an optimisation.)

> Sounds a bit shady ?! ;)
>
> Perhaps python considers it a string ?
>
> Python applies math to strings ?
>
> Sounds a bit slow... therefore perhaps you're wrong...
>
Why would _he_ be wrong? _He_ never claimed any such thing!

> "
> When doing a look-up on a name, the interpreter first checks the local
> scope's dictionary and if it does not find the name there there, goes to
> the outer scope and so forth until you get to the module global
> namespace.  So we don't need any special keywords to do Pascal-style
> constants.  We just define them in the module and they work.  Usually we
> name them in all caps so we have a bit of a convention as to where they
> come from.  And yes we're talking about looking up strings in a
> dictionary here.
> "
>
> So big deal, solution is easy to see, invert interpreter logic:
>
> Everything declared is "not constant".
>
> Everything declared as "constant" suddenly becomes constant.
>
> And thus everything declared as not constant behaves the same way as
> "global", problem solved.
>
> "
> When binding a name to an object, the interpreter always binds a name in
> the local namespace, unless the global keyword has been used previously
> and then it goes right to the global namespace.  As has been said
> numerous times on this thread, how else would the interpreter do this?
> There simply isn't any other way that makes sense. Certainly you haven't
> made the case for it, seeing as you have some fundamental
> misunderstandings about variables in Python.
> "
>
> You didn't completely explain how the global namespace becomes writeable ?
> or re-bindeable ?
>
> (It seems not necessary to explain it you implement the constant idea, as
> explained above already).
>
> Do I have to assume that global namespace is "re-bindeable" = writeable ?
>
> "
> You keep saying things like "writing to a variable" or "declared
> variables" which just don't apply to Python because that's not how
> Python variables work.  It may appear this way on the surface, but the
> differences are subtle yet important.  Namespaces are written to, not
> variables, some objects can be mutated. Names are bound to objects, but
> variables are not declared, as a name can be bound to an object of any type.
> "
>
> Well again you didn't explain how using namespaces suddenly lead to
> "rewritable" and/or "rebinding"
>
Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.

> if A is declared as global as follows:
>
> global A
>
> and then code is written as follows:
>
> A = 10
> A = 20
>
> def Test()
>      global A = 30
>      return
>
> How does this make A "rewriteable" ? Or "rebindable" to 30 ?
>
> "
> Namespaces are powerful constructs that give Python much of its dynamic
> nature and expressivity. Learn to use them!
> "
>
> I didn't learn anything from this posting, sorry ! ;)
>

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

#96492

"
Namespaces don't "become writeable".

The purpose of "global" is to tell the compiler that this name should
be bound in the global namespace, not the local namespace.
"

How does it become writeable then ?

Bye,
  Skybuck.

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

#96494

On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote:

> "
> Namespaces don't "become writeable".
> 
> The purpose of "global" is to tell the compiler that this name should
> be bound in the global namespace, not the local namespace.
> "
> 
> How does it become writeable then ?

It's always writeable.






-- 
Steven

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

#96497

"Steven D'Aprano"  wrote in message 
news:55f566c8$0$1644$c3e8da3$5496439d@news.astraweb.com...

On Sun, 13 Sep 2015 10:04 pm, Skybuck Flying wrote:

> "
> Namespaces don't "become writeable".
>
> The purpose of "global" is to tell the compiler that this name should
> be bound in the global namespace, not the local namespace.
> "
>
> How does it become writeable then ?

"
It's always writeable.
"

Thus my logic is correct.

By making something global, it ends up in the global namespace, and it 
becomes writeable.

I don't even understand how python interpreter works but I can understand it 
better than you guys do apperently hahaha.

Bye,
  Skybuck. 

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

#96498

On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote:

> I don't even understand how python interpreter works but I can understand it 
> better than you guys do apperently hahaha.

As tempting as it is to respond to Skybuck, with a brief pause to consider,
and a deep breath, I'm sure we can all agree that there is no point in it.

Skybuck: go in peace, and thanks for being part of the Python community.

--Ned.

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

#96617

"Ned Batchelder"  wrote in message 
news:180fe671-7bf9-4544-a3ad-d98a4a497d06@googlegroups.com...

On Sunday, September 13, 2015 at 8:11:13 AM UTC-4, Skybuck Flying wrote:

> I don't even understand how python interpreter works but I can understand 
> it
> better than you guys do apperently hahaha.

"
As tempting as it is to respond to Skybuck, with a brief pause to consider,
and a deep breath, I'm sure we can all agree that there is no point in it.

Skybuck: go in peace, and thanks for being part of the Python community.
"

Go in Peace yourself

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

#96438

On 9/11/2015 10:22 PM, Skybuck Flying wrote:
<snip>

> I didn't learn anything from this posting, sorry ! ;)

I'm seeing a pattern here...

Emile

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

#96495

"Emile van Sebille"  wrote in message 
news:mailman.433.1442078406.8327.python-list@python.org...

On 9/11/2015 10:22 PM, Skybuck Flying wrote:
<snip>

> I didn't learn anything from this posting, sorry ! ;)

"
I'm seeing a pattern here...
"

Only thing I might have learned from him was global namespace make thing 
writeable.

But now somebody else says nope.

So I can truely say nothing was learned.

Explaining concepts to people takes something different.

As far as I am concerned python works with objects like Delphi.

And everything else is a reference to it.

And the globals are somehow protected.

But he's as clueless as everybody else seems to be.

For me it doesn't matter since I will write python code just fine without 
understanding any of it.

Bye,
  Skybuck.

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

#96496

I may add to that:

Just like most programmers don't truely understand what a compiler does ! 
HAHAHAHAHA.

C programmers, Delphi programmers, Java programmers.

What python's interpreter is doing same thing, probably completely 
irrelevant.

Except when it comes to making changes to how python works ;)

I don't need to know how the Python interpreter works, cause I will never 
change Python's implementation.

However as indicated I did try to help out.

Reversing the logic for python's global functioning should be possible.

Bye,
  Skybuck. 

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

#96483

On 09/11/2015 11:22 PM, Skybuck Flying wrote:
> I didn't learn anything from this posting, sorry ! ;)

I too am not surprised.  You're not here to learn, either about
programming language theory, or about Python apparently.

I would refer you to a good programming language theory class, but I
suspect you're not interested in learning formal definitions and theory.
 The terms I used here are all from formal programming language theory,
particularly the term "binding." If you're interested in it, this topic
makes for a fascinating class. I loved my programming language theory
class at uni.  We used scheme to explore language construction and to
build our own programming language.  Cool stuff.

I'm truly sorry you aren't interested in learning the underlying
theories of things, or the reasons for certain aspects of the language.
 To me Python's ability to enable so many different programming
paradigms, and to bring some of the coolest parts of LISP and Scheme to
a language for the masses is really cool.

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

#96493

From what he wrote I can see he's not making much sense...

Neither are you.

Just lot's of nag and little python related stuff.

Bye,
  Skybuck.

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

#96376

On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.

In other words, it assigns a pointer to the "5" object [otherwise known
as "a 5"] to the box called "a". (And increments its reference count, if
you care about how the CPython garbage collector works)

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

#96377

On 09/11/2015 06:11 PM, random832@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
>> The secret to understanding the global keyword is to understand how
>> Python namespaces work.  The statement "a=5" does not assign a 5 to the
>> box called "a."  Rather it binds the name "a" to the "5" object, which
>> is immutable and called into existence by the interpreter
>> implementation.
> 
> In other words, it assigns a pointer to the "5" object [otherwise known
> as "a 5"] to the box called "a". (And increments its reference count, if
> you care about how the CPython garbage collector works)

Yes I suppose that works. It shows the difference between Pascal's "a :=
5" and Python's "a = 5".  So long as it's not just a pointer we're
talking about here; it's a counted reference. I think I prefer the word
"reference" to "pointer" in this case.  The word, pointer has certain
connotations that come from C.  Certainly in the implementation you
would probably use pointers.  But we don't really need a full physical
memory abstraction to understand names and how they are bound (made to
refer) to objects.  In fact it might be more useful to forget about the
underlying mechanisms in the interpreter.  And it's useful to think
about namespaces because then we can understand what happens when python
sees a variable in an expression. In any case, we're not overwriting any
values in Python assignments.

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

#96386

On 12/09/2015 01:11, random832@fastmail.us wrote:
> On Fri, Sep 11, 2015, at 20:01, Michael Torrie wrote:
>> The secret to understanding the global keyword is to understand how
>> Python namespaces work.  The statement "a=5" does not assign a 5 to the
>> box called "a."  Rather it binds the name "a" to the "5" object, which
>> is immutable and called into existence by the interpreter
>> implementation.
>
> In other words, it assigns a pointer to the "5" object [otherwise known
> as "a 5"] to the box called "a". (And increments its reference count, if
> you care about how the CPython garbage collector works)
>

If everything in Python is an object, how can it assign a pointer? 
Especially how do Jython and IronPython assign pointers?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#96387

On 12/09/2015 01:01, Michael Torrie wrote:
> On 09/11/2015 03:50 PM, Skybuck Flying wrote:
>> Something which python does not seem to do currently ?!
>>
>> So that's weird.
>>
>> I will leave it at that for now.
>
> Seems to me you have a completely mistaken understanding of how
> variables work in Python.  This is one of the reasons why I have said in
> the past, erroneously, that Python does not have variables.  It does of
> course but not in the same way as C or Pascal.  In those languages names
> are source-code abstractions only, and irrelevant to the compiler and
> machine code.  C and Pascal define variables as boxes that can be
> written to.  Not so in Python.
>
> In Python most common objects are immutable. Meaning they can never
> change or be overwritten.  They are bound to names.  This binding is
> what makes names look like and act like traditional variables.
>
> The secret to understanding the global keyword is to understand how
> Python namespaces work.  The statement "a=5" does not assign a 5 to the
> box called "a."  Rather it binds the name "a" to the "5" object, which
> is immutable and called into existence by the interpreter
> implementation.  Subsequently "a=6" disconnects a from the 5 object,
> casting the 5 object loose to be reclaimed in some fashion that doesn't
> matter at this point.  "a" is then rebound to a new object, 6.
>
> When doing a look-up on a name, the interpreter first checks the local
> scope's dictionary and if it does not find the name there there, goes to
> the outer scope and so forth until you get to the module global
> namespace.  So we don't need any special keywords to do Pascal-style
> constants.  We just define them in the module and they work.  Usually we
> name them in all caps so we have a bit of a convention as to where they
> come from.  And yes we're talking about looking up strings in a
> dictionary here.
>
> When binding a name to an object, the interpreter always binds a name in
> the local namespace, unless the global keyword has been used previously
> and then it goes right to the global namespace.  As has been said
> numerous times on this thread, how else would the interpreter do this?
> There simply isn't any other way that makes sense. Certainly you haven't
> made the case for it, seeing as you have some fundamental
> misunderstandings about variables in Python.
>
> You keep saying things like "writing to a variable" or "declared
> variables" which just don't apply to Python because that's not how
> Python variables work.  It may appear this way on the surface, but the
> differences are subtle yet important.  Namespaces are written to, not
> variables, some objects can be mutated. Names are bound to objects, but
> variables are not declared, as a name can be bound to an object of any type.
>
> Namespaces are powerful constructs that give Python much of its dynamic
> nature and expressivity. Learn to use them!
>

My favourite analogy for Python names, the sticky note, here 
https://mail.python.org/pipermail/tutor/2006-October/049767.html

-- 
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

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

#96389

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:

> On 12/09/2015 01:11, random832@fastmail.us wrote:
> If everything in Python is an object, how can it assign a pointer?
> Especially how do Jython and IronPython assign pointers?

The Java and .NET runtimes also have pointers, they just don't [usually]
call them pointers, just like Python doesn't call them pointers (a match
made in... well, somewhere starting with an H, for sure).

Honestly, whether you want to call the thing a pointer or a reference,
you have to call it *something*, and I think "reference" is a worse fit
based on its connotations from C++. Whatever you call it, it's an arrow
on a diagram.

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

Page 1 of 7  [1] 2 3 4 5 6 7  Next page →

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

csiph-web