On Sunday, December 22, 2013 5:02:51 PM UTC-6, Mark Lawrence wrote: > On 22/12/2013 22:51, Chris Angelico wrote:
> if a() == 0: > > if b() == 0: > > c() > > I can only see one way that you can possibly intepret it. Hmm, I guess i should not assume color vision to be ubiquitous. > [snip] The level of abstraction of that code sample is so high that no one should assume anything from reading it. The only fact we CAN be sure of is that IF a() equals 0 and b() equals 0 then c will execute. But that fact gives us no insight into Frank's *real* source code, not to mention his mind. Sure. We always want folks to trim example code to it's most relevant parts before presenting the code on this list, but just as ten thousands lines of code is useless, so too is 4 lines. It's not the number of lines that matter so much as the context those line provide to the problem at hand. If you take the small code example literally, then why does Frank even need to ask a question about what will happen when he could simply run the code and observe the results. Here is the most simplified example of Franks code: if 0 == 0: if 0 == 0: do_something() This code is so *confined* as to be useless for generalities. In fact, the only reason to ask a question about such simplified code is to understand the execution rules OR syntax of Python source code. Here are some concrete facts about those three lines: 1. test one will ALWAYS eval true, and proceed to test two 2. test two will ALWAYS eval true, then execute "do_something" 3. what happens after that is undefined These are fundamental behaviors of Python conditionals, operators, callables, etc... which we *already* understand quite completely. But these fundamentals will not help us understand Frank's problem. What we need is help Frank is *CONTEXT*. Now, even though Frank's code offers a small increment in complexity over my simplified form, it offers *zero* context of that complexity: 1. test one will evaluate true or false, then proceed (or not, depending on the return value of "a") to test two 2. test two will evaluate true or false, then proceed (or not, depending on the return value of "b") to execute the body 3. What happens in a, b, and c is undefined. The problem is we have no idea what happens in a,b,and c... but those facts may not matter, what does matter is what a return value of zero *means* to Frank, and without an understanding of these "Frank semantics", how could we possibly extrapolate a solution to such ambiguous questions? You see, there exist no rules in Python for what a return value of 0 should mean. Should it mean "success"? Should it mean "failure"? Should it mean "eat pasta quickly"? Well it could mean all those things to different people. Since function return values are defined by programmers, *ONLY* the programmer himself-- or those familiar with the entire code base --can resolve the ambiguities with any degree of precision. Even IF you are presented with a small snippet of code that include the identifier for the return value, you still cannot be certain that extrapolating meaning from an identifier *alone* will give you the insight to remove all ambiguity. For example, let's say the return value is "proceed" and attached to name spelled "flag". Do you really think you can extrapolate the purpose of that value being returned? "proceed" with what? Proceed counting unicorns? Proceed raising exceptions? Proceed extrapolating to infinity and beyond?! You can guess, but that is all. Which brings us full circle to the problem at hand. -- https://mail.python.org/mailman/listinfo/python-list