theoretically - this might make a+b+c+d look like a+(b+(c+d)). Which isn't that bad, except that SA does not level-indent parenthesised expressions, and the sql is going to look like lisp program... but yes, u're right, SA relies on some python precedence and associativity being same as SQL ones. which may or may not be ok. as one can put brackets (a+b)+(c+d) where one needs explicitly, maybe this would only be applicable to SA-generated things, like implicit joins. But then again, if just for readability, indenting by level the parenthesises and subqueries helps much much much more. i had patch about this long ago but it doesnot work anymore... sigh.
On Wednesday 28 January 2009 01:14:16 Jon Nelson wrote: > I recently ran into an issue. Is it a bug? No. However, it made my > brain hurt for a little bit until I remembered the SQL precedence > rules for AND and OR. > > The operator precedence of AND and OR is known (AND takes > precedence). However, it can make humans hurt their brains a bit to > see SQL without (perhaps unnecessary) parens, explicitly noting the > desired order of operation. Perhaps a suggestion might be to always > use parens? > > Approx. line 2168 of sql/expression.py: > > if self.group and self.operator is not against and > operators.is_precedent(self.operator, against): > > What would the harm be in removing the final test (and > operators.is_predecent...) ? > > It seems to me that SQLAlchemy might group things a bit more > explicitly instead of relying on the precedence rules. Are there > database which have precedence rules that are not the same as > others (or are buggy)? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
