Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

As of next week, passwords will be entered in Morse code.


devel / comp.lang.python / Re: Variable scope inside and outside functions - global statement being overridden by assignation unless preceded by reference

SubjectAuthor
o Re: Variable scope inside and outside functions - global statement being overridJacob Kruger

1
Re: Variable scope inside and outside functions - global statement being overridden by assignation unless preceded by reference

<mailman.41.1709730776.3452.python-list@python.org>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=29589&group=comp.lang.python#29589

  copy link   Newsgroups: comp.lang.python
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!not-for-mail
From: jacob.kruger.work@gmail.com (Jacob Kruger)
Newsgroups: comp.lang.python
Subject: Re: Variable scope inside and outside functions - global statement
being overridden by assignation unless preceded by reference
Date: Wed, 6 Mar 2024 15:12:46 +0200
Lines: 268
Message-ID: <mailman.41.1709730776.3452.python-list@python.org>
References: <aff560df-2f57-47d9-ad81-74c21960c21d@gmail.com>
<0ccad7a9-eaba-48e6-b972-d89e5a930c11@DancesWithMice.info>
<db322a1b-2d29-4b67-9d5c-3e8d8737c0f5@gmail.com>
<bd2e0672-fc3e-4678-b212-04ab1f45c52c@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Trace: news.uni-berlin.de xWBkX+jRvhgj2rDj+kjVVAjgRCmbNC/UEdaGX1qu96oQ==
Cancel-Lock: sha1:hoqGpnMGCp20C4Jz6ZLqXDfKtag= sha256:sCWLe/OmY6ZGqOkydH7/z1eL9xnNmEBZFTOgGwzg7Eo=
Return-Path: <jacob.kruger.work@gmail.com>
X-Original-To: python-list@python.org
Delivered-To: python-list@mail.python.org
Authentication-Results: mail.python.org; dkim=pass
reason="2048-bit key; unprotected key"
header.d=gmail.com header.i=@gmail.com header.b=auQqQ8ul;
dkim-adsp=pass; dkim-atps=neutral
X-Spam-Status: OK 0.001
X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'def': 0.04; 'variable':
0.05; 'explicitly': 0.07; 'moment,': 0.07; 'received:mail-
ed1-x52b.google.com': 0.07; 'child': 0.09; 'datetime': 0.09;
'itself,': 0.09; 'meant': 0.09; 'objects,': 0.09; 'ok,': 0.09;
'page:': 0.09; 'parse': 0.09; 'populate': 0.09; 'ultimate': 0.09;
'values.': 0.09; 'way?': 0.09; 'steps': 0.11; 'import': 0.15;
'problem.': 0.15; '"in': 0.16; 'behaviour': 0.16; 'confused':
0.16; 'confused,': 0.16; 'declared': 0.16; 'directly,': 0.16;
'executed': 0.16; 'functions,': 0.16; 'initiate': 0.16;
'iterable': 0.16; 'manipulating': 0.16; 'not)': 0.16; 'psutil':
0.16; 'purely': 0.16; 'removes': 0.16; 'reproduce': 0.16;
'script.': 0.16; 'should,': 0.16; 'something.': 0.16;
'subject:being': 0.16; 'subject:reference': 0.16; 'timezone':
0.16; 'url:faq': 0.16; 'url:programming': 0.16; 'value?': 0.16;
'values,': 0.16; 'variable,': 0.16; 'variables,': 0.16; 'while,':
0.16; 'wrote:': 0.16; 'problem': 0.16; 'python': 0.16; 'values':
0.17; 'instead': 0.17; 'message-id:@gmail.com': 0.18; 'figure':
0.19; 'reduce': 0.19; 'to:addr:python-list': 0.20; 'issue': 0.21;
"what's": 0.22; 'version': 0.23; 'code': 0.23; 'skip:p 30': 0.23;
'run': 0.23; 'list,': 0.24; 'anything': 0.25; 'python,': 0.25;
'actual': 0.25; 'seems': 0.26; 'interact': 0.26; 'object': 0.26;
'else': 0.27; 'local': 0.27; 'function': 0.27; '>>>': 0.28;
'sense': 0.28; 'example,': 0.28; 'asked': 0.29; 'it,': 0.29;
'header:User-Agent:1': 0.30; 'seem': 0.31; 'think': 0.32;
'official': 0.32; 'amounts': 0.32; 'assume': 0.32; 'else,': 0.32;
'empty': 0.32; 'python-list': 0.32; 'requests,': 0.32; 'same,':
0.32; 'specified': 0.32; 'words,': 0.32; 'unless': 0.32;
'received:192.168.1': 0.32; 'but': 0.32; 'there': 0.33; 'same':
0.34; 'mean': 0.34; 'header:In-Reply-To:1': 0.34;
'received:google.com': 0.34; 'trying': 0.35; 'yes,': 0.35; 'less':
0.65; 'time.': 0.66; 'now,': 0.67; 'types': 0.67; 'back': 0.67;
'outside': 0.67; 'time,': 0.67; 'that,': 0.67; 'exactly': 0.68;
'items': 0.68; 'matter': 0.68; 'revert': 0.68; 'and,': 0.69;
'following:': 0.69; 'relate': 0.69; 'types,': 0.69; 'within':
0.69; 'terms': 0.70; 'carry': 0.71; 'ignore': 0.71; 'content':
0.72; 'global': 0.73; 'little': 0.73; 'relevant': 0.73; 'name,':
0.75; 'skip:f 20': 0.75; '8bit%:100': 0.76; 'successful': 0.78;
'moment': 0.81; 'extra': 0.84; 'bid': 0.84; 'executing': 0.84;
'experiment': 0.84; 'forgotten': 0.84; 'global.': 0.84;
'honestly,': 0.84; 'manipulated': 0.84; 'occurring': 0.84;
'referenced': 0.84; 'referral': 0.84; 'scope': 0.84; 'skip:% 30':
0.84; 'subject: \n ': 0.84; '\xc2\xa0\xc2\xa0\xc2\xa0\xc2\xa0':
0.84; 'skip:d 30': 0.86; 'body,': 0.91; 'down,': 0.91; 'retain':
0.91
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1709730774; x=1710335574; darn=python.org;
h=content-transfer-encoding:in-reply-to:content-language:references
:to:from:subject:user-agent:mime-version:date:message-id:from:to:cc
:subject:date:message-id:reply-to;
bh=gP9hjYlVh+Glua33tpYBYtC/mZ2U5IshTojwW/ROcHg=;
b=auQqQ8ul6vWNxsQFzzCY+n0+wN2KdRl947iINjI5/xBQ40jy74EidDm33Ma9mT8oQZ
Wh7RWYFCdEnAdkHtIAdfhsiz8VcrlbIFSNTtExyjG8wS0I4fJ5ZErJgI+AISkDdDQugP
Jf40S5+7FtjJmgE1kz1jdUtb03GjAi+V7aTBkRNq3WcJ2YVFVOdmmO8cJnwU3ehnAR3x
7DITlzxXwqaOfPUnlVbZ6WgTvibviG6CLqzxlpR/P9ajbG+kDy3HvQgjf2KzFlCPKUgl
YQW0U9C+wdAZi/09HaBgubPSs1zCON20Zn9tYTP9dEOtTdScvPQzCDmLYomaGhu63tj3
zsDQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1709730774; x=1710335574;
h=content-transfer-encoding:in-reply-to:content-language:references
:to:from:subject:user-agent:mime-version:date:message-id
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=gP9hjYlVh+Glua33tpYBYtC/mZ2U5IshTojwW/ROcHg=;
b=BaZjjscExevqcrRaQ8Qky4ImwmusRGkIVBAkuxoxD5jn3TjQrN+v4ETLefXnZ4wxXH
mpIjjo46JLR9xzhmF5qYEBPepbAAwvbxidegf2rZFmaDUtjRHVxSltj7HKjm047JEZCi
kluMUCynA2t57ccR4poKGtMihguPdYLCWcreDoBn3ZYIn4uGg+tYIM2hIL4I4tYPOqN/
g66ZWDININQfW0TWybLDJBjiBOnsRcE3/ykNE1+lpwdq8NV8UXUgFh9zPGTWGf84Ygp5
saTUIDupSVw4QTwCZce/L1EioirG0mq9Bxw4fZbStYy1UNgPFX+k9LCbyaWFaa5ld2eR
hnbQ==
X-Gm-Message-State: AOJu0YzOkjaDexkyIDvFxpxrAjIriuf2Saly08w4jZlat7MZmS+/FYM9
gzOuTxMYD/Jgs2Vs5n+/V4asTqSAWnepKQ3Ii8WwzgK5Z4q1nB/g3zrMPPC9
X-Google-Smtp-Source: AGHT+IE8CPceuqtOrSIIb/FCDfac8WD72Z44hbOW7/TkooqpO455o7qX2CNHdCJujOeKMZE2CIXoQA==
X-Received: by 2002:a05:6402:1bce:b0:565:ff64:33b0 with SMTP id
ch14-20020a0564021bce00b00565ff6433b0mr9830025edb.22.1709730773496;
Wed, 06 Mar 2024 05:12:53 -0800 (PST)
User-Agent: Mozilla Thunderbird
Content-Language: en-US
In-Reply-To: <db322a1b-2d29-4b67-9d5c-3e8d8737c0f5@gmail.com>
X-BeenThere: python-list@python.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: General discussion list for the Python programming language
<python-list.python.org>
List-Unsubscribe: <https://mail.python.org/mailman/options/python-list>,
<mailto:python-list-request@python.org?subject=unsubscribe>
List-Archive: <https://mail.python.org/pipermail/python-list/>
List-Post: <mailto:python-list@python.org>
List-Help: <mailto:python-list-request@python.org?subject=help>
List-Subscribe: <https://mail.python.org/mailman/listinfo/python-list>,
<mailto:python-list-request@python.org?subject=subscribe>
X-Mailman-Original-Message-ID: <bd2e0672-fc3e-4678-b212-04ab1f45c52c@gmail.com>
X-Mailman-Original-References: <aff560df-2f57-47d9-ad81-74c21960c21d@gmail.com>
<0ccad7a9-eaba-48e6-b972-d89e5a930c11@DancesWithMice.info>
<db322a1b-2d29-4b67-9d5c-3e8d8737c0f5@gmail.com>
 by: Jacob Kruger - Wed, 6 Mar 2024 13:12 UTC

