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

[Chris Angelico via Python-list]

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 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 multile different "global" bindings of the same name.
> >
> > Most "globals" aren't global either, since you can have different
> > globals in different running applications.
>
> To me, "global" has always been limited to within a single
> process/address space, but that's probably just bias left over from
> C/Pascal/FORTRAN/assembly/etc. It never occurred to me that a global
> called "X" in one program on one computer would be the same as a
> global called "X" in a different program on a different computer
> somewhere else on the "globe".
>

Yeah. My point is, though, the name "global" is a bit of a hack
anyway, so it's not THAT big a deal if it has other caveats too. For
example, let's say you always "import globals" at the top of every
script, and then assign "globals.x = 123" etc. Now you have a concept
of globals that spans the entire application, right? Well, no, not if
you use multiprocessing.

So, go ahead and call them globals, but people will always have to
learn about exactly what that means.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards via Python-list]

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 sense to me to call a binding "global", when
>> there can be multile different "global" bindings of the same name.
>
> Most "globals" aren't global either, since you can have different
> globals in different running applications.

To me, "global" has always been limited to within a single
process/address space, but that's probably just bias left over from
C/Pascal/FORTRAN/assembly/etc. It never occurred to me that a global
called "X" in one program on one computer would be the same as a
global called "X" in a different program on a different computer
somewhere else on the "globe".


-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Chris Angelico via Python-list]

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 multile different "global" bindings of the same name.
>

Most "globals" aren't global either, since you can have different
globals in different running applications.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards via Python-list]

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 doesn't make sense to me to call a binding "global", when
there can be multile different "global" bindings of the same name.

--
Grant




-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Cameron Simpson via Python-list]

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


Yes. Note that the "global" namespace is the module in which the 
function is defined.


x = 1

def f(n):
global x
x += n

This updates the `x` global variable in the module where `f` was 
defined.


If you import `f` and use it in another module it will _still_ update 
`x` in the original module namespace.

--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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 don't suit me all the time, which is why I 
generally work via programmer's text editor interfaces, or treat 
something like VS code as such, but then still prefer to run my code via 
command line, using pdb to then play around with forms of debugging, etc.



And, yes, also generally prefer to work via classes, modules, etc. at 
runtime, but this was more or less mostly testing, which then caused 
confusion/interference on my side...LOL!



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


On 2024/03/07 03:55, Grant Edwards via Python-list wrote:

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 IDE and hitting 'Run'. Am wondering why
you weren't - but it's not important.

Unless the code is intended to be used as a module, 'import'ing it into
the REPL doesn't make sense.

A simple example:

---testit.py--
x = 'x'
y = 'y'
def foo():
 global y
 print("hi")
 x = 'X'
 y = 'Y'
 print(x)
 print(y)
--

The usual method to play with that interactively is

 $ python -i testit.py
 >>> x
 'x'
 >>> y
 'y'
 >>> foo()
 hi
 X
 Y
 >>> x
 'x'
 >>> y
 'Y'
 >>>

As we've seen, doing a 'from testit.py import *' doesn't let you test
what the OP was trying to test. Doing 'import testit.py' gets you
closer, but it's a hassle to test code that way. The right thing to do
is 'python -i ' (or the equivalent button/option in an IDE).

   https://docs.python.org/3/tutorial/interpreter.html

If you intended to use testit.py as a module, and wanted to experiment
with its behavior as a module, then go ahead and import it. But, don't
do 'from testit.py import *' until

  1. you know how that differs from 'import testit.py'

and

  2. you want to use that difference



--
https://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards via Python-list]

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 IDE and hitting 'Run'. Am wondering why 
> you weren't - but it's not important.

Unless the code is intended to be used as a module, 'import'ing it into
the REPL doesn't make sense.

A simple example:

---testit.py--
x = 'x'
y = 'y'
def foo():
global y
print("hi")
x = 'X'
y = 'Y'
print(x)
print(y)
--

The usual method to play with that interactively is

$ python -i testit.py
>>> x
'x'
>>> y
'y'
>>> foo()
hi
X
Y
>>> x
'x'
>>> y
'Y'
>>>

As we've seen, doing a 'from testit.py import *' doesn't let you test
what the OP was trying to test. Doing 'import testit.py' gets you
closer, but it's a hassle to test code that way. The right thing to do
is 'python -i ' (or the equivalent button/option in an IDE).

  https://docs.python.org/3/tutorial/interpreter.html

If you intended to use testit.py as a module, and wanted to experiment
with its behavior as a module, then go ahead and import it. But, don't
do 'from testit.py import *' until

 1. you know how that differs from 'import testit.py'

and

 2. you want to use that difference


-- 
https://mail.python.org/mailman/listinfo/python-list

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

[dn via Python-list]

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, or just try reinstalling 3.11 from scratch, 
or should I retry the above in something like the VS code console, or a 
different python console, etc.?
Some of the facts, such as HOW the code was being executed were missing 
(see earlier request for a cut-down scenario, AND reports from others 
saying 'but it works for me').


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 IDE and hitting 'Run'. Am wondering why 
you weren't - but it's not important.


