Comment by dreamweapon | Hacker News Reader

Comment by dreamweapon | Hacker News Reader

Parent Full thread

Then he asked me to do it one more time. I wasn't familiar with the python syntax for if-else shortcut (e.g., x = 100 if y is True else 0) and so couldn't rewrite it to his liking. This lack of familiarity with this python trick resulted in feedback at the end of the interview that I did not have a deep enough understanding of computer science.

Precious.

And of course, an entirely different take could be made from your response -- precisely because you do have a solid grounding in CS, you've probably chosen to spend your time with languages with (for want of a better term) more "powerful", and arguably more standard constructions than what Python affords for this kind of a logical switch -- namely, a ternary operator -- which if Python had it, would probably look a lot like this:

    x = y ? 100 : 0

and that you were consequently flummoxed by Python's quirky lack of this useful (and arguably much more readable) construct.

So if you were interviewing for a senior-level, Python-specific position I can see why they'd expect you to know the if-then-else trick. But if it's a secondary language for you, then the feedback that interviewer gave you definitely seems more than a bit off-base.

(DISCLAIMER: No, I don't think Python is a flawed language because it doesn't have a ternary op, or that it should have "stronger CS fundamentals" or any of that. It's just a side aspect or a different, larger point I was making).

Someone else mentioned the fact that

    default_result if condition else alternate_result

is pythons form of ternary expression and semantically equivalent other then pythons truthiness boolean testing of objects(empty collections, 0, empty strings, False, None, 0 timedelta evaluate to False, also objects where obj.__nonzero__() returns False (in python3 __nonzero__ is renamed to __bool__)).

I'd like to bring up that while it's a matter of opinion the older ugly ?: syntax is much less readable even when you memorize it. I never use ?: syntax ternary expressions in languages that have them because I always have to look it up. That's why a number of languages prefer python-like versions or forms which emphasize to an even larger degree the fact that its just an if-else as an expression to an even larger degree(so I'd question that it's standard, I'm not 100% it's older either as I think the LISP version is closer to the python version).

CoffeeScript

    s = if condition then "yup" else "nope"

Smalltalk

    abs := x > 0 ifTrue: [ x ] ifFalse: [ x negated ]

Ruby has both versions

Scala a = if (n == 12) "twelve" else "not twelve"

Rust

    let y = if x == 5 { 10 } else { 15 }; // y: i32

Haskell

    fac x = if x==0 then
           1
           else x * fac (x - 1)

(some examples taken from http://rosettacode.org)

When first learning python (Shaw's The Hard Way maybe), it suggested this idiom as python's ternary operator:

    boolean and true_branch or false_branch

and explained that boolean=true would make it check and return true_branch, while false makes it check the other side of the or.

This is parallel to the standard C one. I'm surprised no one has mentioned it, but I guess that makes sense because it's not very explicit about what it's doing, which goes agains the spirit of python. Probably not very common for python programmers to use.

That is pythons 'ternary operator', you can nest it:

  x = 11 if False else ( 12 if False else 13)
  print x
  => 13

Python's philosophy in general is to try to avoid magic symbols such as && or || and just use 'and' and 'or'

You can actually just use the 'or' to shortcut this whole thing, because or returns the first true value.

  x = False or (True or False)

Or you can write it all out on multiple lines

    if cond1:
        if cond2:
            x = 12
        else:
            x = 11
    else:
        x = 13

That way you can debug it more easily (because you can trace execution rather than printing out the values that cond1 and cond2 depend on and figuring out in your head which way the ternary will go).

This also removes ambiguity in the case where you might want to assign to x some falsey thing like None or [] or zero:

    >>> y = None
    >>> x = False or ( y or False )
    >>> x
    False

The above code depends on the value of y for control flow. Clearer is to use syntax for control flow and not abuse falsey-ness or truthiness.

    >>> print [bool(f) for f in [None, 0, 0.0, [], ()]]
    [False, False, False, False, False]

If you really do want to test the falsey behavior, IMHO it's much, much clearer to branch on bool(the_maybe_falsey_thing) rather than just the_maybe_falsey_thing.

>If you really do want to test the falsey behavior, IMHO it's much, much clearer to branch on bool(the_maybe_falsey_thing) rather than just the_maybe_falsey_thing.

Maybe if you never program in python. Otherwise it makes absolutely no sense to do so because its obvious that every value is evaluated for its boolean value.

Right. But at no point was I saying that Python ought to have a ternary op, or that it doesn't have an analogous construct.

Reply on news.ycombinator.com