4 ms·
In Python I might do something like this. class Source(str): pass class Dest(str): pass def helper1(a, b): assert isinsta
by mlthoughts2018 7y ago
In Python I might do something like this.
class Source(str):
pass
class Dest(str):
pass
def helper1(a, b):
assert isinstance(a, Source)
assert isinstance(b, Dest)
copyFile(a, b)
if __name__ == “__main__”:
# obvs use argparse instead and store
# directly to Source & Dest objects
# but here to be quick:
a, b = sys.argv[1:3]
a, b = Source(a), Dest(b)
helper1(a, b)
- collyw 7y agoYou know how to complicate something very simple. What is the advantage here? As I would prefer to have the authors original problem than this.
- mlthoughts2018 7y agoYou’re assuming I would endorse this as a good approach in Python in the real world. I was merely trying to show how to quickly emulate the Haskell example with less code in Python. Both the Haskell approach and asserting on types in Python seem like wastes of time to me personally, and I’d rather just have copyFile by itself and consenting adults can pass the args they want to pass. Use unit tests to make sure you’re not passing paths the wrong way. Also, what’s with the attitude? “You know how to complicate something very simple” (from ~15 lines of Python?) — geez, you must be a joy to work with.
- lonelappde 7y agoHow is writing extra boilerplate tests better than saying what you mean in the primary code?
- mlthoughts2018 7y agoIt addresses exactly the cases you care about, whereas trying to bake it into designs or type system usually adds heavy restrictions that don’t necessarily have anything to do with your exact use cases. Basically from a You Aren’t Gonna Need It point of view, doing it in tests lets you minimally address the real use case with much less risk of premature or incorrect abstraction. In my experience, premature abstraction is one of the worst problems in business software. To contrast two far ends of the spectrum, minimalistic patchworks of gross hacking are asymmetrically way better than overhead of premature or incorrect abstractions.
- throwaway744678 7y agoPython has named arguments; you can use something like: copy(source=file1, destination=file2) and be done with it. Or am I missing something?
- mlthoughts2018 7y agoThis would do nothing to prevent passing it like copy(source=file2, dest=file1) whereas the parent post is trying to use the type system to make this sort of mistake much more difficult to make.
- Too 7y agoParent would not stop me from doing this either: copy(source=Src(file2), dest=Dest(file1)) At some point you will have to make a human decision which file to copy, only thing helping you out in that situation is that it clearly states on call-site which arg is src and which arg is dest, instead of remembering left or right argument.
- mlthoughts2018 7y agoSure, I mean ultimately you could shoot cosmic rays at your computer to rearrange bits and bypass any type safety you want. I don’t get why you think this bears relevance?
- GordonS 7y agoI'm not sure how @Too's example is any worse than named parameters - surely the point is that it's just as likely to transpose source/destination either way.
- mlthoughts2018 7y agoI think the point is that it’s irrelevant, because type checking or type assertions would take place at the parameter ingestion step specifically to render transposing the arguments impossible. Any solution could be screwed up on purpose if you’re imagining someone at an interpreter prompt getting the arguments wrong or omitting unit tests that verify a certain file is used as source and a different file as dest... which is why this kind of objection just totally doesn’t matter.