Re: Mailing-Lists (pointer)

[Milan Glacier]

On 01/10/23 11:33, dn wrote:

On 10/01/2023 08.46, Stefan Ram wrote:

  If anyone is interested: In "comp.misc", there's a discussion
  about the use of mailing lists in software development.
  Subject: An objective criteria for deprecating community platforms
  (I did not create this subject!)


(and I don't read comp.misc)


There is an increasingly relevant question though: how do we 'reach' 
as many people as possible, without diluting the (community) value of 
responses?


At one time, if you wanted to talk/hear certain folk you felt 
compelled to join Twitter (see also AOL, MySpace, Facebook, ...). 
Recently many more people have realised that a single, centralised, 
(and corporately-owned) 'service' has its down-sides.


If there are too many channels for communication, it increases the 
difficulty for any one person to 'keep up', eg python-list and 
python-forum.


I remember there was once a hot thread in this python-list discussing
about abandoning this mailing list and move all the discussion to the
forum.

Has anyone known about any status quo about the decision?

I personally strongly preferred mailing list. It is open-format,
open-archive and easy to download and retrive information using your
preferred indexing tools and homemade scripts.


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

Re: Mailing-Lists (pointer)

[Chris Green]

dn  wrote:
[snip]

> See also the wisdom of enabling comp.lang.python and python-list as 
> 'mirrors', enabling those who prefer one mechanism/client to another, 
> yet maintaining a single 'community'.
> 
Yes, this is important I think.  Plus, if possible, if it's decided to
move to a forum format make that accessible by E-Mail.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

[Abhay Singh]

Here is the entire code snippet of the same.

Please help

def change_flag(top_frame, bottom_frame, button1, button2, button3, button4, 
controller): global counter, canvas, my_image, chosen, flag, directory 
canvas.delete('all') button5['state'] = DISABLED counter += 1

chosen, options_text = function_options()
right_answer_flag = get_right_answer_flag(chosen, options_text)
#pdb.set_trace()

try:
location = directory + chosen + format_image
except:
controller.show_frame(PlayAgainExit)

my_image = PhotoImage(file=location)
canvas.create_image(160, 100, anchor=CENTER, image=my_image)

button1["text"] = options_text[0]
button2["text"] = options_text[1]
button3["text"] = options_text[2]
button4["text"] = options_text[3]

button1['state'] = NORMAL
button2['state'] = NORMAL
button3['state'] = NORMAL
button4['state'] = NORMAL
##

button5 = Button(
next_frame,
width=20,
text="next",
fg="black",
#command=lambda: 
change_flag(top_frame,bottom_frame,button1,button2,button3,button4,controller))
command=Thread(target=change_flag, args 
=(top_frame,bottom_frame,button1,button2,button3,button4,controller)).start)

button5.pack(side=RIGHT, padx=5, pady=5)

Thanks,
Abhay
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

[MRAB]

On 2023-01-10 14:57, Abhay Singh wrote:

Here is the entire code snippet of the same.

Please help

def change_flag(top_frame, bottom_frame, button1, button2, button3, button4, 
controller): global counter, canvas, my_image, chosen, flag, directory 
canvas.delete('all') button5['state'] = DISABLED counter += 1

chosen, options_text = function_options()
right_answer_flag = get_right_answer_flag(chosen, options_text)
#pdb.set_trace()

try:
 location = directory + chosen + format_image
except:
 controller.show_frame(PlayAgainExit)
 
my_image = PhotoImage(file=location)

canvas.create_image(160, 100, anchor=CENTER, image=my_image)

button1["text"] = options_text[0]
button2["text"] = options_text[1]
button3["text"] = options_text[2]
button4["text"] = options_text[3]

button1['state'] = NORMAL
button2['state'] = NORMAL
button3['state'] = NORMAL
button4['state'] = NORMAL
##

 button5 = Button(
 next_frame,
 width=20,
 text="next",
 fg="black",
 #command=lambda: 
change_flag(top_frame,bottom_frame,button1,button2,button3,button4,controller))
 command=Thread(target=change_flag, args 
=(top_frame,bottom_frame,button1,button2,button3,button4,controller)).start)
 
 button5.pack(side=RIGHT, padx=5, pady=5)



The formatting is messed up, which doesn't help.

Some points:

You have a 'bare' except, i.e. "except:". Don't do that. It swallows 
_all_ exceptions and can hide bugs.


I don't like how you're passing Thread...start as an argument. IMHO, it 
would be better/cleaner to pass a plain function, even if the only thing 
that function does is to start the thread.


I can't tell what 'change_flag' is doing because of the formatting 
issue. Is it doing GUI stuff? In a thread? If yes, don't do that. The 
GUI doesn't like that. Only the main thread should do GUI stuff.

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

To clarify how Python handles two equal objects

[Jen Kris via Python-list]

I am writing a spot speedup in assembly language for a short but 
computation-intensive Python loop, and I discovered something about Python 
array handling that I would like to clarify.  

For a simplified example, I created a matrix mx1 and assigned the array arr1 to 
the third row of the matrix:

mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
arr1 = mx1[2]

The pointers to these are now the same:

ida = id(mx1[2]) - 140260325306880
idb = id(arr1) - 140260325306880

That’s great because when I encounter this in assembly or C, I can just borrow 
the pointer to row 3 for the array arr1, on the assumption that they will 
continue to point to the same object.  Then when I do any math operations in 
arr1 it will be reflected in both arrays because they are now pointing to the 
same array:

arr1[0] += 2
print(mx1[2]) - [9, 8, 9]
print(arr1) - [9, 8, 9]

Now mx1 looks like this:

[ 1, 2, 3 ]
[ 4, 5, 6 ]
[ 9, 8, 9 ]

and it stays that way for remaining iterations.  

But on the next iteration we assign arr1 to something else:

arr1 = [ 10, 11, 12 ]
idc = id(arr1) – 140260325308160
idd = id(mx1[2]) – 140260325306880

Now arr1 is no longer equal to mx1[2], and any subsequent operations in arr1 
will not affect mx1.  So where I’m rewriting some Python code in a low level 
language, I can’t assume that the two objects are equal because that equality 
will not remain if either is reassigned.  So if I do some operation on one 
array I have to conform the two arrays for as long as they remain equal, I 
can’t just do it in one operation because I can’t rely on the objects remaining 
equal. 

Is my understanding of this correct?  Is there anything I’m missing? 

Thanks very much. 

Jen


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

Re: To clarify how Python handles two equal objects

[Chris Angelico]

On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
 wrote:
>
> I am writing a spot speedup in assembly language for a short but 
> computation-intensive Python loop, and I discovered something about Python 
> array handling that I would like to clarify.
>
> For a simplified example, I created a matrix mx1 and assigned the array arr1 
> to the third row of the matrix:
>
> mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
> arr1 = mx1[2]
>
> The pointers to these are now the same:
>
> ida = id(mx1[2]) - 140260325306880
> idb = id(arr1) - 140260325306880
>
> That’s great because when I encounter this in assembly or C, I can just 
> borrow the pointer to row 3 for the array arr1, on the assumption that they 
> will continue to point to the same object.  Then when I do any math 
> operations in arr1 it will be reflected in both arrays because they are now 
> pointing to the same array:
>

That's not an optimization; what you've done is set arr1 to be a
reference to that object.

> But on the next iteration we assign arr1 to something else:
>
> arr1 = [ 10, 11, 12 ]
> idc = id(arr1) – 140260325308160
> idd = id(mx1[2]) – 140260325306880
>
> Now arr1 is no longer equal to mx1[2], and any subsequent operations in arr1 
> will not affect mx1.

Yep, you have just set arr1 to be a completely different object.

> So where I’m rewriting some Python code in a low level language, I can’t 
> assume that the two objects are equal because that equality will not remain 
> if either is reassigned.  So if I do some operation on one array I have to 
> conform the two arrays for as long as they remain equal, I can’t just do it 
> in one operation because I can’t rely on the objects remaining equal.
>
> Is my understanding of this correct?  Is there anything I’m missing?
>

Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way.

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

Re: To clarify how Python handles two equal objects

[Jen Kris via Python-list]

Thanks for your comments.  I'd like to make one small point.  You say:

"Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way."

But where they have been set to the same object, an operation on one will 
affect the other as long as they are equal (in Python).  So I will have to 
conform them in those cases because Python will reflect any math operation in 
both the array and the matrix.  



Jan 10, 2023, 12:28 by ros...@gmail.com:

> On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
>  wrote:
>
>>
>> I am writing a spot speedup in assembly language for a short but 
>> computation-intensive Python loop, and I discovered something about Python 
>> array handling that I would like to clarify.
>>
>> For a simplified example, I created a matrix mx1 and assigned the array arr1 
>> to the third row of the matrix:
>>
>> mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
>> arr1 = mx1[2]
>>
>> The pointers to these are now the same:
>>
>> ida = id(mx1[2]) - 140260325306880
>> idb = id(arr1) - 140260325306880
>>
>> That’s great because when I encounter this in assembly or C, I can just 
>> borrow the pointer to row 3 for the array arr1, on the assumption that they 
>> will continue to point to the same object.  Then when I do any math 
>> operations in arr1 it will be reflected in both arrays because they are now 
>> pointing to the same array:
>>
>
> That's not an optimization; what you've done is set arr1 to be a
> reference to that object.
>
>> But on the next iteration we assign arr1 to something else:
>>
>> arr1 = [ 10, 11, 12 ]
>> idc = id(arr1) – 140260325308160
>> idd = id(mx1[2]) – 140260325306880
>>
>> Now arr1 is no longer equal to mx1[2], and any subsequent operations in arr1 
>> will not affect mx1.
>>
>
> Yep, you have just set arr1 to be a completely different object.
>
>> So where I’m rewriting some Python code in a low level language, I can’t 
>> assume that the two objects are equal because that equality will not remain 
>> if either is reassigned.  So if I do some operation on one array I have to 
>> conform the two arrays for as long as they remain equal, I can’t just do it 
>> in one operation because I can’t rely on the objects remaining equal.
>>
>> Is my understanding of this correct?  Is there anything I’m missing?
>>
>
> Assignment in Python is a matter of object references. It's not
> "conform them as long as they remain equal". You'll have to think in
> terms of object references the entire way.
>
> ChrisA
> -- 
> https://mail.python.org/mailman/listinfo/python-list
>

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