That said, the REPL is the perfect place to learn, experiment, and 
prototype - particularly when compared with the facilities of other 
language's eco-systems. The entirety of the on-line Tutorial cannot be 
wrong! (although, after a quick review, I've failed to see where the 
Tutorial mentions the usual development mode, apart from two very brief 
asides (the most useful is almost at the very end(?)) - but then (as 
they say) the objective is to show the language!


The lesson-learned is that there are different 'environments' and 
different ways of building the environment in which the code will run. 
That's a valuable lesson, and full of subtlety!


Glad to see that comparing id()s was useful - for diagnosis but not 
solution. Other tools might include the locals() and globals() 
functions. You may also have detected that many of us try to avoid 
globals and the implicit assumptions about the behavior of mutable 
collections (eg lists) when treated as 'global'. Then there are 
"closures", the "LEGB" rule, namespaces, scope, and ...


--
--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

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

[Roel Schroeven via Python-list]

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 > reasons, one of which is to prevent problems like this.


Unfortunately, many (most?) tutorials for particular modules (and even
example code in the Python documentation itself) are all written
assuming that you do "from  import *". It saves the tutorial
write a few keystrokes, but causes untold trouble for people who learn
incorrectly that "from  import *" is the proper way to do
things.


I know ... it's really irritating.

--
"There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened."
-- Douglas Adams, The Restaurant at the End of the Universe

--
https://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards via Python-list]

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.

Unfortunately, many (most?) tutorials for particular modules (and even
example code in the Python documentation itself) are all written
assuming that you do "from  import *".  It saves the tutorial
write a few keystrokes, but causes untold trouble for people who learn
incorrectly that "from  import *" is the proper way to do
things.

> I would also advice not to use global variables from other modules
> directly, and in fact would advice to minimize the use of globals in
> general as much as possible. If you need to keep state between
> methods, it might be better to use a class.


-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Roel Schroeven via Python-list]

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. Function 
do_it re-binds that last one to a new one, with the new value; name 
dt_expiry in the current namespace is still bound to the old object. (If 
all of that sounds like gibberish, have a look at "Facts and myths about 
Python names and values" (text: 
https://nedbatchelder.com/text/names.html; slides and video: 
https://nedbatchelder.com/text/names1.html)


I would advice not to use 'import *', if at all possible, for multiple 
reasons, one of which is to prevent problems like this.


I would also advice not to use global variables from other modules 
directly, and in fact would advice to minimize the use of globals in 
general as much as possible. If you need to keep state between methods, 
it might be better to use a class.


--
"There is a theory which states that if ever anyone discovers exactly what the
Universe is for and why it is here, it will instantly disappear and be
replaced by something even more bizarre and inexplicable.
There is another theory which states that this has already happened."
-- Douglas Adams, The Restaurant at the End of the Universe

--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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
"Resistance is futile!...Acceptance is versatile..."


On 2024/03/06 18:57, Ethan Furman via Python-list wrote:

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 clear:  only do `from ... import *` when the module has 
been specifically designed to support that.


If you were to also do `import scoping2` and, after calling `do_it()`, 
`print(scoping2.dt_expiry)`, you would see that it had changed.


I know there are good explanations for how variables and names work in 
Python, but I couldn't find any at the moment. Sorry.


--
~Ethan~

--
https://mail.python.org/mailman/listinfo/python-list

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

[Ethan Furman via Python-list]

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 clear:  only do `from ... import *` when the module has been 
specifically designed to support that.

If you were to also do `import scoping2` and, after calling `do_it()`, `print(scoping2.dt_expiry)`, you would see that 
it had changed.


I know there are good explanations for how variables and names work in Python, but I couldn't find any at the moment. 
Sorry.


--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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 command line - generally 
working with flask, and/or other forms of command line interaction, most 
of the time.



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


On 2024/03/06 17:39, Roel Schroeven via Python-list wrote:

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 it working as expected. I pasted in IPython, and 
likewise saw it working as expected, and the same with IDLE. It seems 
to me you must be doing something different from us; maybe the way you 
execute that code might be the key to this whole confusion.



--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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

C:\temp\py_try>type scoping2.py
from datetime import datetime, timezone, timedelta

dt_expiry = datetime.strptime("1970-01-01 00:00", "%Y-%m-%d 
%H:%M").replace(tzinfo=timezone.utc)


def do_it():
    global dt_expiry
    dt_expiry = datetime.now()+timedelta(minutes=5)
    print("date value", dt_expiry.strftime("%Y-%m-%d %H:%M"))
    print("ID", id(dt_expiry))
# end of do_it function


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 *
>>> print(dt_expiry)
1970-01-01 00:00:00+00:00
>>> print(id(dt_expiry))
1808577867152
>>> do_it()
date value 2024-03-06 18:39
ID 1808572660736
>>> print(dt_expiry)
1970-01-01 00:00:00+00:00
>>> print(id(dt_expiry))
1808577867152
>>>
---end session---

As in, the two different ID values are being returned outside and inside 
the function, whereas, if I included that bit inside the interpreter 
while typing code manually, chances are the same ID would be retained 
both inside and outside function.


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


On 2024/03/06 15:57, Mats Wichmann via Python-list wrote:

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


No, it doesn't. Your code is working as one would expect. For example, 
adding prints for the l_test variable, and removing the .clear() which 
you claim makes it not work, shows me:


before: l_test=[1, 2, 3], id(l_test)=140153285385856
leaving do_it: l_test=[1, 2, 3, 1, 2, 3, 99], id(l_test)=140153285385856
after: l_test=[1, 2, 3, 1, 2, 3, 99], id(l_test)=140153285385856

It's the same list object, as you can see by the id values. And the 
list is updating as expected.


And... you don't need the global statement for l_test. As it's 
mutable, you can mutate it in the function; the global only acts on 
assignment. Using "global" for that may make your intent more clear to 
readers though, although static checkers will grumble at you.


You must be doing something additional that you're not telling us about.



--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

int statements):


List before: [1, 2, 3]
start: 1970-01-01 00:00
inside after reassignment: 2024-03-06 08:57
outside after: 2024-03-06 08:57
List after: [1, 2, 3, 99]

As an aside, you have gone to some trouble to copy, clear, and 
reconstruct l_test.  It would be simpler like this (and you wouldn't 
have to import the "copy" library):


    l_temp = l_test[:]
    l_test = []

Instead of those lines and then this:

    for i in l_temp: l_test.append(i)

you could achieve the same thing with this single statement:

    l_test = l_test[:]


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 val

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

[Roel Schroeven via Python-list]

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"? Other people have put your code in a script, 
executed it, and saw it working as expected. I pasted in IPython, and 
likewise saw it working as expected, and the same with IDLE. It seems 
to me you must be doing something different from us; maybe the way you 
execute that code might be the key to this whole confusion.
(As an aside, I made a type; "What exactly _do_ you mean" is what I 
meant to type)


If you want, you can play with the code online here:
https://tio.run/##pVPbitswEH3XVwwJITaNQ9KllATy0EKhL/2AUsqiWKNkWlkykrzZ7NJvT0e@JWT7VmPsEZozc87RqD7Ho7MPl8sUQpQ@QukUCqG9q0DJiJEqBKpqx1vDegHp@@JsHyk0UfaY0tXnIT/FQogpkKVI0lBAcJ4OZKWBJ2kaDEKo@IjPNfkz7MYGyxB9nYJsst58XBWrNb@wWm1Xq8kCJrPvxawqZgpmX7ezb5N86bE2ssQsvpDVbjewWzaxzIUwjxFD5PI/1gt4v4CHn0xKoQblHilm@VYAPwfj9kxrpLOAHjcFGX6jgrp1CqIDjxp9CnrMk/Qk9wYDaOdh7@JRtCUTMtDBgsVTp5edYbuIZZpzl/NP@dadsvzdaG1WkW2Yy@5D3mJqTzZmIzK5pTu37p3JmcOvhkUw2XB0pxsmRxlgj2h7jqh6ygcv990pOg18ZLEV5bFo0ulpoIhVaHOTP1XNvFN21rmV91W0M8adyB64hEWoUNowGHoiY8CwVg/sp8coyQ722MHTwEWRCZYy9SVGMd9KWqqbBFWcGkgh6MaWkbgOryNKlSi2igdZV8kj6RCXpUHps4FtPz/X4QwYU6F@RlNSMoESv071digk6xqtymgoJVXXMdl027DP22xyvg8cpfLt/I0KRL@RLiDwhHanPP@M3Brn@bAu2mdc6/k4B7vXMfxzs98R2L12/@tOPrb48owlz1fH575TMTbsr8sb@CfNR3kH@x9@l8tf

(sorry for the long URL; that's where tio.run puts the code)

Again it works as expected, but with or without the l_test.clear() line.

--
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à
ajouter, mais quand il n'y a plus rien à retrancher."
"Perfectie is niet bereikt als er niets meer toe te voegen is, maar als er
niets meer weg te nemen is."
-- Antoine de Saint-Exupéry

--
https://mail.python.org/mailman/listinfo/python-list

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

[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"? Other people have put your code in a script, 
executed it, and saw it working as expected. I pasted in IPython, and 
likewise saw it working as expected, and the same with IDLE. It seems to 
me you must be doing something different from us; maybe the way you 
execute that code might be the key to this whole confusion.


--
"Il semble que la perfection soit atteinte non quand il n'y a plus rien à
ajouter, mais quand il n'y a plus rien à retrancher."
"Perfectie is niet bereikt als er niets meer toe te voegen is, maar als er
niets meer weg te nemen is."
-- Antoine de Saint-Exupéry

--
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas Passin via Python-list]

y, 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..."






--
https://mail.python.org/mailman/listinfo/python-list

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

[Thomas Passin via Python-list]

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 to worthless sites like
geeksforgeeks.

And not just Google, I just tried bing, yahoo and duckduckgo
and they are all the same. Not a one listed anything from
python.org on the first page... In fact it didn't even appear
in the first 100 listings, although wikipedia did manage an
entry, eventually.


I don't know ... I just searched for "python local vs global variables" 
and a python.org page on it was the second hit. I usually use StartPage 
- who knows where they aggregate from - but the same search on Google 
and Bing also popped up the python.org link as the second hit.  As usual 
Bing was a nasty experience, though.


Still, if your search phrase isn't as well focused as that or you are 
less lucky, for sure you'll get all sorts of junk.


--
https://mail.python.org/mailman/listinfo/python-list

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

[Mats Wichmann via Python-list]

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


No, it doesn't. Your code is working as one would expect. For example, 
adding prints for the l_test variable, and removing the .clear() which 
you claim makes it not work, shows me:


before: l_test=[1, 2, 3], id(l_test)=140153285385856
leaving do_it: l_test=[1, 2, 3, 1, 2, 3, 99], id(l_test)=140153285385856
after: l_test=[1, 2, 3, 1, 2, 3, 99], id(l_test)=140153285385856

It's the same list object, as you can see by the id values. And the list 
is updating as expected.


And... you don't need the global statement for l_test. As it's mutable, 
you can mutate it in the function; the global only acts on assignment. 
Using "global" for that may make your intent more clear to readers 
though, although static checkers will grumble at you.


You must be doing something additional that you're not telling us about.


--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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





--
https://mail.python.org/mailman/listinfo/python-list

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

[Jacob Kruger via Python-list]

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





--
https://mail.python.org/mailman/listinfo/python-list

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

[Alan Gauld via Python-list]

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 Google, I just tried bing, yahoo and duckduckgo
and they are all the same. Not a one listed anything from
python.org on the first page... In fact it didn't even appear
in the first 100 listings, although wikipedia did manage an
entry, eventually.

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Grant Edwards via Python-list]

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.  _Regardless_ of whether that
> assignment has been executed, or gets executed at all (eg in an
> if-statement branch which doesn't fire).

Unfortunately, crap "information" sites like geeksforgeeks often
describe this either incorrectly or so vaguely as to be worthless.
>From the page https://www.geeksforgeeks.org/global-local-variables-python/

 Python Global variables are those which are not defined inside
 any function and have a global scope whereas Python local
 variables are those which are defined inside a function and their
 scope is limited to that function only.

Since "define" (in this context) isn't a term of art in Python, and
it's never defined on the page in question, the quoted paragraph is
not meaningful: it simply says that "global variables are global and
local variables are local".

That page goes on to say:

 In other words, we can say that local variables are accessible
 only inside the function in which it was initialized

This is equally crap. It doesn't matter whether the variable is
initialized or not. As Cameron correctly stated, if a function
contains an assignment to a variable, and that variable is not
declared global, then that variable is local.  For example:

def foo():
print(s)
if 0:
s = "there"
print(s)

In the function above s _is_not_ initialized in the function foo().
However, foo() does contain an assignment to s, therefore s is local
unless declared global/nonlocal.  [And the first print() will throw an
exception even if there is a value bound to the global name 's'.]

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.

-- 
https://mail.python.org/mailman/listinfo/python-list

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

[Cameron Simpson via Python-list]

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 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.  _Regardless_ of whether that assignment has been 
executed, or gets executed at all (eg in an if-statement branch which 
doesn't fire).


You can use `global` or `nonlocal` to change where Python looks for a 
particular name.


In the code below, `f1` has no local variables and `f2` has an `x` and 
`l1` local variable.


x = 1
l1 = [1, 2, 3]

def f1():
print("f1 ...")
l1[1] = 5   # _not_ an assignment to "l1"
print("in f1, x =", x, "l1 =", l1)

def f2():
print("f2 ...")
x = 3
l1 = [6, 7, 9]  # assignment to "l1"
print("in f2, x =", x, "l1 =", l1)

print("outside, x =", x, "l1 =", l1)
f1()
print("outside after f1, x =", x, "l1 =", l1)
f2()
print("outside after f2, x =", x, "l1 =", l1)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

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

[dn via Python-list]

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




--
Regards,
=dn
--
https://mail.python.org/mailman/listi

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

[Jacob Kruger via Python-list]

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


--
https://mail.python.org/mailman/listinfo/python-list

[issue529750] Circular reference makes Py_Init crash

[admin]

Change by admin :


--
github: None -> 36257

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue516076] Assign boolean value to a weak reference

[admin]

Change by admin :


--
github: None -> 36084

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210866] re group self-reference weird behavior (PR#2)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue474538] Memory (reference) leak in poller.regis

[admin]

Change by admin :


--
github: None -> 35397

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue223398] "Python/C API Reference Manual" erroneous Python/C exception

[admin]

Change by admin :


--
github: None -> 33507

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue488477] Reference counting bugs

