OSX 10.4
PsychoPy version 3.02
Standard Standalone? Y
Nothing went wrong, except my mania. I hate coding (I’ve programmed experiments in 7 languages), but I use I usually use a few code components in generally Builder context. I have an experiment where a ball travels across the screen and changes color. In Builder I used 2 balls (e.g., red, blue). But I was thinking how wonderful it would be to have an if statement in Builder. (If are usually done with loops with nreps= something). Thanks to the fantastic PsychoPy book, I realized that by putting a $ in any field it was interpreted as Python code. That was wonderful, but if statements in Python are multiple line affairs. I was wondering if there was a 1 line ‘if’ and there is (One line if statement in Python (ternary conditional operator) - Python Central). Could I use that syntax and have my ball change color at a certain frame number, and yes! If the example I also put an if statement in a text component, just for fun. There are probably many reasons why I should not do this (for one, this if format is not hugely backward compatible). If my form of ‘pretend I am not really coding’ is going to condemn me to a purgatory of debugging, please let me know. (The if statement is in the Advance tab.) ifPlay1.psyexp (7.3 KB)
Python is a language that provides an environment for entirely differently programming approaches, from simple procedural to object-oriented to functional programming. If your approach works for you, then it is correct. 
And as these expressions are a standard part of the Python language, I guess they are “Pythonic” by definition.
I’d tend to put the comparisons in a code component, to create a variable name that could then be put in a component field. That has the advantage of allowing the code to be easily extended to deal with more complex situations, or that the result can be used in multiple places.
But your approach of putting a conditional expression directly in a field has the substantial advantage that the logic can be found directly where it takes effect. If there is just a bare variable name there, then you have to go hunting to see where it was defined. To my mind, the only limitations are if the code needs to be extended, or if you want to use the result in multiple places. If not, it seems like a great approach.
PS regular if statements can also go on one line:
if len([1, 2, 3]) == 3: print('Three!!!')
But I don’t think that would be of much use in most Builder fields: your approach is far better for that.
I guess most people avoid lines like the one above in scripts because we rely so much on reading program logic from white space, but it is useful when typing expressions directly into a Python interpreter for immediate execution, rather than a .py file.
I am glad I finally made a contribution! 
. Stupid me didn’t try regular if statement on one line. The regular syntax looks better and reads better that what I put in my example.
You guys are sneaky, getting me to write code. But there is something nice about builder. You can show a student or someone and they can get the gist of the experiment without reading through lines of code and following function to function.
Actually only your sort of expression:
$'red' if frameN > 100 else 'blue'
would work properly in a Builder field, because it directly returns a value (either 'red' or 'blue'). I don’t think regular if statement syntax (i.e. with a colon) could be shoe-horned into a field like that. You are definitely doing things the right way: I’ll have to try to remember this useful syntax myself for situations like this.
I think Jon’s original view was that Builder would just be a teaching tool, and a gateway for people to go on to learn programming once they exceeded its limitations. But increasingly we find that Builder is actually good enough, and flexible enough, for most purposes, and people generally only need to extend it by inserting the odd snippet of code here and there. So most people can focus on being experimenters, working with a bit of code here and there, rather than having to become fully conversant with a programming language.