On Sat, 9 Mar 2024 at 03:42, Grant Edwards via Python-list
wrote:
>
> On 2024-03-08, Chris Angelico via Python-list wrote:
> > On Sat, 9 Mar 2024 at 00:51, Grant Edwards via Python-list
> > wrote:
> >
> >> One might argue that "global" isn't a good choice for what to call the
> >> scope in
On 2024-03-08, Chris Angelico via Python-list wrote:
> On Sat, 9 Mar 2024 at 00:51, Grant Edwards via Python-list
> wrote:
>
>> One might argue that "global" isn't a good choice for what to call the
>> scope in question, since it's not global. It's limited to that source
>> file. It doesn't make
On Sat, 9 Mar 2024 at 00:51, Grant Edwards via Python-list
wrote:
> One might argue that "global" isn't a good choice for what to call the
> scope in question, since it's not global. It's limited to that source
> file. It doesn't make sense to me to call a binding "global", when
> there can be
On 2024-03-07, Cameron Simpson via Python-list wrote:
> Yes. Note that the "global" namespace is the module in which the
> function is defined.
One might argue that "global" isn't a good choice for what to call the
scope in question, since it's not global. It's limited to that source
file. It
On 06Mar2024 15:12, Jacob Kruger wrote:
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
Thanks again, all.
I think the python -i scoping2.py would have given me a good beginning
as well - will archive that one for use.
And, to maybe explain how I work - not an excuse at all - but, I am
actually 100% blind, so a lot of the IDE's, or their common
means/methods of interaction
On 2024-03-07, dn via Python-list wrote:
> The idea of importing a module into the REPL and then (repeatedly)
> manually entering the code to set-up and execute is unusual (surely type
> such into a script (once), and run that (repeatedly). As you say, most
> of us would be working from an
On 7/03/24 05:28, Jacob Kruger via Python-list wrote:
...
So, yes, know this comes across like some form of a scam/joke, or
list-garbage, since it doesn't make any sense to me at all, but still
just wondering if missing something, or should I shift over to 3.12 to
see if if works differently,
Grant Edwards via Python-list schreef op 6/03/2024 om 18:59:
On 2024-03-06, Roel Schroeven via Python-list
wrote:
> Op 6/03/2024 om 17:40 schreef Jacob Kruger via Python-list:
>> >>> from scoping2 import *
>
> [...]
>
> I would advice not to use 'import *', if at all possible, for
multiple
On 2024-03-06, Roel Schroeven via Python-list wrote:
> Op 6/03/2024 om 17:40 schreef Jacob Kruger via Python-list:
>> >>> from scoping2 import *
>
> [...]
>
> I would advice not to use 'import *', if at all possible, for multiple
> reasons, one of which is to prevent problems like this.
Op 6/03/2024 om 17:40 schreef Jacob Kruger via Python-list:
>>> from scoping2 import *
Ah yes, that explains what's happening. After that statement, the name
dt_expiry in the current namespace is bound to the same object that the
name dt_expiry in the namespace of module scoping2 is bound to.
Ok, Ethan, that makes sense - I generally work with modules in folders,
etc., but, this was just test code, but, 'see' if I instead import
scoping2 as sc2, and then refer to sc2.dt_expiry and sc2.do_it, then it
does operate as it should - thanks, again.
Jacob Kruger
+2782 413 4791
On 3/6/24 08:28, Jacob Kruger via Python-list wrote:
> C:\temp\py_try>python
> Python 3.11.7 (tags/v3.11.7:fa7a6f2, Dec 4 2023, 19:24:49) [MSC v.1937 64
bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from scoping2 import *
And it becomes
You'll see more details in other mail, but, here I am firing up standard
python interpreter from within windows terminal, and then executing
following line:
from scoping2 import *
And, this is under windows 11 windows terminal, which is where I
generally interact with my python code, via
Matt, other mail is more relevant - seems to maybe have more to do with
different behavour if import code, or not - no, does not make sense to
me - but, here's the command line contents including printing out id()
results, but, only working via importing code:
#---start session---
Thanks for all your input people, and, yes, I know that besides the
scope oddities the rest of the code is not my normal style either - was
partly due to forms of experimentation to try figure out what could be
causing issues. For example, instead of [:] syntax, was specifically
using copy()
Op 6/03/2024 om 16:39 schreef Roel Schroeven via Python-list:
Op 6/03/2024 om 13:55 schreef Jacob Kruger via Python-list:
If you import the contents of that file into the python interpreter,
[...]
What exactly to you mean by "import the contents of that file into the
python interpreter"?
Op 6/03/2024 om 13:55 schreef Jacob Kruger via Python-list:
If you import the contents of that file into the python interpreter, [...]
What exactly to you mean by "import the contents of that file into the
python interpreter"? Other people have put your code in a script,
executed it, and saw
On 3/6/2024 7:55 AM, Jacob Kruger via Python-list 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
#
On 3/6/2024 5:59 AM, Alan Gauld via Python-list wrote:
On 05/03/2024 22:46, Grant Edwards via Python-list wrote:
Unfortunately (presumably thanks to SEO) the enshittification of
Google has reached the point where searching for info on things like
Python name scope, the first page of links are
On 3/6/24 05:55, Jacob Kruger via Python-list 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:
If you import the contents of that file into the python interpreter,
dt_expiry will start off as
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
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 =
On 05/03/2024 22:46, Grant Edwards via Python-list wrote:
> Unfortunately (presumably thanks to SEO) the enshittification of
> Google has reached the point where searching for info on things like
> Python name scope, the first page of links are to worthless sites like
> geeksforgeeks.
And not just
On 2024-03-05, Cameron Simpson via Python-list wrote:
> Because there are no variable definitions in Python, when you write
> a function Python does a static analysis of it to decide which
> variables are local and which are not. If there's an assignment to a
> variable, it is a local variable.
On 05Mar2024 20:13, Jacob Kruger wrote:
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 .
Because there are no variable definitions in
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
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
28 matches
Mail list logo