Re: To clarify how Python handles two equal objects

[Chris Angelico]

On Wed, 11 Jan 2023 at 07:41, Jen Kris  wrote:
>
>
> Thanks for your comments.  I'd like to make one small point.  You say:
>
> "Assignment in Python is a matter of object references. It's not
> "conform them as long as they remain equal". You'll have to think in
> terms of object references the entire way."
>
> But where they have been set to the same object, an operation on one will 
> affect the other as long as they are equal (in Python).  So I will have to 
> conform them in those cases because Python will reflect any math operation in 
> both the array and the matrix.
>

It's not that "an operation on one will affect the other" - it's that,
no matter how you refer to that object, you're affecting *that one
single object*. It's like when you're washing a window; the inside and
outside of the window are the exact same window, so regardless of
where you're looking at it from, it's the same single window and
changes affect it equally.

So you shouldn't have to replicate any changes. What should be
happening is that you find the right object to mutate, and mutate
that. For example:

stuff = [[1, 2, 3], [4, 5, 6]]
stuff.append(stuff[0])
print(stuff)

You now have two references to the same list, inside another list. Any
change to stuff[0] is a change to stuff[2], because they're the exact
same list. When you append "a reference to this list over here" (which
you found by asking for stuff[0]) to the outer list, you get that
list.

That's Python's object model, and trying to cheat it by copying
changes is just going to cause untold nightmares of desynchronization.

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

Python 3.12.0 alpha 4 released

[Thomas Wouters]

I'm pleased to announce the release of Python 3.12 alpha 4.

https://www.python.org/downloads/release/python-3120a4/

*This is an early developer preview of Python 3.12*.

Major new features of the 3.12 series, compared to 3.11

Python 3.12 is still in development. This release, 3.12.0a4 is the fourth
of seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2023-05-08) and, if necessary, may be modified or deleted up
until the release candidate phase (2023-07-31). Please keep in mind that
this is a preview release and its use is *not *recommended for production
environments.

Many new features for Python 3.12 are still being planned and written.
Among the new major new features and changes so far:

   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   ). The setuptools package (installed
   by default in virtualenvs and many other places) continues to provide the
   distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - (Hey,* fellow core developer*, if a feature you find important is
   missing from this list, let Thomas know .)


For more details on the changes to Python 3.12, see What's new in Python
3.12 . The next pre-release
of Python 3.12 will be 3.12.0a5, currently scheduled for 2023-02-06.

More resources

Online Documentation .
PEP 693 , the Python 3.12
Release Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .

And now for something completely different

Two haikus apt, as Python's development springs ever forward.

I write, erase, rewrite
> Erase again, and then
> A poppy blooms.


Haiku by Katsushika Hokusai.

O snail
> Climb Mount Fuji,
> But slowly, slowly!


Haiku by Kobayashi Issa.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from chilly Amsterdam,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower
-- 
Thomas Wouters 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Mailing-Lists (pointer)

[Dieter Maurer]

Chris Green wrote at 2023-1-10 08:45 +:
> ...
>Yes, this is important I think.  Plus, if possible, if it's decided to
>move to a forum format make that accessible by E-Mail.

I much prefer a mailing list over an http based service.
With mailing lists, all interesting messages arrive in my email
reader, i.e. at a central place; with http based services,
I have to visit the various sites to learn whether there is
relevant new information.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To clarify how Python handles two equal objects

[Weatherby,Gerard]

For clarification, equality is not identity in Python. e.g.

x = 7
y = 7.0
print(x == y)
print(x is y)

Will return
True
False

Full explanation at 
https://docs.python.org/3/reference/expressions.html#comparisons


From: Python-list  on 
behalf of Chris Angelico 
Date: Tuesday, January 10, 2023 at 3:47 PM
To: Python List 
Subject: Re: To clarify how Python handles two equal objects
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On Wed, 11 Jan 2023 at 07:41, Jen Kris  wrote:
>
>
> Thanks for your comments.  I'd like to make one small point.  You say:
>
> "Assignment in Python is a matter of object references. It's not
> "conform them as long as they remain equal". You'll have to think in
> terms of object references the entire way."
>
> But where they have been set to the same object, an operation on one will 
> affect the other as long as they are equal (in Python).  So I will have to 
> conform them in those cases because Python will reflect any math operation in 
> both the array and the matrix.
>

It's not that "an operation on one will affect the other" - it's that,
no matter how you refer to that object, you're affecting *that one
single object*. It's like when you're washing a window; the inside and
outside of the window are the exact same window, so regardless of
where you're looking at it from, it's the same single window and
changes affect it equally.

So you shouldn't have to replicate any changes. What should be
happening is that you find the right object to mutate, and mutate
that. For example:

stuff = [[1, 2, 3], [4, 5, 6]]
stuff.append(stuff[0])
print(stuff)

You now have two references to the same list, inside another list. Any
change to stuff[0] is a change to stuff[2], because they're the exact
same list. When you append "a reference to this list over here" (which
you found by asking for stuff[0]) to the outer list, you get that
list.

That's Python's object model, and trying to cheat it by copying
changes is just going to cause untold nightmares of desynchronization.

ChrisA
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!iORRBJFui8Kn7WzY0ZRPfSdGKcmnDV81UffITsv7ExEAbBXEtv86qC3BOvGaDXCAY708Q4QbDXh0_wo7$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: To clarify how Python handles two equal objects

[MRAB]

On 2023-01-10 20:41, Jen Kris via Python-list wrote:


Thanks for your comments.  I'd like to make one small point.  You say:

"Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way."

But where they have been set to the same object, an operation on one will 
affect the other as long as they are equal (in Python).  So I will have to 
conform them in those cases because Python will reflect any math operation in 
both the array and the matrix.

It's not a 2D matrix, it's a 1D list containing references to 1D lists, 
each of which contains references to Python ints.


In CPython, references happen to be pointers, but that's just an 
implementation detail.





Jan 10, 2023, 12:28 by ros...@gmail.com:


On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
 wrote:



I am writing a spot speedup in assembly language for a short but 
computation-intensive Python loop, and I discovered something about Python 
array handling that I would like to clarify.

For a simplified example, I created a matrix mx1 and assigned the array arr1 to 
the third row of the matrix:

mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
arr1 = mx1[2]

The pointers to these are now the same:

ida = id(mx1[2]) - 140260325306880
idb = id(arr1) - 140260325306880

That’s great because when I encounter this in assembly or C, I can just borrow 
the pointer to row 3 for the array arr1, on the assumption that they will 
continue to point to the same object.  Then when I do any math operations in 
arr1 it will be reflected in both arrays because they are now pointing to the 
same array:



That's not an optimization; what you've done is set arr1 to be a
reference to that object.


But on the next iteration we assign arr1 to something else:

arr1 = [ 10, 11, 12 ]
idc = id(arr1) – 140260325308160
idd = id(mx1[2]) – 140260325306880

Now arr1 is no longer equal to mx1[2], and any subsequent operations in arr1 
will not affect mx1.



Yep, you have just set arr1 to be a completely different object.


So where I’m rewriting some Python code in a low level language, I can’t assume 
that the two objects are equal because that equality will not remain if either 
is reassigned.  So if I do some operation on one array I have to conform the 
two arrays for as long as they remain equal, I can’t just do it in one 
operation because I can’t rely on the objects remaining equal.

Is my understanding of this correct?  Is there anything I’m missing?



Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way.

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





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

Re: To clarify how Python handles two equal objects

[Roel Schroeven]

Jen Kris via Python-list schreef op 10/01/2023 om 21:41:

But where they have been set to the same object, an operation on one will 
affect the other as long as they are equal (in Python).
As long as they are *identical*, not equal. Identical as in having the 
same identity as Python defines it.
I advise you to read Ned Batchelder's explanation about names and values 
in Python, or watch his presentation, to get a good understanding. See 
https://nedbatchelder.com/text/names1.html


--
"Don't Panic."
-- Douglas Adams, The Hitchhiker's Guide to the Galaxy

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

Re: Mailing-Lists (pointer)

[Cameron Simpson]

On 10Jan2023 08:45, Chris Green  wrote:

dn  wrote:

See also the wisdom of enabling comp.lang.python and python-list as
'mirrors', enabling those who prefer one mechanism/client to another,
yet maintaining a single 'community'.


Yes, this is important I think.  Plus, if possible, if it's decided to
move to a forum format make that accessible by E-Mail.


There's a Discourse forum over at discuss.python.org. I use it in 
"mailing list mode" and do almost all my interactions via email, exactly 
as I do for python-list. Posts come to me and land in the same local 
mail folder I use for python-list. My replies land on the forum as 
expected (and of course also go by email to those members who have 
turned that mode on).


So I'm using both the new forum and the currently mailing list still, 
and broadly in exactly the same way.


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

Re: To clarify how Python handles two equal objects

[Thomas Passin]

Just to add a possibly picky detail to what others have said, Python 
does not have an "array" type.  It has a "list" type, as well as some 
other, not necessarily mutable, sequence types.


If you want to speed up list and matrix operations, you might use NumPy. 
 Its arrays and matrices are heavily optimized for fast processing and 
provide many useful operations on them.  No use calling out to C code 
yourself when NumPy has been refining that for many years.


On 1/10/2023 4:10 PM, MRAB wrote:

On 2023-01-10 20:41, Jen Kris via Python-list wrote:


Thanks for your comments.  I'd like to make one small point.  You say:

"Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way."

But where they have been set to the same object, an operation on one 
will affect the other as long as they are equal (in Python).  So I 
will have to conform them in those cases because Python will reflect 
any math operation in both the array and the matrix.


It's not a 2D matrix, it's a 1D list containing references to 1D lists, 
each of which contains references to Python ints.


In CPython, references happen to be pointers, but that's just an 
implementation detail.





Jan 10, 2023, 12:28 by ros...@gmail.com:


On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
 wrote:



I am writing a spot speedup in assembly language for a short but 
computation-intensive Python loop, and I discovered something about 
Python array handling that I would like to clarify.


For a simplified example, I created a matrix mx1 and assigned the 
array arr1 to the third row of the matrix:


mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
arr1 = mx1[2]

The pointers to these are now the same:

ida = id(mx1[2]) - 140260325306880
idb = id(arr1) - 140260325306880

That’s great because when I encounter this in assembly or C, I can 
just borrow the pointer to row 3 for the array arr1, on the 
assumption that they will continue to point to the same object.  
Then when I do any math operations in arr1 it will be reflected in 
both arrays because they are now pointing to the same array:




That's not an optimization; what you've done is set arr1 to be a
reference to that object.


But on the next iteration we assign arr1 to something else:

arr1 = [ 10, 11, 12 ]
idc = id(arr1) – 140260325308160
idd = id(mx1[2]) – 140260325306880

Now arr1 is no longer equal to mx1[2], and any subsequent operations 
in arr1 will not affect mx1.




Yep, you have just set arr1 to be a completely different object.

So where I’m rewriting some Python code in a low level language, I 
can’t assume that the two objects are equal because that equality 
will not remain if either is reassigned.  So if I do some operation 
on one array I have to conform the two arrays for as long as they 
remain equal, I can’t just do it in one operation because I can’t 
rely on the objects remaining equal.


Is my understanding of this correct?  Is there anything I’m missing?



Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to think in
terms of object references the entire way.

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







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

Re: To clarify how Python handles two equal objects

[Chris Angelico]

On Wed, 11 Jan 2023 at 09:08, Thomas Passin  wrote:
>
> Just to add a possibly picky detail to what others have said, Python
> does not have an "array" type.  It has a "list" type, as well as some
> other, not necessarily mutable, sequence types.

Just to be even pickier, Python DOES have an array type, but it's not
the one the OP was using :)

https://docs.python.org/3/library/array.html

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

Re: To clarify how Python handles two equal objects

[Jen Kris via Python-list]

There are cases where NumPy would be the best choice, but that wasn’t the case 
here with what the loop was doing.  

To sum up what I learned from this post, where one object derives from another 
object (a = b[0], for example), any operation that would alter one will alter 
the other.  When either is assigned to something else, then they no longer 
point to the same memory location and they’re once again independent.   I hope 
the word "derives" sidesteps the semantic issue of whether they are "equal."    

Thanks to all who replied to this post.  

Jen


Jan 10, 2023, 13:59 by li...@tompassin.net:

> Just to add a possibly picky detail to what others have said, Python does not 
> have an "array" type.  It has a "list" type, as well as some other, not 
> necessarily mutable, sequence types.
>
> If you want to speed up list and matrix operations, you might use NumPy.  Its 
> arrays and matrices are heavily optimized for fast processing and provide 
> many useful operations on them.  No use calling out to C code yourself when 
> NumPy has been refining that for many years.
>
> On 1/10/2023 4:10 PM, MRAB wrote:
>
>> On 2023-01-10 20:41, Jen Kris via Python-list wrote:
>>
>>>
>>> Thanks for your comments.  I'd like to make one small point.  You say:
>>>
>>> "Assignment in Python is a matter of object references. It's not
>>> "conform them as long as they remain equal". You'll have to think in
>>> terms of object references the entire way."
>>>
>>> But where they have been set to the same object, an operation on one will 
>>> affect the other as long as they are equal (in Python).  So I will have to 
>>> conform them in those cases because Python will reflect any math operation 
>>> in both the array and the matrix.
>>>
>> It's not a 2D matrix, it's a 1D list containing references to 1D lists, each 
>> of which contains references to Python ints.
>>
>> In CPython, references happen to be pointers, but that's just an 
>> implementation detail.
>>
>>>
>>>
>>> Jan 10, 2023, 12:28 by ros...@gmail.com:
>>>
 On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
  wrote:

>
> I am writing a spot speedup in assembly language for a short but 
> computation-intensive Python loop, and I discovered something about 
> Python array handling that I would like to clarify.
>
> For a simplified example, I created a matrix mx1 and assigned the array 
> arr1 to the third row of the matrix:
>
> mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
> arr1 = mx1[2]
>
> The pointers to these are now the same:
>
> ida = id(mx1[2]) - 140260325306880
> idb = id(arr1) - 140260325306880
>
> That’s great because when I encounter this in assembly or C, I can just 
> borrow the pointer to row 3 for the array arr1, on the assumption that 
> they will continue to point to the same object.  Then when I do any math 
> operations in arr1 it will be reflected in both arrays because they are 
> now pointing to the same array:
>

 That's not an optimization; what you've done is set arr1 to be a
 reference to that object.

> But on the next iteration we assign arr1 to something else:
>
> arr1 = [ 10, 11, 12 ]
> idc = id(arr1) – 140260325308160
> idd = id(mx1[2]) – 140260325306880
>
> Now arr1 is no longer equal to mx1[2], and any subsequent operations in 
> arr1 will not affect mx1.
>

 Yep, you have just set arr1 to be a completely different object.

> So where I’m rewriting some Python code in a low level language, I can’t 
> assume that the two objects are equal because that equality will not 
> remain if either is reassigned.  So if I do some operation on one array I 
> have to conform the two arrays for as long as they remain equal, I can’t 
> just do it in one operation because I can’t rely on the objects remaining 
> equal.
>
> Is my understanding of this correct?  Is there anything I’m missing?
>

 Assignment in Python is a matter of object references. It's not
 "conform them as long as they remain equal". You'll have to think in
 terms of object references the entire way.

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

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

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

Re: To clarify how Python handles two equal objects

[Thomas Passin]

On 1/10/2023 5:11 PM, Chris Angelico wrote:

On Wed, 11 Jan 2023 at 09:08, Thomas Passin  wrote:


Just to add a possibly picky detail to what others have said, Python
does not have an "array" type.  It has a "list" type, as well as some
other, not necessarily mutable, sequence types.


Just to be even pickier, Python DOES have an array type, but it's not
the one the OP was using :)

https://docs.python.org/3/library/array.html



Ha! And here all this time I thought you got them from an add-on package.

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

Re: To clarify how Python handles two equal objects

[Ethan Furman]

On 1/10/23 12:03, Jen Kris via Python-list wrote:

> I am writing a spot speedup in assembly language for a short but 
computation-intensive Python
> loop, and I discovered something about Python array handling that I would 
like to clarify.

> But on the next iteration we assign arr1 to something else:
>
> arr1 = [ 10, 11, 12 ]
> idc = id(arr1) – 140260325308160
> idd = id(mx1[2]) – 140260325306880
>
> Now arr1 is no longer equal to mx1[2]...

If you want to have `arr1` to still be `mx1[2]` (and consequently for `mx1[2]` to now be `[10, 11, 12]` you need to 
mutate `arr1` instead of reassigning it:


arr1[:] = [10, 11, 12]

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

Re: To clarify how Python handles two equal objects

[Thomas Passin]

On 1/10/2023 5:21 PM, Jen Kris wrote:
There are cases where NumPy would be the best choice, but that wasn’t 
the case here with what the loop was doing.


To sum up what I learned from this post, where one object derives from 
another object (a = b[0], for example), any operation that would alter 
one will alter the other.


Let's make sure we're clear here. The way you were doing it, it *looks 
like* "one alters the other".  But in reality, both are the same thing, 
and so when that thing gets altered in some way, both variables will 
show the change because they are in fact references to the same object.


As an analogy, if you dye your hair purple and look in a mirror, you 
will see your image with the new purple hair.  If you look in a 
different mirror, you will also see your image with the new purple hair. 
 They are both reflections of the same object, namely you with your new 
purple hair.


The point about the identity of objects contained within other objects 
is echoed by the copy and deepcopy operations.  copy() copies the 
references, deepcopy() makes new objects that are equal to the original 
ones. After making a deep copy of a list and assigning it to  new 
variable, changes in one will no longer show up in the other because the 
elements are are no longer the same elements.


When either is assigned to something else, 
then they no longer point to the same memory location and they’re once 
again independent.


This is right except that in Python, it's better not to think about 
their memory locations, because that would basically be an 
implementation detail (well, except that if you are going to access them 
with C you will possibly need actual locations).  Their logical identity 
would be better to think about.


I hope the word "derives" sidesteps the semantic 
issue of whether they are "equal."


Thanks to all who replied to this post.

Jen


Jan 10, 2023, 13:59 by li...@tompassin.net:

Just to add a possibly picky detail to what others have said, Python
does not have an "array" type. It has a "list" type, as well as some
other, not necessarily mutable, sequence types.

If you want to speed up list and matrix operations, you might use
NumPy. Its arrays and matrices are heavily optimized for fast
processing and provide many useful operations on them. No use
calling out to C code yourself when NumPy has been refining that for
many years.

On 1/10/2023 4:10 PM, MRAB wrote:

On 2023-01-10 20:41, Jen Kris via Python-list wrote:


Thanks for your comments.  I'd like to make one small
point.  You say:

"Assignment in Python is a matter of object references. It's not
"conform them as long as they remain equal". You'll have to
think in
terms of object references the entire way."

But where they have been set to the same object, an
operation on one will affect the other as long as they are
equal (in Python).  So I will have to conform them in those
cases because Python will reflect any math operation in both
the array and the matrix.

It's not a 2D matrix, it's a 1D list containing references to 1D
lists, each of which contains references to Python ints.

In CPython, references happen to be pointers, but that's just an
implementation detail.



Jan 10, 2023, 12:28 by ros...@gmail.com:

On Wed, 11 Jan 2023 at 07:14, Jen Kris via Python-list
 wrote:


I am writing a spot speedup in assembly language for
a short but computation-intensive Python loop, and I
discovered something about Python array handling
that I would like to clarify.

For a simplified example, I created a matrix mx1 and
assigned the array arr1 to the third row of the matrix:

mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ]
arr1 = mx1[2]