So, this does not make sense to me in terms of the following snippet
from the official python docs page:

https://docs.python.org/3/faq/programming.html

"In Python, variables that are only referenced inside a function are
implicitly global. If a variable is assigned a value anywhere within the
function’s body, it’s assumed to be a local unless explicitly declared
as global."

So, I would then assume that if I explicitly include a variable name
inside the global statement, then even just assigning it a new value
should update the variable in the global context, outside the function?

Unless this is something that changed from 3.11 to 3.12 - since that
snippet is more or less referring to 3.12, but, don't think it was
changed in any way?

Jacob Kruger
+2782 413 4791
"Resistance is futile!...Acceptance is versatile..."

On 2024/03/06 14:55, Jacob Kruger wrote:
> Ok, simpler version - all the code in a simpler test file, and working
> with two separate variables to explain exactly what am talking about:
>
> # start code
>
> from datetime import datetime, timezone, timedelta
>
> from copy import copy
>
>
> # initialise original values
>
> dt_expiry = datetime.strptime("1970-01-01 00:00", "%Y-%m-%d
> %H:%M").replace(tzinfo=timezone.utc)
>
> l_test = [1, 2, 3]
>
>
> def do_it():
>     global dt_expiry, l_test # asked python to refer to global
> variables for both
>
>     # assign new value immediately
>
>     dt_expiry = datetime.now()+timedelta(minutes=5)
>     print(dt_expiry.strftime("%Y-%m-%d %H:%M")) # just to show new
> value has been assigned
>     # grab copy of list for re-use of items
>     l_temp = copy(l_test)
>     # following line means l_test will later on retain value in global
> scope because it was manipulated inside function instead of just
> assigned new value
>     l_test.clear()
>     # replace original set of values
>     for i in l_temp: l_test.append(i)
>     # add new item
>     l_test.append(99)
> # end of do_it function
>
> # end code
>
>
> If you import the contents of that file into the python interpreter,
> dt_expiry will start off as "1970-01-01 00:00", and, if you execute
> do_it function, it will print out the new value assigned to the
> dt_expiry variable inside that function, but if you then again check
> the value of the dt_expiry variable afterwards, it's reverted to the
> 1970... value?
>
>
> If I take out the line that removes values from l_test #
> l_test.clear() # before appending new value to it, then it will also
> not retain it's new/additional child items after the function exits,
> and will just revert back to [1, 2, 3] each and every time.
>
>
> In other words, with some of the variable/object types, if you use a
> function that manipulates the contents of a variable, before then
> re-assigning it a new value, it seems like it might then actually
> update/manipulate the global variable, but, either just calling purely
> content retrieval functions against said objects, or assigning them
> new values from scratch seems to then ignore the global scope
> specified in the first line inside the function?
>
>
> Hope this makes more sense
>
>
> Jacob Kruger
> +2782 413 4791
> "Resistance is futile!...Acceptance is versatile..."
>
>
> On 2024/03/05 20:23, dn via Python-list wrote:
>> Jacob,
>>
>> Please reduce the problem to a small code-set which reproduces the
>> problem. If we can reproduce same, then that tells us something. At
>> the very least, we can experiment without having to expend amounts of
>> time in a (likely faulty) bid to reproduce the same environment.
>>
>> Also, code is the ultimate description!
>>
>>
>> Perhaps start with a small experiment:
>>
>> - after l_servers is created, print its id()
>> - after the global statement, print its id()
>> - after the clear/reassignment, print its id()
>>
>> Is Python always working with the same list?
>> Please advise...
>>
>>
>> On 6/03/24 07:13, Jacob Kruger via Python-list wrote:
>>> Hi there
>>>
>>>
>>> Working with python 3.11, and, issue that confused me for a little
>>> while, trying to figure out what was occurring - unless am
>>> completely confused, or missing something - was that, for example,
>>> when having pre-defined a variable, and then included it in the
>>> global statement inside a function, that function was still
>>> referring to a completely local instance, without manipulating
>>> outside variable object at all unless I first executed a form of
>>> referral to it, before then possibly assigning a new value to it.
>>>
>>>
>>> Now, this does not seem to occur consistently if, for example, I
>>> just run bare-bones test code inside the python interpreter, but
>>> consistently occurs inside my actual testing script.
>>>
>>>
>>> Basically, in a file with python code in that am using for a form of
>>> testing at the moment, at the top of the file, under all the import
>>> statements, I initiate the existence of a list variable to make use of
>>>
>>> later:
>>>
>>>
>>> # code snippet
>>>
>>> l_servers = []
>>>
>>> # end of first code snippet
>>>
>>>
>>> Then, lower down, inside a couple of different functions, the first
>>> line
>>> inside the functions includes the following:
>>> # code snippet
>>>      global l_servers
>>> # end code snippet
>>>
>>> That should, in theory, mean that if I assign a value to that variable
>>> inside one of the functions, it should reflect globally?
>>>
>>> However, it seems like that, while inside those functions, it can be
>>> assigned a new list of values, but if I then return to the scope
>>> outside
>>>
>>> the functions, it has reverted back to being an empty list = []?
>>>
>>>
>>> The issue seems to specifically (or not) occur when I make a call to
>>> one function, and, in the steps it's executing in one context, while
>>> it's not doing anything to the list directly, it's then making a
>>> call to the second function, which is then meant to repopulate the
>>> list with a brand new set of values.
>>>
>>>
>>> Now, what almost seems to be occurring, is that while just
>>> manipulating the contents of a referenced variable is fine in this
>>> context, the moment I try to reassign it, that's where the issue is
>>> occurring .
>>>
>>>
>>> Here are relevant excerpts from the file:-
>>>
>>>
>>> # start code
>>>
>>> # original assignation in main part of file
>>>
>>> l_servers = []
>>>
>>>
>>> # function wich is initially being executed
>>>
>>> def interact():
>>>      global l_servers
>>>      # extra code inbetween choosing what to carry out
>>>
>>>      # ...
>>>
>>>      # end of other code
>>>
>>>      bl_response, o_out = list_servers()
>>>
>>>      if bl_response: # just make sure other function call was
>>> successful
>>>
>>>          l_servers.clear() # first make reference to global variable
>>>
>>>          for srv in o_out: l_servers.append(srv) # now re-populate
>>> items
>>>
>>>      # end code snippet from inside interact function
>>>
>>> # end of interact function
>>>
>>> # end of code snippet
>>>
>>>
>>> That other function being called from within, list_servers() was
>>> initially just trying to populate the values inside the global list
>>> variable itself, but was ending up in a similar fashion - reverting
>>> to initial empty value, but, the above now seems to work, as long as
>>> I first make reference to/manipulate/work with global variable
>>> instead of just trying to reassign it a brand new value/set of items?
>>>
>>>
>>> So, am I missing something obvious, have I forgotten about something
>>> else - yes, know that if was working from within an embedded
>>> function, I might need/want to then use the nonlocal statement
>>> against that variable name, but, honestly, just not sure how this
>>> can be occurring, and, it's not just with this one list variable, etc.?
>>>
>>>
>>> If I try simple test code from within the python interpreter, using
>>> different types of variables, this does also not seem to be the same
>>> all the time, but, don't think it can relate to an iterable like a
>>> list, or else, just in case, here is the code snippet with all the
>>> import statements from the top of that file, in case something could
>>> be overriding standard behaviour - not likely in this context, but,
>>> really not sure what's occurring:
>>>
>>> # import code snippet
>>>
>>> import requests, time
>>> from requests.auth import HTTPBasicAuth
>>> import psutil as psu
>>> import pytz
>>> import bcrypt
>>> from copy import copy
>>> from datetime import datetime, timedelta, timezone
>>> from dateutil.parser import parse
>>>
>>> # end of import snippet
>>>
>>>
>>> Thanks if you have any ideas/thoughts on the matter
>>>
>>>
>>> Jacob Kruger
>>> +2782 413 4791
>>> "Resistance is futile!...Acceptance is versatile..."
>>>
>>>
>>


Click here to read the complete article
1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor