>There's also plenty of Python developers two years in (that I've interviewed and rejected) who couldn't write me a decorator or explain MRO.
First off both MRO and decorators can be learned in 1 week max by anyone. And one week is REALLY forgiving. Literally. You have to be mentally deficient not to be able to learn it. They simply didn't encounter the python feature in their experience. You would just reject them for not knowing about those features?
Second off decorators are syntactical tricks. You can get around python without ever using them. If you encounter them in libraries you just need to know what they do at a high level, you don't need to know how to implement them. If you ever do need to implement one just look it up. I don't judge people for not knowing syntactic tricks.
Third, MRO is something that should be not heavily used at all. You should avoid inheritance as much as possible. Additionally you should avoid double inheritance all together. The MRO/inheritance concept is a left over thing from an outdated programming style. At most you should know inheritance, and at most have one level of it if you must and try to use interfaces instead. Nowadays I expect only to see inheritance in existing libraries/tech debt and not newly written code from senior programmers. If someone encounters MRO issues, again, I just expect them to look it up.
I'll actually judge someone who expects others to know MRO given how outdated it is. I won't think they're stupid, or I won't not hire them or anything like that. I just know they aren't up to date with the current methodology but they can easily learn it if needed.
Overall, you're just setting a high bar artificially. It's like hiring janitors who only have phds in chemistry to know what's in the cleaning chemicals.
> Yes but the same timeline can be done for C, C#, Java or anything else.
No Java and C# languages are complex enough that it can be done in a 2 year timeline but these languages are hard enough that they are in a different class then python. C with memory management is harder then both java and C#. Memory management simply isn't intuitive.
No. The decorator is really just a syntactic shortcut. There are other facilities in python to do the same thing. The decorator is just a convenient way of doing it. The concept at hand is a function that takes a function and returns a new function. Nothing crazy here.
decorator: Callable[[Callable[[Any]. Any]], Callable[[Any], Any]] = lambda x: (lambda y: x(y)) #does nothing
g: Callable[[Any], Any] = lambda x: x #identity func
decorated_g: Callable[[Any], Any] = decorator(g) #decorator that does nothing to identity returns identity func
You see? You can just call the function and assign the result to a var and that var is a decorated function. The facility exists, the @ symbol is simply a convenience so you can execute it in the declaration step.
>We have a fundamentally different view of these things. Mine is serving me well. Yours isn't challenging mine.
Exactly see. Just because my view is "better" or more "modern" you still function fine within your role which is my point. Someone could have knowledge far superior to a person with 2 years of experience, functionally speaking, it doesn't matter too much. You still do "fine" at your role. Your view serves you well in the capacity of a "senior" engineer" even though your view points are ultimately wrong and inferior they still work well enough.
Also it isn't a viewpoint. Two of the newest languages to hit the mainstream have eschewed inheritance completely from their syntax. Neither Golang or Rust have the concept. Both use interfaces exclusively to promote the concept of similar types. No inheritance anywhere. I have tons of evidence on this even papers, quotations from prominent people. It's a well known fact inheritance is outdated.
We can agree to disagree, but it's like agreeing to disagree with a child who doesn't know any better. Sure.
First off both MRO and decorators can be learned in 1 week max by anyone. And one week is REALLY forgiving. Literally. You have to be mentally deficient not to be able to learn it. They simply didn't encounter the python feature in their experience. You would just reject them for not knowing about those features?
Second off decorators are syntactical tricks. You can get around python without ever using them. If you encounter them in libraries you just need to know what they do at a high level, you don't need to know how to implement them. If you ever do need to implement one just look it up. I don't judge people for not knowing syntactic tricks.
Third, MRO is something that should be not heavily used at all. You should avoid inheritance as much as possible. Additionally you should avoid double inheritance all together. The MRO/inheritance concept is a left over thing from an outdated programming style. At most you should know inheritance, and at most have one level of it if you must and try to use interfaces instead. Nowadays I expect only to see inheritance in existing libraries/tech debt and not newly written code from senior programmers. If someone encounters MRO issues, again, I just expect them to look it up.
I'll actually judge someone who expects others to know MRO given how outdated it is. I won't think they're stupid, or I won't not hire them or anything like that. I just know they aren't up to date with the current methodology but they can easily learn it if needed.
Overall, you're just setting a high bar artificially. It's like hiring janitors who only have phds in chemistry to know what's in the cleaning chemicals.
> Yes but the same timeline can be done for C, C#, Java or anything else.
No Java and C# languages are complex enough that it can be done in a 2 year timeline but these languages are hard enough that they are in a different class then python. C with memory management is harder then both java and C#. Memory management simply isn't intuitive.