[admin]

Change by admin :


--
github: None -> 35654

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue448194] Debuging negative reference counts

[admin]

Change by admin :


--
github: None -> 34898

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue453111] C API Reference bugs

[admin]

Change by admin :


--
github: None -> 35008

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue443059] typo in reference manual

[admin]

Change by admin :


--
github: None -> 34798

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue425836] Reference leak in filter()

[admin]

Change by admin :


--
github: None -> 34525

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue411118] Typo in Python Reference Manual

[admin]

Change by admin :


--
github: None -> 34229

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402652] Reference implementation for PEP 208 (coercion)

[admin]

Change by admin :


--
github: None -> 33546

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue223398] "Python/C API Reference Manual" erroneous Python/C exception

[admin]

Change by admin :


--
github: None -> 33507

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210863] Reference counting problem? (PR#338)

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue402652] Reference implementation for PEP 208 (coercion)

[admin]

Change by admin :


--
github: None -> 33546

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210863] Reference counting problem? (PR#338)

[admin]

Change by admin :


--
github: None -> 32861

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210866] re group self-reference weird behavior (PR#2)

[admin]

Change by admin :


--
github: None -> 32864

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36643] Forward reference is not resolved by dataclasses.fields()

[Eric V. Smith]

Eric V. Smith  added the comment:

I agree with Jelle here: dataclasses shouldn't be calling get_type_hints().

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Thomas Fischbacher]

Thomas Fischbacher  added the comment:

Addendum

Serhiy, I agree that my assessment was incorrect.
It actually is unittest/mock.py that has quite a few 'raise AssertionError' 
that are not coming from an 'assert' keyword statement.

At a deeper level, the problem here is as follows:

Every programming language has to make an awkward choice: either it excludes 
some authors ("must be forklift certified"), or it adds a lot of bureaucratic 
scaffolding to have some mechanisms that allow code authors to enforce API 
contracts (as if this would help to "keep out the tide" of unprincipled code 
authors), or it takes a more relaxed perspective - as also Perl did - of "we 
are all responsible users" / "do not do this because you are not invited, not 
because the owner has a shotgun". I'd call this third approach quite reasonable 
overall, but then the understanding is that "everybody treats documentation as 
binding and knows how to write good documentation".

After all, we need to be able to reason about code, and in order to do that, it 
matters to have guarantees such as for example: "Looking up a nonexistent key 
for a mapping by evaluating the_mapping[the_key] can raise an exception, and 
when it does, that exception is guaranteed to be an instance of KeyError".

Unfortunately, Python on the one hand emphasizes "responsible behavior" - i.e. 
"people know how to write and read documentation, and the written documentation 
creates a shared understanding between its author and reader", but on the other 
hand is often really bad at properly documenting its interfaces. If I had to 
name one thing that really needs fixing with Python, it would be this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

The last leak of a memory block on Windows was fixed by:

New changeset 88872a29f19092d2fde27365af230abd6d301941 by Jeremy Kloth in 
branch 'main':
bpo-47084: Clear Unicode cached representations on finalization (GH-32032)
https://github.com/python/cpython/commit/88872a29f19092d2fde27365af230abd6d301941

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue35577] side_effect mocked method lose reference to instance

[Irit Katriel]

Change by Irit Katriel :


--
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

I concur with Eric. The existing documentation looks pretty clear to me. Any 
exception can be raised explicitly, no need to repeat this.

And unittest.TestCase methods do not raise AssertionError. They raise 
TestCase.failureException, which by default is set to AssertionError. It is 
specified in the corresponding module documentation.

--
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Eric V. Smith]

Eric V. Smith  added the comment:

> I would argue that "The reference documentation for X states that it gets 
> raised under condition Y" generally should be understood as "this is a 
> guarantee that also includes the guarantee that it is not raised under other 
> conditions in correctly written code".

That's definitely not the case in Python, though.

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python

___
Python tracker 
<https://bugs.python.org/issue46972>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Thomas Fischbacher]

Thomas Fischbacher  added the comment:

The documentation of exceptions in the reference is one of the places that 
makes the life of users substantially harder than it ought to be, since the 
documentation appears to not have been written with the intent to give 
guarantees that users can expect correctly written code to follow.

I would argue that "The reference documentation for X states that it gets 
raised under condition Y" generally should be understood as "this is a 
guarantee that also includes the guarantee that it is not raised under other 
conditions in correctly written code".

Other languages often appear to be somewhat stricter w.r.t. interpreting the 
reference documentation as binding for correct code - and for Python, having 
this certainly would help a lot when writing code that can give binding 
guarantees.

--

___
Python tracker 
<https://bugs.python.org/issue46972>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Eric V. Smith]

Eric V. Smith  added the comment:

The documentation doesn't say that assert statements are the only place 
AssertionError is raised, so I don't think it's incorrect.

> From this, one can infer the guarantee "the -O flag will suppress 
> AssertionError exceptions from being raised".

I don't think that follows from what the documentation says. It's only talking 
about assert statements.

This is equivalent to StopIteration: it is commonly raised by exhausting 
iterators, but it can be raised elsewhere. Or KeyError: the docs say "Raised 
when a mapping (dictionary) key is not found in the set of existing keys", but 
I've raised them in my own code.

> An assert[{add reference to `assert` definition}] statement fails, or a unit 
> testing related assert{...}() callable detects an assertion violation.

I think that's also misleading, and not an improvement. Why focus just on 
testing? It can certainly be raised elsewhere.

If anything, I think maybe add a note at the top of the list of Concrete 
Exceptions saying these are common ways these exceptions are raised, but they 
can be raised elsewhere. But I'm -0 on such a change.

--
nosy: +eric.smith

___
Python tracker 
<https://bugs.python.org/issue46972>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46972] Documentation: Reference says AssertionError is raised by `assert`, but not all AssertionErrors are.

