Blake Winton wrote:
Steve Howell wrote:
Let the Python interpreter build expression objects for you. You write: rowexpr: convert_to_euros(salary) > 50000 and deptno = 10 Python translates that into the same bytecode as: lambda row: convert_to_euros(row['salary'] > 50000 and row['deptno'] == 10
I'm sorry, why would that not be translated into:
lambda row: row['convert_to_euros'](row['salary'] > row['50000'] row['and'] row['deptno'] == row['10']
Sticking to your logic, why would it be > instead of row['>']? This is, I guess, particularly simple with Python's tokenizer because neither 50000 nor and can be valid identifiers.
? Specifically, how would python know what to dereference and what not to? What if there were two things, named the same, one in the row and one in the namespace? (i.e. a variable named 'salary')
That's a harder one, indeed. Perhaps, nothing should be dereferenced (at ``compile'' time, don't know if that's a valid term in CPython's interpreter chain tho), as it is in a lambda-expression.
How would you escape things which would have been dereferenced but you didn't want to be? (i.e. "rowexpr: convert_to_euros(salary) > salary")
ACK. If included (and I have major doubts it has a chance over 0.001%), it could just support "easy" expressions, such as lambdas do today.
I guess I'm kind of wasting my time here, since the introduction of a new keyword for this application really isn't going to happen, based on other decisions I've seen Guido make, but I do think that you need to think a little more about how the implementation of this feature would work. (Or perhaps you've done that thinking, and you just need to fill in the proposal with that information.)
Well, discussing in a mature manner can IMO never be a waste of time but I have to agree, I would not want this as a keyword either. A common idiom (aka stdlib module) *could* be handy, though. Regards, Stargaming