osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tutor] beginning to code


ROGER GRAYDON CHRISTMAN wrote:

[Note: RODGER's words have been edited for clarity, and hopefully he won't mind.]
    
> I have not yet mastered how to respond to a particular note
> in a thread with the mailer that I use, so this is not in
> response to anyone in particular, but just to some of the
> sentiments as a whole.
>  
>     if x:
>         # do something
> 
> Completely out of context, I would dislike it just because
> it is far too vague. Is it testing for zero? [F]or an empty
> list? [O]r for some object's completely arbitrary
> definition of truthiness?
> 
> x.._bool__() seems to me to be just as efficient, but we
> don't like calling dunders.bool(x) should mean the same
> thing, perhaps with an extra function invocation to look
> for the dunder. But even so, nothing here sheds light on
> what that Boolean outcome means.
> 
> I would agree that testing any of those for '== True' or
> the like is pointless redundancy, 

But what's wrong with syntactical redundancy when it brings
_clarity_ to the source code? And why can't Python be smart?
Consider the collowing code:

    if bool(someObject) == True:
        # Do something
        
Yes, from a "byte-code perspective", this source code is
superfluous, but, from a source code perspective, this code
is perfectly balanced between explicit and implicit. So what
should Python do when such intuitive, but not so much
efficient, code is encountered? Easy! Python should optimize
it! Observe:

    FROM: "if bool(someObject) == True:"
      TO: "if someObject:"
        
    FROM: "if bool(someObject) == False:"        
      TO: "if not someObject:"

Why is "source code optimization" such a difficult concept
for some people in this community to grasp? In this case,
Python doesn't even need to know anything about these
objects, no, the solution is just a simple matter of string
substitution. 

> which may or may not be slower, depending on optimization
> issues. 

Slower only the first time the source code is
_byte_compiled_. After that, source code containing explicit
statements like: "if bool(someObject) == True:" will run
just as fast as the implicit statement of: "if someObject:".
Well, that is, if the devs are wise...