4 ms·
Python has named arguments; you can use something like: copy(source=file1, destination=file2) and be done with it. Or am I missing something?
by throwaway744678 7y ago
Python 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.
- Spoom 7y agoSuch an error would be immediately obvious on code review. The idea is to make it obvious, not foolproof.
- mlthoughts2018 7y agoIn static typing paradigms, the idea most certainly is to make it foolproof and not merely easy to spot. Literally to convert the problem into something the compiler can prove is unbroken. Not saying this makes static typing better or anything, just pointing out that “easy to spot in code review” is massively different from “absolute mathematical proof this problem isn’t affecting me.” I’d argue you rarely care about such compiler proofs in real software development, but that’s beside the point if you assume a static typing paradigm has already been chosen.
- kedean 7y agoBut it's the "wrong" solution for python. Python is heavily focused around the idea of duck-typing, and forcing things like this completely blocks duck-typing. What if I want to pass down a complex object that can be used as a string? Python functions should let me pass any string-like thing I want, which is why named arguments are the preferred way to deal with this. You can even force named arguments using kwargs, I believe this is what the boto interface to AWS does.
- mlthoughts2018 7y agoYour argument doesn’t work. Python affords you tools like metaclasses, __instancecheck__, __subclasshook__, properties and descriptors exactly so you can use the type system to determine how duck typing is handled in whatever cases you want. Using inheritance and metaprogramming to enforce how and when a given instance or class object satisfies the contract of some interface is a core, fundamental, first-class aspect of Python. Just because you don’t need to use it very often doesn’t mean “it’s the wrong choice for Python” or anything like that at all. It is a thing Python goes way out of its way to enthusiastically support, so therefore it is absolutely a Pythonic way to solve problems.