저는 zzzeek이 대답 한 것과 비슷한 방식으로 백 슬래시를 자주 사용합니다. PEP8은 지침 일 뿐이며 위반할 때 잠을 자지 않습니다!
그러나 나는 또한 자주 나는 zzzeek의 첫 번째 예를 도난 한 경우, 아래 서식의 형식을 사용, 약간을 쥐게하고 포맷 :
이
q = Session.query(
Subkeyword.subkeyword_id,
Subkeyword.subkeyword_word,
)
q = q.filter_by(subkeyword_company_id=self.e_company_id) # first filter
q = q.filter_by(subkeyword_word=subkeyword_word) # 2nd filter
q = q.filter_by(subkeyword_active=True)
if filter_by_foo:
q = q.filter(Subkeyword.foo == True)
# Run the query (I usually wrap in a try block)...
subkeyword = q.one()
질문에 반복 된 재 할당 처음에 가지 불쾌한 것 , 그러나 나는 그것을 극복했다. 성능 영향은 사실상 유효하지 않습니다. 이 방법의 큰 장점은 후행 주석과 주석 행을 모두 섞어 쿼리를 문서화 할 수 있다는 것입니다 (위의 쓸모없는 추가로 수행 한 것처럼). 백 슬래시가있는 행을 연결하면 여기가 제한됩니다. 다른 예로서 등
로직 트리거 변형 톤 내장형 스칼라 선택과 대량 질의를 공식화 때
포맷팅이 방법은 고순도이며, I는 CTE 쿼리 I 상당히 큰 (> 150 라인)가 두 가지 방법을 혼합 한 혼합 논리, 에일리어싱 및 라벨링 (생성 된 쿼리의 가독성을 위해 필수적)이 많은 SQLAlchemy를 생성합니다.당신은 (않는 많은 일반 SQL 형식 체계와 같은) 새로운 작업으로 라인을 이끌 수 있는지 확인하는 경우, 그것은 유지, 일반적으로
cte_init = session.\
query(
child1.foo.label("child1_foo"),
sa.literal(1).label("indent"), # can comment on non-slashed lines
child2.bar.label("child2bar"),
#comments between non-slashed lines ok, too
sa.func.MAX(toplevel.baz).label("max_baz"),
).\
select_from(top_level).\
join(child1,
child1.id == toplevel.fk_child1_id).\
join(child2.
child2.id == toplevel.fk_child2.id).\
filter(top_level.name == "bogus").\
cte(name = "cte", recursive = True)
if(use_filter_x):
cte_init = cte_init.filter_by(x = "whatever")
# etc (no, the above doesn't make any sense)...
: 그것의 심각한 감소 (및 난도질) 버전은 뭔가 아래와 같이 시작 꽤 읽을 수 있습니다. 괄호 안의 개줄도 두려워하지 마십시오.
좋은 백 슬래시 사용 http://www.pocoo.org/internal/styleguide/ – estin