[Thomas Fischbacher]

New submission from Thomas Fischbacher :

The Python reference says:

(1) https://docs.python.org/3/library/exceptions.html#concrete-exceptions

exception AssertionError
Raised when an assert statement fails.

(2) https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement

"assert ..." is equivalent to "if __debug__: ..."

>From this, one can infer the guarantee "the -O flag will suppress 
>AssertionError exceptions from being raised".

However, there is code in the Python standard library that does a direct "raise 
AssertionError" (strictly speaking, in violation of (1)), and it is just 
reasonable to assume that other code following the design of that would then 
also want to do a direct "raise AssertionError".

This happens e.g. in many methods defined in: unittest/mock.py

The most appropriate fix here may be to change the documentation to not say:

===
exception AssertionError
Raised when an assert statement fails.
===

but instead:

===
exception AssertionError
An assert[{add reference to `assert` definition}] statement fails, or a unit 
testing related assert{...}() callable detects an assertion violation.
===

--
messages: 414837
nosy: tfish2
priority: normal
severity: normal
status: open
title: Documentation: Reference says AssertionError is raised by `assert`, but 
not all AssertionErrors are.

___
Python tracker 
<https://bugs.python.org/issue46972>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

The initial issue "Python leaks one reference at exit on Windows" is now fixed.

If someone wants to investigate the remaining leak of 1 memory block or the 
negative ref count of PYTHONDUMPREFS=1, please open a separated issue.

--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue46857>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

[Vidhya]

Vidhya  added the comment:

Thanks Alex. I will look into @slateny's patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

[Alex Waygood]

Alex Waygood  added the comment:

Hi Vidhya — @slateny submitted a PR for this issue only two days ago (you can 
see that it's linked to this BPO issue in the "Pull Requests" field). I think 
it would be good to wait until that has been reviewed before doing any work on 
a possible PR for this issue :)

If you'd like to help out with this issue, you'd of course be very welcome to 
submit a review for @slateny's patch.

--
nosy: +AlexWaygood

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

[Vidhya]

Vidhya  added the comment:

If this is still open, I would like to work on this. Please let me know.

--
nosy: +vidhya

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

Ah, with PYTHONDUMPREFS=1 (and without -I), I get a negative ref count:

$ PYTHONDUMPREFS=1 ./python -X showrefcount -c pass
[-10 refs, 0 blocks]

I don't plan to investigate this issue. I'm not using PYTHONDUMPREFS=1 anymore.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Did you also modify initconfig.c?  That part is required as the usual
processing of the environment variable PYTHONDUMPREFS needed to enable
tracing output is ignored with -I

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

I just built Python with --with-trace-refs. On Linux, it works as expected:

$ ./python -I -X showrefcount -c pass 
[0 refs, 0 blocks]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
> initial inc (ob_refcnt == 1) and Py_DECREF to dump on final dec
> (ob_refcnt == 0). Then filter that list (~65K) to find objects not
> dealloc'ed.  Given those names (~200), cross-check with source files
> containing 'ifdef MS_WINDOWS' (and related spellings).

That's smart! Thanks for sharing. It may help to identify future leaks.


> Even using that change, I still have negative refs (but I still have
Py_TRACE_REFS defined)

Ah, maybe testing with Py_TRACE_REFS shows more bugs. I didn't try 
Py_TRACE_REFS recently. Well, if someone finds why it's becoming negative, a 
fix would be welcomed :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ad56919c5ed54523f866e6605a2573ab7b7d5235 by Victor Stinner in 
branch 'main':
bpo-46857: Fix refleak in OSError INIT_ALIAS() (GH-31594)
https://github.com/python/cpython/commit/ad56919c5ed54523f866e6605a2573ab7b7d5235


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: PYT - The expressions described in the Python language reference yield only boolean values

[Peter J. Holzer]

