Re: Questioning the effects of multiple assignment

[Peter J. Holzer]

On 2020-07-08 12:26:06 +1200, dn via Python-list wrote:
> A matter of style, which I like to follow [is it TDD's influence? - or
> does it actually come-from reading about DBC (Design by Contract*)?]

I think Design by Contract only affects the interfaces (parameters,
return values and side effects), not internal operations of a component.

> is the injunction that one *not* vary the value of a parameter inside
> a method/function.
> (useful in 'open-box testing' to check both the API and that input+process
> agrees with the expected and actual output, but irrelevant for 'closed-box
> testing')
> This also has the effect of side-stepping any unintended issues caused by
> changing the values of mutable parameters!
> (although sometimes it's a equally-good idea to do-so!)
> 
> Accordingly, binding argument-values to mutable parameters (instead of
> an immutable tuple) might cause problems/"side-effects", were those
> parameters' values changed within the function!

I don't think so. The tuple/list is local to the function and never
visible outside of it. So you can change it within the function without
affecting the caller:

#!/usr/bin/python3
def f(*a):
# a = list(a) # simulate star-as-list
a.append(2)

v = { "old": 1}
f(v)
print(v)

should print «{'old': 1}».

OTOH, using a tuple doesn't prevent the function from mutating mutable
arguments:

#!/usr/bin/python3
def f(*a):
a[0]["new"] = 2

v = { "old": 1}
f(v)
print(v)

prints «{'old': 1, 'new': 2}».

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Questioning the effects of multiple assignment

[o1bigtenor]

On Tue, Jul 7, 2020 at 2:30 AM Mike Dewhirst  wrote:

>
>  Original message From: dn via Python-list <
> python-list@python.org> Date: 7/7/20  16:04  (GMT+10:00) To: 'Python' <
> python-list@python.org> Subject: Questioning the effects of multiple
> assignment TLDR; if you are a Python 'Master' then feel free to skim the
> first part (which you should know hands-down), until the excerpts from 'the
> manual' and from there I'll be interested in learning from you...Yesterday
> I asked a junior prog to expand an __init__() to accept either a series of
> (>1) scalars (as it does now), or to take similar values but presented as a
> tuple. He was a bit concerned that I didn't want to introduce a (separate)
> keyword-argument, until 'we' remembered starred-parameters. He then set
> about experimenting. Here's a dichotomy that surfaced as part of our
> 'play':-(my problem is: I can't (reasonably) answer his question...)If you
> read this code:NB The print-ing does not follow the input-sequence, because
> that's the point to be made... >>> def f( a, *b, c=0 ):Shouldn't that def
> be ...>>> def f(a, c=0, *b):???... print( a, type( a ) )... print(
> c, type( c ) )... print( b )... >>> f( 1, 'two', 3, 'four' )[I had to
> force "c" to become a keyword argument, but other than that, we'll be using
> these three parameters and four argument-values, again]Question 1: did you
> correctly predict the output?1 0 ('two', 3,
> 'four')Ahah, "c" went to default because there was no way to identify when
> the "*b" 'stopped' and "c" started - so all the values 'went' to become "b"
> (were all "consumed by"...).Why did I also print "b" differently?Building
> tension!Please read on, gentle reader...Let's make two small changes:-
> amend the last line of the function to be similar:... print( b, type( b
> ) )- make proper use of the function's API: >>> f( 1, 'two', 3, c='four'
> )Question 2: can you predict the output of "a"? Well duh!(same as before)1
> Question 3: has your predicted output of "c" changed? Yes?
> Good!(Web.Refs below, explain; should you wish...)four  'str'>Question 4: can you correctly predict the content of "b" and its
> type?('two', 3) That makes sense, doesn't it? The arguments
> were presented to the function as a tuple, and those not assigned to a
> scalar value ("a" and "c") were kept as a tuple when assigned to "b".Jolly
> good show, chaps!(which made my young(er) colleague very happy, because now
> he could see that by checking the length of the parameter, such would
> reveal if the arguments were being passed as scalars or as a tuple.Aside:
> however, it made me think how handy it would be if the newly-drafted PEP
> 622 -- Structural Pattern Matching were available today (proposed for
> v3.10, https://www.python.org/dev/peps/pep-0622/) because (YAGNI-aside)
> we could then more-easily empower the API to accept other/more
> collections!Why am I writing then?Because during the same conversations I
> was 'demonstrating'/training/playing with some code that is (apparently)
> very similar - and yet, it's not. Oops!Sticking with the same, toy-data,
> let's code: >>> a, *b, c = 1, 'two', 3, 'four' >>> a, type( a ) >>> c,
> type( c ) >>> b, type( b )Question 5: what do you expect "a" and "c" to
> deliver in this context?(1, )('four', )Happy so
> far?Question 6: (for maximum effect, re-read snippets from above, then)
> what do you expect from "b"?(['two', 3], )List? A list?
> What's this "list" stuff???When "b" was a parameter (above) it was assigned
> a tuple!Are you as shocked as I?Have you learned something?(will it ever be
> useful?)Has the world stopped turning?Can you explain why these two
> (apparently) logical assignment processes have been designed to realise
> different result-objects?NB The list cf tuple difference is 'legal' - at
> least in the sense that it is documented/expected behavior:-Python
> Reference Manual: 7.2. Assignment statementsAssignment statements are used
> to (re)bind names to values and to modify attributes or items of mutable
> objects:...An assignment statement evaluates the expression list (remember
> that this can be a single expression or a comma-separated list, the latter
> yielding a tuple) and assigns the single resulting object to each of the
> target lists, from left to rightA list of the remaining items in the
> iterable is then assigned to the starred target (the list can be empty).
> https://docs.python.org/3/reference/simple_stmts.html#assignment-statementsPython
> Reference Manual: 6.3.4. CallsA call calls a callable object (e.g., a
> function) with a possibly empty series of arguments:...If there are more
> positional arguments than there are formal parameter slots, a TypeError
> exception is raised, unless a formal parameter using the syntax *identifier
> is present; in this case, that formal parameter receives a tuple containing
> the excess positional arguments (or an empty tuple if there were no excess
> positional arguments).
> 

execution timing of the method QWidget.show()

[artis . paintre]

I might be wrong but since I have not found anygroup newsgroup dedicated to 
PyQt5.

My small program is expected to show a window GUI for 4 seconds before changing 
it, so I naively coded:

"...
...
# codes to set up the GUI
...
F0.show() # F0 being a QMainWindow object
time.sleep(4)
...
# codes to change the GUI set up
...
F0.update() 

"

What happens: The a blank window is displayed, freezes for 4 seconds then 
second set up is displayed, the original set up is not displayed.

Why is not the original set up displayed? 

Obviously, if I remove the codes for the second set up, and the "time.sleep(4)" 
instruction, the original set up is displayed immediatly after I launch the 
execution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: execution timing of the method QWidget.show()

[MRAB]

On 2020-07-08 21:11, artis.pain...@gmail.com wrote:

I might be wrong but since I have not found anygroup newsgroup dedicated to 
PyQt5.

My small program is expected to show a window GUI for 4 seconds before changing 
it, so I naively coded:

"...
...
# codes to set up the GUI
...
F0.show() # F0 being a QMainWindow object
time.sleep(4)
...
# codes to change the GUI set up
...
F0.update()

"

What happens: The a blank window is displayed, freezes for 4 seconds then 
second set up is displayed, the original set up is not displayed.

Why is not the original set up displayed?

Obviously, if I remove the codes for the second set up, and the "time.sleep(4)" 
instruction, the original set up is displayed immediatly after I launch the execution.

If you tell the program to sleep, or your code is busy processing, then 
the GUI won't be unresponsive.


A GUI is based on events. Something happens, e.g. a button is pressed, a 
handler in your code is called, it does something, and then it passes 
control back to the GUI code to update the display and wait for the next 
event.


Basically, your code needs to set up the GUI, set some kind timer (I'm 
not familiar with Qt), and return control to Qt. When the timer expires, 
your code will be called, and then you can change the display, and 
return control to Qt again.

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

Re: Questioning the effects of multiple assignment

[dn via Python-list]

On 8/07/20 2:40 PM, Kyle Stanley wrote:

A matter of style, which I like to follow [is it TDD's influence? - or
does it actually come-from reading about DBC (Design by Contract*)?] is
the injunction that one *not* vary the value of a parameter inside a
method/function.
(useful in 'open-box testing' to check both the API and that
input+process agrees with the expected and actual output, but
irrelevant
for 'closed-box testing')
This also has the effect of side-stepping any unintended issues caused
by changing the values of mutable parameters!
(although sometimes it's a equally-good idea to do-so!)

Accordingly, binding argument-values to mutable parameters (instead of
an immutable tuple) might cause problems/"side-effects", were those 
parameters' values changed within the function!


I think I can see where you're going with this, and it makes me wonder 
if it might be a reasonable idea to have an explicit syntax to be able 
to change the behavior to store those values in a tuple instead of a 
list. The programming style of making use of immutability as much as 
possible to avoid side effects is quite common, and becoming 
increasingly so from what I've seen of recent programming trends.


If something along those lines is something you'd be interested in and 
have some real-world examples of where it could specifically be useful 
(I currently don't), it might be worth pursuing further on python-ideas. 



Thanks for this.

Nor can I imagine a strong reason to vary the existing implementation, 
and have no real-world example to offer which might drive such motivation.


Our surprise was an apparent lack of consistency. However, the 
explanation makes good sense (IMHO - now that it is properly informed). 
As you said, practicality trumps consistency. So, the two situations 
each have their own rule - and Python is better understood! The value of 
asking, "why?"!


Contrary to many, I enjoy it when someone pushes me into a 'corner' that 
I can't explain - such represents both a challenge and learning 
opportunity, and probably useful that the Junior Programmer-concerned 
should appreciate that no-one knows 'everything'.
(hopefully, others 'playing along at home' using the summary of our 
REPL-experimentation, have also learned - without first feeling as 
flummoxed, as we were...)

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

Re: Questioning the effects of multiple assignment

[dn via Python-list]

On 8/07/20 11:11 PM, o1bigtenor wrote:
On Tue, Jul 7, 2020 at 2:30 AM Mike Dewhirst > wrote:

 Original message From: dn via Python-list
mailto:python-list@python.org>> Date:
7/7/20  16:04  (GMT+10:00) To: 'Python' mailto:python-list@python.org>> Subject: Questioning the effects of
multiple assignment TLDR; if you are a Python 'Master' then feel
free to skim the first part (which you should know hands-down),

...

Dunno about the rest of the list but I'm finding this message incredibly 
hard to read.


Please sir - - - - would you please break up your message into at least 
sentences?



That is a terrible mess indeed!

This may be a local problem. The original (as reflected by the 
list-server), and each reply since, has been properly-formatted - at 
least when viewed in Thunderbird email-client.


All due apologies. If you (any colleague) are interested in the 
(apparent) conundrum, I will be happy to format a text file copy and 
attach it to a personal message...

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

Re: Questioning the effects of multiple assignment

[DL Neil via Python-list]

On 8/07/20 10:19 PM, Peter J. Holzer wrote:

On 2020-07-08 12:26:06 +1200, dn via Python-list wrote:
OTOH, using a tuple doesn't prevent the function from mutating mutable
arguments:

#!/usr/bin/python3
def f(*a):
 a[0]["new"] = 2

v = { "old": 1}
f(v)
print(v)

prints «{'old': 1, 'new': 2}».



Very clever!
Place a mutable inside the immutable parameter...

Any advance on return new_mutable?
--
Regards =dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: execution timing of the method QWidget.show()

[Barry]

Search for PyQt mailing list will get you to 
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

Barry

> On 8 Jul 2020, at 21:17, artis.pain...@gmail.com wrote:
> 
> I might be wrong but since I have not found anygroup newsgroup dedicated to 
> PyQt5.
> 
> My small program is expected to show a window GUI for 4 seconds before 
> changing it, so I naively coded:
> 
> "...
> ...
> # codes to set up the GUI
> ...
> F0.show() # F0 being a QMainWindow object
> time.sleep(4)
> ...
> # codes to change the GUI set up
> ...
> F0.update() 
> 
> "
> 
> What happens: The a blank window is displayed, freezes for 4 seconds then 
> second set up is displayed, the original set up is not displayed.
> 
> Why is not the original set up displayed? 
> 
> Obviously, if I remove the codes for the second set up, and the 
> "time.sleep(4)" instruction, the original set up is displayed immediatly 
> after I launch the execution.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 
-- 
https://mail.python.org/mailman/listinfo/python-list

Function type in typing

[Jonathan Gossage]

How could I type a function that returns a generic type? For example, I use
a function that expects another function as an argument. This second
function must return a datatype or a collection. I assume that I could
use *Callable[...,
return type]* and I have no way to specify the return type.

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