The problem with the typical tech recruiter is that they feel their job is to screen out unqualified candidates, but they do not understand technology well enough to understand the candidates, and thus they end up using completely arbitrary criteria. Some of this criteria sounds plausible, especially to junior candidates, and certainly to others in the HR industry who also don't know technology. But it is actually like excluding a receptionist from an interview because her last company had AT&T equipment and the new company has ITT phones!

In my career I've dealt with quite a few people like this, both as a hiring manager and as a candidate. As a hiring manager you get the opportunity to ask them some detailed questions about how they filter candidates, and I even asked one, once, to send me all of the resumes they got for the position, after she'd applied her filter. I went thru the entire stack of resumes myself, and filtered them by looking at them briefly, and then compared the ones I pulled out to hers. There was zero correlation. None of the ones I pulled out she did. All of the ones she pulled out -- and was busy giving me the hard sell on-- were ones I'd excluded. In fact my belief that the pickings couldn't be so slim was the reason I asked her to send me all of them, though I gave her some other excuse at the time. I also pulled twice as many candidates as she did, and was willing to spend up to an hour of my own time on the phone with them.

All of the people in your position think they know what they are doing and think they are good at being able to tell good candidates from bad ones. I understand why this might be, as this seems to be what they think is their job. "Anybody can exclude the janitors-- but I add value by being able to tell good programmers from bad ones!"

If you'd like to be a better recruiter, here's some changes to make:

1. Stop reviewing people's code. I've participated in many code reviews. I've often seen stuff that looked stupid, and asked the programmer about it, and then found out that they were expressing a level of understanding of the problem that was stronger than mine. Makes sense given that it wasn't my code I was reviewing, I was just reviewing, not writing it. That you think you can review someones contributions to open source in isolation is a big red flag. Just stop. Even if you're a great programmer, you can't do it fairly. In fact, if you were good enough to do it, you wouldn't want to do it because you'd know how easily it is to get wrong.

2. Just because someone doesn't list python on their resume, does not mean they wouldn't be a great python programmer. I've been using python off and on since the mid 1990s. I use it for utilities, tools and other support code, not for major projects, and it turns out (I just checked) I never actually put it on my resume. By your statements above I would have a "strong career but zero commercial or practical experience with python".

3. Just because someone has never programmed in python before, does not mean can't be the best candidate for the job. Programming is the talent. Python is a language. If you would say I'm unqualified to drive a ford because I've been driving toyotas, you'd be laughed at, wouldn't you? This is what you're doing. Every language has its strengths and weaknesses, sure. Unless you're hiring someone for a 3-5 week job, the quality of python code produced in the 6th week will have everything to do with the strength of the programmer, and nothing to do with the amount of python they've used in the past.

4. I once was interviewed by a recruiter and it became immediately obvious he was something special. I could tell he wasn't technical, so after he said he'd be setting up an interview with the hiring manager, I asked him how he'd come to the decision. He gave me a solution that you, and every non-technical person can apply, which is really quite brilliant: He said (paraphrasing) "I look for three things: ABC: Attitude, Bandwidth and Confidence. If they have a positive attitude, can explain things well to show they have a bright mind, and have some confidence, then I ask them a follow up question. I ask them to tell me about some technical thing they did that they're proud of. If my eyes glaze over, I know they are qualified to pass on." He didn't have to understand what the thing was, but he was uncanny in finding great candidates... in large part because his reputation caused them to seek him out. Maybe someone could bullshit him with a bunch of technical jargon that he didn't understand, that's fine, that's not his job. The idea of him judging my code is absurd, and would be to him too.

Please take this in the spirit it is intended, which is constructively.