Re: What is the "Unpacking Arguments List" rule?
Alister via Python-list at 2018/6/13 PM 08:43 wrote: IMHO, there is no reason to check the *args has to appear at last in positional argument list in a function call because of there is no "unknown number of parameters" at the time of unpacking. It should be alright to write line 19 action(*args, progress) Anyone wanting to write such code should be banned form ever accessing a computer. Won't it be too hard to this guy:-) if you know how many arguments are going to be passed to match the *args part of this function then they should be assigned known variables otherwise the code will soon become an unmanageable mess. I think it's depend on the situation. this is why the language specifications states it should only appear after all known positional arguments have been declared To a function call, where the spec is? --Jach --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- https://mail.python.org/mailman/listinfo/python-list
Re: OFF-TOPIC Good sig [was Re: What is the "Unpacking Arguments List" rule?]
On Wed, Jun 13, 2018 at 10:10 AM Steven D'Aprano wrote: > > On Wed, 13 Jun 2018 12:43:12 +, Alister via Python-list wrote: > > > I have a theory that it's impossible to prove anything, but I can't > > prove it. > > Heh, that reminds me of Stephen Pinker's comment from "Enlightenment Now": > > "one cannot reason that there's no such thing as reason" > > but on the other hand, Kurt Gödel successfully proved using mathematics > that (sufficiently powerful) maths is either inconsistent or incomplete, > and we can never tell which. In a sense, Gödel proved that it is > impossible to prove *certain* things which are true, or disprove some > which are false, but we have no way of proving which are which. I'm not an expert, but my understanding of the Second Incompleteness Theorem is that a consistent, sufficiently powerful formal system cannot prove its own consistency. It doesn't mean that we can't prove it in some other way. -- https://mail.python.org/mailman/listinfo/python-list
OFF-TOPIC Good sig [was Re: What is the "Unpacking Arguments List" rule?]
On Wed, 13 Jun 2018 12:43:12 +, Alister via Python-list wrote: > I have a theory that it's impossible to prove anything, but I can't > prove it. Heh, that reminds me of Stephen Pinker's comment from "Enlightenment Now": "one cannot reason that there's no such thing as reason" but on the other hand, Kurt Gödel successfully proved using mathematics that (sufficiently powerful) maths is either inconsistent or incomplete, and we can never tell which. In a sense, Gödel proved that it is impossible to prove *certain* things which are true, or disprove some which are false, but we have no way of proving which are which. -- Steven D'Aprano "Ever since I learned about confirmation bias, I've been seeing it everywhere." -- Jon Ronson -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the "Unpacking Arguments List" rule?
On Wed, 13 Jun 2018 14:21:53 +0800, sa...@caprilion.com.tw wrote: > [Of the first part] > line 19 is > action(progress=progress, *args) > where the args is a tuple > args = (i, 3) > and the function is defined as > def action(id, reps, progress): > > In documents 4.7.2. Keyword Arguments, it says ''' > def parrot(voltage, state='a stiff', action='voom', type='Norwegian > Blue'): > ... > ... > but all the following calls would be invalid: > ... > parrot(voltage=5.0, 'dead') # non-keyword argument after a keyword > argument > ... > ''' > > After unpack the args in line 19, it will be looks like > action(progress=progress, i, 3) > and it seems violate the above rule. > > [Of the second part] > > The "*args" and "**kw" are very helpfull. I hope (and expect) > > they will remain. > There is no "**kw" involved in this topic:-) and the positional limit of > "*args" in a function definitions has its own good reason:-) > > IMHO, there is no reason to check the *args has to appear at last in > positional argument list in a function call because of there is no > "unknown number of parameters" at the time of unpacking. It should be > alright to write line 19 > action(*args, progress) Anyone wanting to write such code should be banned form ever accessing a computer. if you know how many arguments are going to be passed to match the *args part of this function then they should be assigned known variables otherwise the code will soon become an unmanageable mess. this is why the language specifications states it should only appear after all known positional arguments have been declared > just like assignment below where both are valid. > a, *b = any *a, b = any > > Best Regards, > Jach Fong > > > dieter at 2018/6/13 PM 12:59 wrote: >> Jach Fong writes: >>> ... >>> 4.7.4. Unpacking Argument Lists The reverse situation occurs when the >>> arguments are already in a list or tuple but need to be unpacked for a >>> function call requiring separate positional arguments. >>> ... >> args = [3, 6] list(range(*args)) >>> """ >>> >>> I can't understand why line 19 works? >> >> Not sure what "line 19" is - but if it refers to the example above: >> >>"range" accepts (among others) 2 integer arguments. >>The "*args" above means: unpack the sequence in "args" into >>individual arguments. >>This means (with the values of the example above), >>that "range(*args)" is equivalent to "range(3, 6)". >> >>> Didn't it violate the rule of "# non-keyword argument after a keyword >>> argument"? >> >> No keyword arguments at all in the above example. >> >>> and why a more reasonable look syntax gets an error? >>> >>> action(*args, progress) >>> ^ >>> SyntaxError: only named arguments may follow *expression File >>> "test.py", line 19 >> >> This is (in my view) a somewhat arbitrary restriction -- maybe >> introduced for symmetry with the function definition syntax. >> >> The message is quite clear, however: after the "*arg", >> you must pass keyword arguments only, i.e. they must have the form >> "param=value". >> >>> The only reason I can guess is that it checks with the rule in 4.7.3 >>> which is really unrelated. The "*any" notation used in different >>> places with different meaning, such as defining arbitrary argument, >>> unpacking argument or even in an assignment(a,*b=any). Maybe it will >>> be better to stop this syntax checking and lets both statements below >>> valid:-) >> >> The "*args" and "**kw" are very helpfull. I hope (and expect) >> they will remain. >> >> > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus -- I have a theory that it's impossible to prove anything, but I can't prove it. -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the "Unpacking Arguments List" rule?
[Of the first part] line 19 is action(progress=progress, *args) where the args is a tuple args = (i, 3) and the function is defined as def action(id, reps, progress): In documents 4.7.2. Keyword Arguments, it says ''' def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'): ... ... but all the following calls would be invalid: ... parrot(voltage=5.0, 'dead') # non-keyword argument after a keyword argument ... ''' After unpack the args in line 19, it will be looks like action(progress=progress, i, 3) and it seems violate the above rule. [Of the second part] > The "*args" and "**kw" are very helpfull. I hope (and expect) > they will remain. There is no "**kw" involved in this topic:-) and the positional limit of "*args" in a function definitions has its own good reason:-) IMHO, there is no reason to check the *args has to appear at last in positional argument list in a function call because of there is no "unknown number of parameters" at the time of unpacking. It should be alright to write line 19 action(*args, progress) just like assignment below where both are valid. a, *b = any *a, b = any Best Regards, Jach Fong dieter at 2018/6/13 PM 12:59 wrote: Jach Fong writes: ... 4.7.4. Unpacking Argument Lists The reverse situation occurs when the arguments are already in a list or tuple but need to be unpacked for a function call requiring separate positional arguments. ... args = [3, 6] list(range(*args)) """ I can't understand why line 19 works? Not sure what "line 19" is - but if it refers to the example above: "range" accepts (among others) 2 integer arguments. The "*args" above means: unpack the sequence in "args" into individual arguments. This means (with the values of the example above), that "range(*args)" is equivalent to "range(3, 6)". Didn't it violate the rule of "# non-keyword argument after a keyword argument"? No keyword arguments at all in the above example. and why a more reasonable look syntax gets an error? action(*args, progress) ^ SyntaxError: only named arguments may follow *expression File "test.py", line 19 This is (in my view) a somewhat arbitrary restriction -- maybe introduced for symmetry with the function definition syntax. The message is quite clear, however: after the "*arg", you must pass keyword arguments only, i.e. they must have the form "param=value". The only reason I can guess is that it checks with the rule in 4.7.3 which is really unrelated. The "*any" notation used in different places with different meaning, such as defining arbitrary argument, unpacking argument or even in an assignment(a,*b=any). Maybe it will be better to stop this syntax checking and lets both statements below valid:-) The "*args" and "**kw" are very helpfull. I hope (and expect) they will remain. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- https://mail.python.org/mailman/listinfo/python-list
Re: What is the "Unpacking Arguments List" rule?
Jach Fong writes: > ... > 4.7.4. Unpacking Argument Lists > The reverse situation occurs when the arguments are already in a list or > tuple but need to be unpacked for a function call requiring separate > positional arguments. > ... args = [3, 6] list(range(*args)) > """ > > I can't understand why line 19 works? Not sure what "line 19" is - but if it refers to the example above: "range" accepts (among others) 2 integer arguments. The "*args" above means: unpack the sequence in "args" into individual arguments. This means (with the values of the example above), that "range(*args)" is equivalent to "range(3, 6)". > Didn't it violate the rule of > "# non-keyword argument after a keyword argument"? No keyword arguments at all in the above example. > and why a more > reasonable look syntax gets an error? > > action(*args, progress) > ^ > SyntaxError: only named arguments may follow *expression File > "test.py", line 19 This is (in my view) a somewhat arbitrary restriction -- maybe introduced for symmetry with the function definition syntax. The message is quite clear, however: after the "*arg", you must pass keyword arguments only, i.e. they must have the form "param=value". > The only reason I can guess is that it checks with the rule in 4.7.3 > which is really unrelated. The "*any" notation used in different places > with different meaning, such as defining arbitrary argument, unpacking > argument or even in an assignment(a,*b=any). Maybe it will be better to > stop this syntax checking and lets both statements below valid:-) The "*args" and "**kw" are very helpfull. I hope (and expect) they will remain. -- https://mail.python.org/mailman/listinfo/python-list
What is the "Unpacking Arguments List" rule?
I had read "More on Defining Functions" sections of "The Python Tutorial" carefully yesterday. One thing in the example code(Re: How can an int be '+' with a tuple?) puzzles me again. It's the line 19: def progress(*any): threadQueue.put((onProgress, any + context)) action(progress=progress, *args) # line 19, it calls threadaction function def threadaction(id, reps, progress): """ below was quoted from the document 4.7.2. Keyword Arguments ... def parrot(voltage, state='a stiff', action='voom', type='Norwegian Blue'): ... but all the following calls would be invalid: ... parrot(voltage=5.0, 'dead') # non-keyword argument after a keyword argument ... 4.7.3. Arbitrary Argument Lists ... def write_multiple_items(file, separator, *args): ... Normally, these variadic arguments will be last in the list of formal parameters, because they scoop up all remaining input arguments that are passed to the function. ... 4.7.4. Unpacking Argument Lists The reverse situation occurs when the arguments are already in a list or tuple but need to be unpacked for a function call requiring separate positional arguments. ... >>> args = [3, 6] >>> list(range(*args)) """ I can't understand why line 19 works? Didn't it violate the rule of "# non-keyword argument after a keyword argument"? and why a more reasonable look syntax gets an error? action(*args, progress) ^ SyntaxError: only named arguments may follow *expression File "test.py", line 19 The only reason I can guess is that it checks with the rule in 4.7.3 which is really unrelated. The "*any" notation used in different places with different meaning, such as defining arbitrary argument, unpacking argument or even in an assignment(a,*b=any). Maybe it will be better to stop this syntax checking and lets both statements below valid:-) action(progress=progress, *args) action(*args, progress) Best Regards, Jach Fong --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus -- https://mail.python.org/mailman/listinfo/python-list
