consider rollup of __clause_element__() onto ClauseElement
tried to do this for #3802 late in 1.1 but it's too critical if someone is doing a while loop, and here's at least one example: https://github.com/albertov/py-mailing/blob/a81d71f35b3c04de75cca48eb82b0b85bbaaf915/mailing/models/util.py#L45. there's no reason that person would have done that besides copying our code. additionally, if we put __clause_element__()
onto ClauseElement, there's a lot of internal checks that should also be optimized.
other more far-out tricks would be:
-
return a copy of the object that raises some assertion on
__clause_element__()
. though this is expensive -
deprecate
__clause_element__()
and replace with some totally other method. But we'd need almost-forever backwards compat for calling upon__clause_element__
also in this case. It sort of suggests all the places where we dohasattr(obj, '__clause_element__')
should become some other kind of single call that perhaps we can put into cutils. Detecting__clause_element__
itself would then raise some kind of deprecation warning.
Comments (7)
-
reporter -
reporter __sql_expr__
__sqla_expr__
as_sqlalchemy
__expression__
__sql_expression__
as_sql_element
as_clauseelement
-
reporter __sqla_expression__
-
reporter __sqlexpression__
-
reporter __sql_element__
-
reporter maybe it's time to rename
ClauseElement
toSQLElement
anyway.ClauseElement
has always been awkward. -
reporter - changed milestone to 1.3
it's not clear how much benefit this is besides correctness, pushing this out for now
- Log in to comment
e.g. like this: