feature request: ternary fallthroughs

[ndc85430]

I don't get what you're trying to do either. I am half wondering if what you want is a result monad, though.

[buran]

Im converting the int only once,

no you converting it twice

val = int(sys.argv[1]) if int(sys.argv[1])

Just an example how your code may look

import sys
from string import ascii_lowercase

def read_file(file="/Users/rexfitzhugh/bin/data/words"):
    print("opening file..")
    with open(file) as f:
        contents = f.read().splitlines()
    print("contents stored...")
    return contents

def chek(word, ch_map, val):
    return sum(ch_map.get(ch, 0) for ch in word.lower()) == val

if __name__ == '__main__':
    try:
        val = int(sys.argv[1])
    except (ValueError, IndexError):
        print("expected a number as an arg")
    else:
        ch_map = {v:k for k, v in enumerate(ascii_lowercase, 1)}
        words = read_file() # instead of reading the whole file in memory you may just iterate over it line by line.
        matches = [word for word in words if check(word, ch_map, val)]

[rexrf]

okay bud heres how ternary operators work

val = thing IF (this condition is TRUE) otherwise it does not equal that thing.

nothing is assigned to val until the evaluation is complete Theres scenarios where val is never even assigned a value.

val is schrodinger's cat until that expression is evaluated.

[rexrf]

I don't get what you're trying to do either. I am half wondering if what you want is a result monad, though.

I'm not sure what to tell you, this is a fully implemented solution in other languages.

[buran]

And because your thread is titled feature request - note that we are not associated with Python Software Foundation / python core development team.

I will also move the thread to Discussions subsection

[deanhystad]

There are problems with your example and your references. The main problem is fall through does something completely different in C++ than what you propose. In C/C++ the case statement has fall through as a built in feature, and the fall through tag tells the compiler to not issue a warning. If I were proposing a Python fall through feature I might start by referencing that it adds a "C case" like fall through behavior to Python if/else/elif.

Another problem is that your example does not read well at all, even now that I think I understand what you are trying to do. I would do your example like this:

def get_args():
    if len(sys.argv) > 1 and sys.argv[1]:
        return int(sys.argv[1])
    print("expected a number as an arg")
    exit(1)

The need for the C++ [fallthrough] attribute is an indictment of what a bad idea fall through is in a case statement. Millions of hours have been wasted tracking down bugs caused by this "feature". If case fall through worked as you propose, requiring an explicit statement to make it happen, it would have caused a lot fewer problems and it would make the code a lot easier to read.

However I do not think fallthrough reads well in an if statement. I also don't think you can come up with many examples where using fallthrough is better than reorganizing the if logic. Unless you can come up with some better examples I don't think you'll gain much support.

EDIT

A lot of discussion snuck in while I was writing the above. Are you thinking of this fall through as only used in a ternary operation? If so, your example really stinks. That is not what I was getting from your examples at all.

[rexrf]

sorry a lot too unpack, I hope I address it all.

No i think fallthrough is a great addition for flow control in general. My example is how it can be used in an already great evaluation tool. And While your example is a solid solution, im simply of the opinion that a one liner with bolstered eval abilities is a no brainer.

And you'll have to forgive me for loving go, I think perhaps the things that make sense in a largely procedural / functional language do not translate well in this case.

To me it is painfully obvious when and why you use this. I can see this opinion is not shared amongst the python community :)

[rexrf]

thanks for everyone engaging with me on this. for real; i wanted to see how the idea would be received and i did

[deanhystad]

Until they see how this will make their own programming better people will be reluctant to adopt. To me, your example is not compelling. It does not make the code any shorter and the dangling fallthrough does not say to me "jump to the body of the next conditional".

I was looking at go, and there, in a switch statement, it works great. It addresses two big problems with case statement fall-through in C. It makes it difficult to do fall-through by mistake and it makes it obvious when fall-through is used. But even here it looks more like a correction than a valuable feature. This is apology for messing up the C case statement. "Sorry we made you waste millions of hours chasing down fall-through errors in switch statements. We won't do that anymore. But for the few times you did fall-through on purpose we're going to add a new keyword to make it easier to convert your old C programs.

Is there a language that has a fall-through like feature for if statements? If so, you should reference that language.

[rexrf]

traditional OO.

This belief that some idea or concept is only true only if it's always true, is a fools errand.

You will find many seemingly random features in python. your assumption that since its not useful to you, so therefore its not useful to anyone is the crux of your argument.

My point is that this feature HAS been implemented and IS otherwise enjoyed. You're taking this personally.

I'm simply asking for a simple flow control adoption, and pythonistas are saying: it isnt complicated enough!