On 2022-02-19 23:28:28 +0100, vanyp wrote:
> *I am trying to learn Python from the grammar given in the Python language
> reference and I am surprised.*
> 
> *Lets start here:*
> 
> *"*
> *6.3.4. Calls*
> 
> A call calls a callable object (e.g., a function
> <https://docs.python.org/3/glossary.html#term-function>) with a possibly
> empty series of arguments
> <https://docs.python.org/3/glossary.html#term-argument>:
> 
> *call *::= |primary 
> <https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-primary>|"("
> [|argument_list 
> <https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-argument_list>|[","]
> | |comprehension 
> <https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-comprehension>|]

With all those links this is very hard to read. Please try to format
your mails in a way that makes them easy to follow.

[...][

> *The first or_test is strange, I assume it should be replaced by expression.*

Nope.

> *But even so I think that the only ways out of the recursion are the or_test
> or the lambda_expr.*
> 
> *And by the grammar, those evaluate to booleans as follows:*

No. A grammar specifies how to parse the text, it doesn't say anything
about the types of these expressions (especially not in a dynamically
typed language like python). 

> *Where did I, or the language reference, go wrong?*

First, you neglected the difference between parsing an expression and
evaluating it.

Secondly, you didn't see the way out. 

For example, let's parse the expression

«f(1+2, 3)»

Can this be a call?

To confirm this, is has to match 

call ::=  primary "(" [argument_list [","] | comprehension] 
")"

which looks plausible, so let's dive in:

primary ::=  atom | attributeref | subscription | slicing | call

atom  ::=  identifier | literal | enclosure

identifier   ::=  xid_start xid_continue*

«f» is an identier which is an atom which is a primary.

Good so far. Now for the argument-list:

argument_list::=  positional_arguments ["," starred_and_keywords] 
...

positional_arguments ::=  positional_item ("," positional_item)*

We have two comma-separated items, good so far. Check «1+2» first

positional_item  ::=  assignment_expression | "*" expression

assignment_expression ::=  [identifier ":="] expression

expression ::=  conditional_expression | lambda_expr

conditional_expression ::=  or_test ["if" or_test "else" expression]

or_test  ::=  and_test | or_test "or" and_test

and_test ::=  not_test | and_test "and" not_test

not_test ::=  comparison | "not" not_test

comparison::=  or_expr (comp_operator or_expr)*

or_expr  ::=  xor_expr | or_expr "|" xor_expr

xor_expr ::=  and_expr | xor_expr "^" and_expr

and_expr ::=  shift_expr | and_expr "&" shift_expr

shift_expr ::=  a_expr | shift_expr ("<<" | ">>") a_expr

a_expr ::=  m_expr | a_expr "+" m_expr | a_expr "-" m_expr

Oof. That was a deep recursion, but we finally found a «+». 
So 1 must be an a_expr and 2 an m_expr. Actually recursing once more reveals
that both can be m_expr:

m_expr ::=  u_expr | m_expr "*" u_expr | m_expr "@" m_expr | ...

u_expr ::=  power | "-" u_expr | "+" u_expr | "~" u_expr

power ::=  (await_expr | primary) ["**" u_expr]

primary ::=  atom | attributeref | subscription | slicing | call

atom  ::=  identifier | literal | enclosure

literal ::=  stringliteral | bytesliteral | integer | floatnumber | 
imagnumber

Ok, they are both integer. 

Then we do basically the same for the second argument and we arrive at
the parse tree:

[warning: fixed width font required]

call
  |
   ---+--
  //  |   \
  ||argument_list  |
  ||positional_arguments   |
  ||   /  | \  |
  ||   positional_item| positional_item|
  ||   assignment_expression  | assignment_expression  |
  ||   expression | expression |
  ||   conditional_expression | conditional_expression |
  ||   or_test| or_test|
  ||   and_test   | and_test   |
  |

[issue46857] Python leaks one reference at exit on Windows

[Jeremy Kloth]

Jeremy Kloth  added the comment:

> ./configure --enabled-shared --with-py-debug --with-trace-refs

(that's what I get for typing from memory):
./configure --enable-shared --with-pydebug --with-trace-refs

> > I proposed GH-31594 to fix this macro.
>
> Even using that change, I still have negative refs (but I still have
> Py_TRACE_REFS defined)

I initially missed the _PySet_Dummy change, with that total refs (w/o
dump_refs) is now 0.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[Jeremy Kloth]

Jeremy Kloth  added the comment:

> Oh wow. How did you find this leak? Did you read all C files and check for 
> code specific to Windows? How did you proceed? Well spotted!

Initially, I modified Py_INCREF to dump the object (addr & tp_name) on
initial inc (ob_refcnt == 1) and Py_DECREF to dump on final dec
(ob_refcnt == 0).
Then filter that list (~65K) to find objects not dealloc'ed.  Given
those names (~200), cross-check with source files containing 'ifdef
MS_WINDOWS' (and related spellings).

> Which command do you type? Do you pass -I option to Python?

For both as -I disables environment lookup:
--- a/Python/initconfig.c
+++ b/Python/initconfig.c
@@ -757,6 +757,7 @@ config_init_defaults(PyConfig *config)
config->user_site_directory = 1;
config->buffered_stdio = 1;
config->pathconfig_warnings = 1;
+   config->dump_refs = 1;
#ifdef MS_WINDOWS
config->legacy_windows_stdio = 0;
#endif

For linux:
./configure --enabled-shared --with-py-debug --with-trace-refs
make build_all
LD_LIBRARY_PATH=$PWD ./python -X showrefcount -I -c pass

For Windows:
Add "#define Py_TRACE_REFS 1" to PC\pyconfig.h
build.bat -d -e
amd64\python_d.exe -X showrefcount -I -c pass

> I proposed GH-31594 to fix this macro.

Even using that change, I still have negative refs (but I still have
Py_TRACE_REFS defined)

--
nosy: +jeremy.kloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:

> Good news, the difference on Windows was easy enough to find, bad news total 
> refs are now negative!

Oh wow. How did you find this leak? Did you read all C files and check for code 
specific to Windows? How did you proceed? Well spotted!


>  #define INIT_ALIAS(NAME, TYPE)

I proposed GH-31594 to fix this macro.


> Strange as well, when using dump_refs, the total refs are much more negative 
> (-12 linux, -13 Windows)

Which command do you type? Do you pass -I option to Python?

With my PR, I get exactly 0 on Linux:

$ ./python -I -X showrefcount -c pass
[0 refs, 0 blocks]


> Note that an allocated block is still leaking.

Right, with my PR, I now get 1 leaked memory block on Windows:

> python -I -X showrefcount -c pass   
[0 refs, 1 blocks]

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

Change by STINNER Victor :


--
pull_requests: +29717
pull_request: https://github.com/python/cpython/pull/31594

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Note that an allocated block is still leaking.

Strange as well, when using dump_refs, the total refs are much more negative 
(-12 linux, -13 Windows)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[Jeremy Kloth]

Jeremy Kloth  added the comment:

Good news, the difference on Windows was easy enough to find, bad news total 
refs are now negative!

--- a/Objects/exceptions.c
+++ b/Objects/exceptions.c
@@ -3647,8 +3647,7 @@ _PyBuiltins_AddExceptions(PyObject *bltinmod)

 #define INIT_ALIAS(NAME, TYPE) \
 do { \
-Py_INCREF(PyExc_ ## TYPE); \
-Py_XDECREF(PyExc_ ## NAME); \
+Py_XSETREF(PyExc_ ## NAME, PyExc_ ## TYPE); \
 PyExc_ ## NAME = PyExc_ ## TYPE; \
 if (PyDict_SetItemString(mod_dict, # NAME, PyExc_ ## NAME)) { \
 return -1; \

As the PyExc_* aliases just deprecated names for PyExc_OSError, there is no 
need to increment their refcounts.  Or they could be decremented in Fini().  Or 
they could finally be removed entirely.

--
nosy: +jkloth

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

STINNER Victor  added the comment:


New changeset ea9612a17bc60d44e0058f525d3c02a91c439cef by Victor Stinner in 
branch 'main':
bpo-46857: Fix test_embed.test_no_memleak() on Windows (GH-31589)
https://github.com/python/cpython/commit/ea9612a17bc60d44e0058f525d3c02a91c439cef


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

Change by STINNER Victor :


--
keywords: +patch
pull_requests: +29712
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31589

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46857] Python leaks one reference at exit on Windows

[STINNER Victor]

New submission from STINNER Victor :

"./python -X showrefcount -I -c pass" returns "[0 refs, 0 blocks]" as expected 
on Linux: Python doesn't leak any reference nor memory block.

But on Windows, it still leaks 1 reference (and 1 memory block)!

vstinner@DESKTOP-DK7VBIL C:\vstinner\python\main>python -X showrefcount -I -c 
pass
[1 refs, 1 blocks]

I recently added a test in test_embed which now fails on Windows.

See bpo-1635741 "Py_Finalize() doesn't clear all Python objects at exit" for 
the context.

--
components: Interpreter Core
messages: 414020
nosy: vstinner
priority: normal
severity: normal
status: open
title: Python leaks one reference at exit on Windows
versions: Python 3.11

___
Python tracker 
<https://bugs.python.org/issue46857>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29687
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31565

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

Some specific points from the document:

"While the PLR explicitly states that “x < y calls x.__lt__(y)” [20, 3.3.1.] 
this is actually false." They had to read the implementation to actually figure 
out how this works.

"If no expression is provided, the PLR states that “the last exception that was 
active in the current scope” should be re-raised. Unfortunately, the PLR stays 
unspecific on what it means for an exception to be “the last exception that was 
active in the current scope.”"

"The description of this name binding and resolution process in the PLR [20, 
4.2.] is unfortunately not particularly clear"

"While generator objects seem not to be specified as part of the PLR, the 
documentation of the inspect module5 describes them."

(I didn't read the whole thing, but searched for "PLR".)

Here's a few similar things I noticed while reading through the reference 
recently:

- 
https://docs.python.org/3.10/reference/datamodel.html#the-standard-type-hierarchy
 is supposed to be a list of primitive types but has a few problems:
  - Lists "numbers.Number" as a standard type, when it's an ABC that's really 
not part of the core language
  - Lists "I/O objects" as a kind of standard object, but there are many kinds 
of file-like objects, and I'd argue they're not part of the core language, but 
of the standard library.
  - On the other hand, some builtin types (range, map, filter, zip) are not 
listed.
- https://docs.python.org/3.10/reference/expressions.html#subscriptions doesn't 
actually give the rules about when __class_getitem__ is called vs. __getitem__. 
That's in 
https://docs.python.org/3.10/reference/datamodel.html#class-getitem-versus-getitem.
- The text at https://docs.python.org/3.10/reference/expressions.html#calls 
doesn't cover positional-only parameters.

--
nosy: +Jelle Zijlstra

___
Python tracker 
<https://bugs.python.org/issue46754>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Guido van Rossum]

Guido van Rossum  added the comment:

Another:

- The description of this name binding and resolution process
  in the PLR [20, §4.2.] is unfortunately not particularly clear.

(I found this to be the case too, and wrote up what I found:
https://gvanrossum.github.io/formal/scopesblog.html
Hopefully it matches what Kohl derived.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Guido van Rossum]

Guido van Rossum  added the comment:

A few examples of issues brought up by Kohl:

- While the PLR explicitly states that “x < y calls x.__lt__(y)”
  [20, §3.3.1.] this is actually false.
  There are cases where x < y does not call x.__lt__(y)
  and there are other cases where x.__lt__(y) is called
  but more than that happens.

- If no expression is provided, the PLR states that
  “the last exception that was active in the current scope”
  should be re-raised. Unfortunately, the PLR stays
  unspecific on what it means for an exception to be
  “the last exception that was active in the current scope.
  [...]
  Instead, raise re-raises the exception that *is active*
  in the respective execution context

(Perhaps unrelated, but indicative of how out of date the PLR is: in 
executionmodel.rst there's still a mention of and even an index entry for 
restricted execution, a feature that was removed in some early Python 2 
release.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Dong-hee Na]

Change by Dong-hee Na :


--
nosy: +corona10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eric Snow]

Eric Snow  added the comment:

Thanks for the updates, Eddie.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Eddie Elizondo  added the comment:

It seems that we are back on track with perf being back to neutral!

I've created 4 new PRs. Each with an optimization applied on top of the 
baseline introduction of instance immortalization.

The main PR 19474 currently stands at around 4%, after rebasing past Eric's PR 
30928 it went down to 3%.

This is the list of optimizations that I used to get some performance back:
* Immortalizing Interned Strings (PR 31488): 1% regression
* Immortalizing Runtime Heap After Startup (PR 31489): 0% regression
* Immortalizing Modules After Import (PR 31490): 1% regression
* Combined Optimizations (PR 31491): 0% improvement

All the PRs contain the results of the pyperformance benchmarks and they should 
each stand on their own in case we want to go for a subset of these 
optimizations rather than all of them. Make sure to look at each PR to read the 
implementation details.

For testing, in every PR I made sure all the tests were passing on my local 
environment. Though I do expect some failures happening in non-linux 
environments. I'll be fixing these over the next couple of days.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Inada Naoki]

Inada Naoki  added the comment:

All of these optimizations should be disabled by default.

* It will cause leak when Python is embedded.
* Even for python command, it will break __del__ and weakref callbacks.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Change by Eddie Elizondo :


--
pull_requests: +29621
pull_request: https://github.com/python/cpython/pull/31491

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Change by Eddie Elizondo :


--
pull_requests: +29620
pull_request: https://github.com/python/cpython/pull/31490

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Change by Eddie Elizondo :


--
pull_requests: +29619
pull_request: https://github.com/python/cpython/pull/31489

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Change by Eddie Elizondo :


--
pull_requests: +29618
pull_request: https://github.com/python/cpython/pull/31488

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: PYT - The expressions described in the Python language reference yield only boolean values

[Chris Angelico]

On Sun, 20 Feb 2022 at 12:00, vanyp  wrote:
>
> *I am trying to learn Python from the grammar given in the Python
> language reference and I am surprised.*
>

The grammar is not the best way to learn the language. It'll show you
a lot of unnecessary details. For technical reasons, Python's grammar
defines expressions in a nested way, but the way most programmers want
to think of it is that there is operator precedence.

https://docs.python.org/3/reference/expressions.html#operator-precedence

The grammar considers that these are different types of expressions,
but they're not really different in actual usage.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

PYT - The expressions described in the Python language reference yield only boolean values

[vanyp]

*I am trying to learn Python from the grammar given in the Python 
language reference and I am surprised.*


*Lets start here:*

*"*
*6.3.4. Calls*

A call calls a callable object (e.g., a function 
<https://docs.python.org/3/glossary.html#term-function>) with a possibly 
empty series of arguments 
<https://docs.python.org/3/glossary.html#term-argument>:


*call *::= |primary 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-primary>|"(" [|argument_list 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-argument_list>|[","] | |comprehension 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-comprehension>|] ")"
*argument_list *::= |positional_arguments 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-positional_arguments>|["," |starred_and_keywords 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-starred_and_keywords>|]
["," |keywords_arguments 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-keywords_arguments>|]
| |starred_and_keywords 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-starred_and_keywords>|["," |keywords_arguments 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-keywords_arguments>|]
| |keywords_arguments 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-keywords_arguments>|

*positional_arguments*::= positional_item ("," positional_item)*
*positional_item *::= |assignment_expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-assignment_expression>|| "*" |expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression>|

*"*

*continued by:*
*"*
*6.12. Assignment expressions*
*assignment_expression*::= [|identifier 
<https://docs.python.org/3/reference/lexical_analysis.html#grammar-token-python-grammar-identifier>|":="] |expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression>|

*"*

*Now I look at the following productions:*

*"*
*6.13. Conditional expressions*
*conditional_expression*::= |or_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-or_test>|["if" |or_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-or_test>|"else" |expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression>|]
*expression *::= |conditional_expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-conditional_expression>|| |lambda_expr 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-lambda_expr>|

*"*

*The first or_test is strange, I assume it should be replaced by expression.*

*But even so I think that the only ways out of the recursion are the 
or_test or the lambda_expr.*


*And by the grammar, those evaluate to booleans as follows:*


*"*
*6.14. Lambdas*
*lambda_expr*::= "lambda" [|parameter_list 
<https://docs.python.org/3/reference/compound_stmts.html#grammar-token-python-grammar-parameter_list>|] ":" |expression 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-expression>|

*"*

*and I conclude that the only way out of that branch is also or_test.*

*I then look at or_test:*

*"*
*6.11. Boolean operations*
*or_test *::= |and_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-and_test>|| |or_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-or_test>|"or" |and_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-and_test>|
*and_test*::= |not_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-not_test>|| |and_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-and_test>|"and" |not_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-not_test>|
*not_test*::= |comparison 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-comparison>|| "not" |not_test 
<https://docs.python.org/3/reference/expressions.html#grammar-token-python-grammar-not_test>|

*"*

*and the ony way out is comparison, which by the semantics should return 
a boolean.*


*Looking at comparison

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Alex Waygood]

Change by Alex Waygood :


--
keywords:  -patch
nosy:  -AlexWaygood
stage: patch review -> 

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Alex Waygood]

Change by Alex Waygood :


--
pull_requests:  -29560

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Alex Waygood]

Change by Alex Waygood :


--
keywords: +patch
nosy: +AlexWaygood
nosy_count: 1.0 -> 2.0
pull_requests: +29560
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/29479

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46754] Improve Python Language Reference based on [Köhl 2020]

[Guido van Rossum]

New submission from Guido van Rossum :

In https://arxiv.org/pdf/2109.03139.pdf ("M Köhl, An Executable Structural 
Operational Formal Semantics for Python, Master Thesis 2020 Saarland 
University) there are some observations on cases where the Language Reference 
(referred to as PLR) is ambiguous or incorrect.

Somebody should go over the thesis, collect the issues, and then we can update 
the language reference.

See also 
https://github.com/faster-cpython/ideas/issues/208#issuecomment-1039612432

--
messages: 413275
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: Improve Python Language Reference based on [Köhl 2020]

___
Python tracker 
<https://bugs.python.org/issue46754>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Inada Naoki]

Inada Naoki  added the comment:

I think making more objects immortal by default will reduce the gap, although I 
am not sure it can be 2%. (I guess 3% and I think it is acceptable gap.)

* Code attributes (contents of co_consts, co_names, etc...) in deep frozen 
modules.
  * only if subinterpreter shares them.
* Statically allocated strings (previously _Py_IDENTIFIER)

To reduce gap more, we need to reduce Python stack operation in ceval in some 
way.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eddie Elizondo]

Eddie Elizondo  added the comment:

@eric.snow great to hear about this update! I'll start looking at some of the 
techniques that we talked about to improve performance, I'm optimistic that 
we'll be able to close down the gap to 2%.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[Eric Snow]

Eric Snow  added the comment:

@Eddie, what can I do to push this forward?  FYI, in addition to the python-dev 
thread a few weeks back, I've brought the matter up with the steering council. 
[1]

Also, if we can get back to performance-neutral (currently at about 4% slower) 
then there would be a lot less controversy.  Even at 2% it may be enough.


[1] https://github.com/python/steering-council/issues/103

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45555] Object stays alive for weak reference if an exception happens in constructor

[Irit Katriel]

Irit Katriel  added the comment:

I don't think there's any suitable place in the documentation to describe this. 
Like Pablo says, it is one of the many ways in which you can create a reference 
to an object.

--
nosy: +iritkatriel
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue4>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36643] Forward reference is not resolved by dataclasses.fields()

[Jelle Zijlstra]

Jelle Zijlstra  added the comment:

I don't think we should merge this change. get_type_hints() is fragile and full 
of corner cases around using the right globals and locals dictionaries. 
dataclasses shouldn't execute it implicitly for you.

--
nosy: +Jelle Zijlstra
versions: +Python 3.11 -Python 3.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting and immortal objects

[STINNER Victor]

Change by STINNER Victor :


--
title: Fixing Copy on Writes from reference counting -> Fixing Copy on Writes 
from reference counting and immortal objects

___
Python tracker 
<https://bugs.python.org/issue40255>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40255] Fixing Copy on Writes from reference counting

[STINNER Victor]

STINNER Victor  added the comment:

I just want to say that GOOGLE_ETERNAL_REFCOUNT_SUPPORT is a cool name :-D I 
love "eternal refcount"!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue46379] itertools.product reference implementation creates temporaries

[Markus Wallerberger]

Markus Wallerberger  added the comment:

> To a person well versed in recursion and in generator chains it makes sense 
> but not so much for anyone else.

There I pretty much fundamentally disagree.  I find the version in the docs 
much more magical in the sense that it builds up "laterally", i.e., 
level-by-level, rather than element-by-element.

Also, I think from a functional programming perspective, which, let's face it, 
is what these iteration/generator tools are really modelling, a recursive 
version is much more natural.  It also generalizes nicely to other problems 
which people may be having -- so it has the added benefit of explaining the 
code and teaching people useful patterns.

Take the itertools.permutation as an example:  writing that as it was in the 
reference implementation the code is IMHO pretty opaque and hard to reason 
about.  Write it in a recursive style and both its working and correctness is 
immediately obvious.

>  Plus it is hard to step through by hand to see what it is doing.

This I agree with.

Anyway, thanks for taking the time to explain the rejection.

--

___
Python tracker 
<https://bugs.python.org/issue46379>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com