The pointers to these are now the same:

ida = id(mx1[2]) - 140260325306880
idb = id(arr1) - 140260325306880

That’s great because when I encounter this in
assembly or C, I can just borrow the pointer to row
3 for the array arr1, on the assumption that they
will continue to point to the same object. Then when
I do any math operations in arr1 it will be
reflected in both arrays because they are now
pointing to the same array:


That's not an optimization; what you've done is set arr1
to be a
reference to that object.

But on the next iteration we assign arr1 to
something else:

arr1 = [ 10, 1

Re: To clarify how Python handles two equal objects

[MRAB]

On 2023-01-10 22:21, Jen Kris via Python-list wrote:

There are cases where NumPy would be the best choice, but that wasn’t the case 
here with what the loop was doing.

To sum up what I learned from this post, where one object derives from another object (a = b[0], 
for example), any operation that would alter one will alter the other.  When either is assigned to 
something else, then they no longer point to the same memory location and they’re once again 
independent.   I hope the word "derives" sidesteps the semantic issue of whether they are 
"equal."


[snip]
In C terms (and in CPython), a 'list' is a resizable array of pointers 
to objects, so after "a=b[0]", the name "a" will point to the same 
object that b[0] points to. That object might or might not be mutable.


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

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

[Cameron Simpson]

On 10Jan2023 18:32, MRAB  wrote:
I don't like how you're passing Thread...start as an argument. IMHO, it 
would be better/cleaner to pass a plain function, even if the only 
thing that function does is to start the thread.


Yes, and this is likely the thing causing the cited exception "threads 
can only be started once". Your setup of the button with the action 
defined as:


Thread().start

creates a _single_ new Thread _when you define the button_, and makes 
hte button callback try to start it. On the second and following 
callback, you're trying to start the _same_ single Thread again.


Do as MRAB suggests and have the callback create-and-start a Thread 
instead of just starting an _existing_ Thread.


Also, for simple quick things there's no need to use a Thread at all. If 
the final version of the programme is going to do something long running 
at that point, then sure.


I can't tell what 'change_flag' is doing because of the formatting 
issue. Is it doing GUI stuff? In a thread? If yes, don't do that. The 
GUI doesn't like that. Only the main thread should do GUI stuff.


Aye. This is very important in almost all GUI toolkits.

Bit me very badly with Qt once, badly in that the segfaults (yes!  
segfaults! in a Python app!) were erratic and very timing dependent, 
making them hard to reproduce and understand. It wasn't until I 
_realised_ it was thread/concurrency related that I could fix it.


Note that in Tk you can have a callback do GUI work, just not in a 
separate thread.


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

Re: Tkinter GUI freezing, used Thread then encountered RuntimeError: threads can only be started once

[MRAB]

On 2023-01-11 00:13, Cameron Simpson wrote:

On 10Jan2023 18:32, MRAB  wrote:
I don't like how you're passing Thread...start as an argument. IMHO, it 
would be better/cleaner to pass a plain function, even if the only 
thing that function does is to start the thread.


Yes, and this is likely the thing causing the cited exception "threads
can only be started once". Your setup of the button with the action
defined as:

  Thread().start

creates a _single_ new Thread _when you define the button_, and makes
hte button callback try to start it. On the second and following
callback, you're trying to start the _same_ single Thread again.


You're right! I missed that detail. :-(


Do as MRAB suggests and have the callback create-and-start a Thread
instead of just starting an _existing_ Thread.

Also, for simple quick things there's no need to use a Thread at all. If
the final version of the programme is going to do something long running
at that point, then sure.

I can't tell what 'change_flag' is doing because of the formatting 
issue. Is it doing GUI stuff? In a thread? If yes, don't do that. The 
GUI doesn't like that. Only the main thread should do GUI stuff.


Aye. This is very important in almost all GUI toolkits.

Bit me very badly with Qt once, badly in that the segfaults (yes!
segfaults! in a Python app!) were erratic and very timing dependent,
making them hard to reproduce and understand. It wasn't until I
_realised_ it was thread/concurrency related that I could fix it.

Note that in Tk you can have a callback do GUI work, just not in a
separate thread.



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

Re: To clarify how Python handles two equal objects

[Greg Ewing]

On 11/01/23 11:21 am, Jen Kris wrote:

where one object derives from another object (a = b[0], for example), any 
operation that would alter one will alter the other.


I think you're still confused. In C terms, after a = b[0], a and b[0]
are pointers to the same block of memory. If you change that block of
memory, then of course you will see the change through either pointer.

Here's a rough C translation of some of your Python code:

/* mx1 = [ [ 1, 2, 3 ], [ 4, 5, 6 ], [ 7, 8, 9 ] ] */
int **mx1 = (int **)malloc(3 * sizeof(int *));
mx1[0] = (int *)malloc(3 * sizeof(int));
mx1[0][0] = 1;
mx1[0][1] = 2;
mx1[0][2] = 3;
mx1[1] = (int *)malloc(3 * sizeof(int));
mx1[1][0] = 4;
mx1[1][1] = 5;
mx1[1][2] = 6;
mx1[2] = (int *)malloc(3 * sizeof(int));
mx1[2][0] = 7;
mx1[2][1] = 8;
mx1[2][2] = 9;

/* arr1 = mx1[2] */
int *arr1 = mx[2];

/* arr1 = [ 10, 11, 12 ] */
arr1 = (int *)malloc(3 * sizeof(int));
arr1[0] = 10;
arr1[1] = 11;
arr1[2] = 12;

Does that help your understanding?

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

Re: Python - working with xml/lxml/objectify/schemas, datatypes, and assignments

[aapost]

On 1/4/23 12:13, aapost wrote:

On 1/4/23 09:42, Dieter Maurer wrote:

aapost wrote at 2023-1-3 22:57 -0500:

...
Consider the following:

from lxml import objectify, etree
schema = etree.XMLSchema(file="path_to_my_xsd_schema_file")
parser = objectify.makeparser(schema=schema, encoding="UTF-8")
xml_obj = objectify.parse("path_to_my_xml_file", parser=parser)
xml_root = xml_obj.getroot()

let's say I have a Version element, that is defined simply as a string
in a 3rd party provided xsd schema




Does your schema include the third party schema?

You might have a look at `PyXB`, too.
It tries hard to enforce schema restrictions in Python code.



Yes, to clarify, they provide the schema, which is what we use, 
downloaded locally. Basically just trying to remain compliant with their 
structures that they already define without reinventing the wheel for 
numerous calls and custom types, and in a way that feels more live 
rather than just checking validity at the end of the edits as if I were 
modifying the XML manually.


Thank you for the suggestion, PyXB works much more like how I envisioned 
working with xml in my head:


 >>> xml_root.Version = 1231.32000
pyxb.exceptions_.SimpleTypeValueError: Type 
{http://www.w3.org/2001/XMLSchema}string cannot be created from: 1231.32

 >>> xml_root.Version = "1231.32000"

I will have to do some more testing to see how smooth the transition 
back to a formatted document goes, since it creates a variable for all 
possible fields defined in the type, even if they are optional and not 
there in the situational template.


Thanks


Unfortunately picking it apart for a while and diving deeper in to a 
rabbit hole, PyXB looks to be a no-go.


PyXB while interesting, and I respect it's complexity and depth, is 
lacking in design consistency in how it operates if you are trying to 
modify and work with the resulting structure intuitively. It was 
developed on Python2 14 years ago, made compatible with python3 late, 
seems like it was trying to maintain vast version compatibility rather 
than getting a needed overhaul, before being abandoned in 2017 after the 
author moved on to more interesting work... I don't blame him, lol.. The 
community forks are just minor bug fixes currently.


There are no setValue()/_setValue() functions for SimpleTypes (the bulk 
of your objects) so you can't change their values directly. Assigning to 
them appears to work if they are nested inside a parent that has 
__setattr__ overloaded (as a default resulting structure does when you 
first load a document), but it is a rats nest as far as what happens 
from there. Sometimes it calls .Factory(), sometimes it goes through a 
series of __init__s, but nothing is really clear on what is or is not a 
kosher approach to managing value changes, and my attempts have failed 
so far to see if I could figure out how to encompass those paths in to a 
single _setValue() call.


Then there are ComplexTypes, with a value called _IsSimpleContent, which 
indicates whether it is a wrapper for a custom SimpleType, or something 
that does not contain SimpleType data. These DO have _setValue() 
functions IF it contains SimpleType data, where the SimpleType is stored 
in a __content member variable. Assignment on these also appears to work 
but the results aren't good, you need to use _setValue(), or you lose 
things like attributes. It would have been nicer if the structure of the 
ComplexType was called something else and wrapped all objects with a 
common set of functions.


The validate functions do not work how one would assume, like they do 
for other libraries, where they go back and verify the data. I believe 
they only function on the way in, because if the data becomes invalid 
through some manual messing with it after the fact, they indicate that 
the data is still valid even when it's not.


It seems like what I am probably looking for may reside in java with 
JAXB, but nothing really beyond that.


generateDS, doesn't really offer anything I need from what I could tell 
in messing with it, and by the looks of it, I might have to bite the 
bullet and use the xmlschema library, work with dicts, handle many more 
corner cases on my side, and just let the result be a lot clunkier than 
I was hoping. Unless I find 8 years to redesign the wheel myself, not 
sure I am granted that ability though. Oh well. lol

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