[Tutor] a few question about my evolving program

[Cameron Simpson]

On 11Aug2015 22:33, Clayton Kirkwood <crk at godblessthe.us> wrote:
>> >What is the purpose and how is the following definition focused on the *?
>> >Turns out, you can't actually put the asterisk in the code, so what
>> >does it mean?
>> >os.stat(path, *, dir_fd=None, follow_symlinks=True)
>> [...]
>> Python function definition syntax and semantics are defined here:
>>   https://docs.python.org/3/reference/compound_stmts.html#function-definitions
>> and that in turn points to parameters:
>>   https://docs.python.org/3/glossary.html#term-parameter
>> Give them a read. The bare "*" in a function definition says that the following
>> keyword parameters (dir_fd and follow_symlinks in your example) may only
>> be supplied to function calls in keyword form, i.e.: [...]
>> Without the bare "*", unused positional parameters are assigned to the
>> keywords parameters, allowing:
>>   os.stat(pathname, None, True)
>> to set these two. The bare "*" forbids this, which avoids a lot of
>confusion and common errors.
>
>Well, thanks. The asterisk is only used in the *description* of the function
>call and says that everything following must be keyword defined.

Correct.

>If the
>definition of the function call doesn't have the asterisk, then if possible,
>assignments can be used or just using ordered (positional) callout is
>possible.

Yes. The bare "*" is new in Python 3.

>The issue comes down to the documentation being too efficient and
>saying things only once.

Specifications are like that. Saying things twice has the opportunity of 
inconsistency:-)

>When learning it is difficult to remember every
>nuance even reading through the documentation more than once, because it
>isn't always inherently obvious what something means and when specifically
>it is important that that specific character must be remembered.

Certainly. The trick is to be able to go back and find the specific information 
you need when the situation arises. If the situation arises often enough, 
you'll know it quite soon.

Now, I hadn't read that particular section of the doco for python 2, but 
remembered the gist of the "*" from discussion (on this list, as it happens).  
But I knew it had to be there, so I went to the "Language Specification" and 
found the section on function definitions. Since that did not explicitly 
describe the bare "*" but did point to the "Parameters" section, I followed 
that link and there it was. And that was how I found the two links I then 
provided to you.

Definitely read the documentation. But unless you are quite unusual, you will 
never rememebr it verbatim. But you will remember the broad outlines and also 
that you saw the section on this stuff, making it more findable. And on 
rereading it, _after_ having used the stuff it talks about, your retention of 
its details will be better because you now have experiential context to attach 
it to.

>> >Question 2:
>> >My current code:
>> >See "Look here" below.
>> [...]
>> >         if current_filename in target_directory_file_list:
>> >#top_directory_file_list
>> >That's it:<)) Go down to the bottom now:<))
[...]
>> >As you can see the current_filename does not exist in
>> >target_directory_file list. Yet, I fall through to the next line. Yes,
>> >the indents are all fine: I wouldn't have gotten to running code
>> >otherwise.  I turned my head upside down and still couldn't see why it
>> doesn't work and what I am missing?
>>
>> Have you put in a print statement to prove this, and also to display
>> current_filename and target_directory_file on that next line?
>
>I am using the PyCharm debugger in this instance. I validated by going to
>the directory itself and verifying what the value of what
>target_directory_file_list says in the debugger. The file doesn't exist in
>that directory although it does exist in the current directory file list.

That may be a clue. Might target_directory_file_list contain the current 
directory file list when the code runs? Hence the request for a print statement 
at the time of the misbehaviour.

>> Can you reduce this to a MUCH smaller program (eg 10 lines long) showing
>> the same problem? For example by hardwiring the values of
>> current_filename and
>> target_directory_file:
>>
>>   current_filename = 'foo'
>>   target_directory_file_list = [...]
>>   if current_filename in target_directory_file_list:
>>     print("IN! (unexpected!)")
>>   else:
>>     print("NOT IN")
>>
>> If the small program works correctly, that may point you to the issue in
>your larger program.
>
>I understand what you are saying. However, you guys are constantly asking
>for the original code. Now you are saying you are saying not the original
>code, rather a made up snippet, which very likely, for newbies like me,
>would bet bungled in creating a snippet. Can't win for losing.

Well, yes and no. Usually what we want is the smallest program exhibiting your 
problem, and an explaination of what correct results should be. For that, we 
always want the original code of that smallest example rather than an anecdote.  
We want to be sure that what we're inspecting is what you're inspecting.

The other thing we often want is the original problem (which you've described); 
often people come with their specific solution to a larger problem. Which is 
fine as long far as it goes, but sometimes the larger problem has a better, 
less cumbersome solution.

Cheers,
Cameron Simpson <cs at zip.com.au>