1. assert디버깅 목적으로 표준 코드를 사용하는 대신 표준 코드의 일부로 사용하면 성능 또는 코드 유지 관리 문제가 있습니까?

   입니다

   assert x >= 0, 'x is less than zero'

   보다 나은 또는 나쁜

   if x < 0:
       raise Exception, 'x is less than zero'

2. 또한 비즈니스 규칙을 설정하는 방법이 있습니까? 그렇지 if x < 0 raise error않고 항상 확인 try/except/finally하십시오. 코드 전체에서 언제라도 x0보다 작은 경우 assert x < 0함수의 시작 부분에서 함수의 어디에서나 설정하는 것처럼 오류가 발생 합니다 x예외가 발생한 곳 이 0보다 작은 곳 은 어디 입니까?

함수 전체에서 x가 0보다 작을 때 오류를 자동으로 발생시킬 수 있습니다. 클래스 디스크립터 를 사용할 수 있습니다 . 예를 들면 다음과 같습니다.

class LessThanZeroException(Exception):
    pass

class variable(object):
    def __init__(self, value=0):
        self.__x = value

    def __set__(self, obj, value):
        if value < 0:
            raise LessThanZeroException('x is less than zero')

        self.__x  = value

    def __get__(self, obj, objType):
        return self.__x

class MyClass(object):
    x = variable()

>>> m = MyClass()
>>> m.x = 10
>>> m.x -= 20
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "my.py", line 7, in __set__
    raise LessThanZeroException('x is less than zero')
LessThanZeroException: x is less than zero

어설 션은 절대 발생하지 않아야하는 조건을 테스트하는 데 사용해야합니다 . 프로그램 상태가 손상된 경우 일찍 충돌하는 것이 목적입니다.

발생할 수있는 오류에 대해서는 예외를 사용해야하며 거의 항상 자체 예외 클래스를 작성해야합니다 .

예를 들어, 구성 파일 dict에서을 ( 를) 읽는 기능을 작성하는 경우 파일의 형식이 잘못 지정되면을 발생시켜야 ConfigurationSyntaxError하지만 assert을 반환 할 수는 없습니다 None.

예를 들어, x사용자 인터페이스 또는 외부 소스를 통해 설정된 값인 경우 예외가 가장 좋습니다.

x동일한 프로그램에서 자신의 코드로만 설정된 경우 어설 션을 사용하십시오.

컴파일이 최적화되면 "assert"문이 제거됩니다 . 따라서 성능과 기능상의 차이가 있습니다.

컴파일시 최적화가 요청 될 때 현재 코드 생성기는 어설 션 명령문에 대한 코드를 생성하지 않습니다. - 파이썬 2 문서 파이썬 3 문서

당신이 사용하는 경우 assert응용 프로그램 기능을 구현 데 하고 프로덕션 환경에 맞게 배포를 최적화하는 경우 "but-it-it-works-in-dev"결함이 발생합니다.

PYTHONOPTIMIZE 및 -O -OO 참조

네 가지 목적 assert

4 명의 동료 Alice, Bernd, Carl 및 Daphne과 함께 200,000 줄의 코드를 작업한다고 가정합니다. 그들은 당신의 코드를 호출하고, 당신은 그들의 코드를 호출합니다.

그리고 assert이 네 가지 역할을 :

1. Alice, Bernd, Carl 및 Daphne에게 코드에 필요한 것을 알립니다.
   튜플 목록을 처리하는 메소드가 있고 해당 튜플을 변경할 수없는 경우 프로그램 로직이 중단 될 수 있다고 가정하십시오.

   def mymethod(listOfTuples):
       assert(all(type(tp)==tuple for tp in listOfTuples))

   이는 문서의 동등한 정보보다 신뢰할 수 있으며 유지 관리가 훨씬 쉽습니다.

2. 코드에 필요한 것을 컴퓨터에 알리십시오.
   assert코드 발신자로부터 올바른 행동을 취합니다. 코드가 Alices와 Bernd의 코드를 호출하면을 제외하고 assert프로그램이 Alices 코드에서 충돌하는 경우 Bernd는 Alice의 결함이라고 가정하고 Alice는이를 조사하고 결함이라고 가정 할 수 있습니다. 그의. 많은 작업이 손실되었습니다.
   어설 션을 사용하면 전화가 잘못 된 사람은 자신의 잘못이 아니라 자신의 잘못이라는 것을 빨리 알 수 있습니다. 앨리스, 베른 그리고 당신은 모두 이익을 얻습니다. 엄청난 시간을 절약합니다.

3. 어느 시점에서 코드가 달성 한 것을 코드 독자 (자신 포함)에게 알리십시오.
   항목 목록이 있고 각 항목이 깨끗하거나 (좋으면) smorsh, trale, gullup 또는 twinkled (모두 허용되지 않음) 일 수 있다고 가정하십시오. 스모 시일 경우 스모시되지 않아야합니다. 그것이 trale라면 그것은 baludoed해야합니다; gullup 인 경우 뛸 수 있어야합니다. 반짝 거리면 목요일을 제외하고 다시 반짝 여야합니다. 당신은 아이디어를 얻는다 : 그것은 복잡한 일이다. 그러나 최종 결과는 모든 항목이 깨끗하다는 것입니다. 올바른 일 (TM)은 세척 루프의 효과를 다음과 같이 요약합니다.

   assert(all(entry.isClean() for entry in mylist))

   이 문장은 훌륭한 루프가 달성하는 것이 무엇인지 정확히 이해하려는 모든 사람들에게 두통을 덜어줍니다 . 그리고이 사람들 중 가장 빈번하게 자신이 될 것입니다.

4. 어느 시점에서 코드가 달성 한 것을 컴퓨터에 알리십시오.
   뛸 때 필요한 항목을 조정하는 것을 잊어 버린 경우 assert하루를 절약하고 Daphne의 코드가 훨씬 나중에 손상되지 않도록하십시오.

내 생각에, assert문서 (1과 3)와 보호 (2와 4)의 두 가지 목적은 똑같이 가치가 있습니다.
사람들에게 알리는 것이 컴퓨터를 알리는 것보다 더 가치가있을 수 있습니다. 컴퓨터가 의도하는 실수 assert(1 번 경우)와 그 이후의 많은 실수를 막을 수 있기 때문 입니다.

다른 답변 외에도 AssertionErrors 만 예외를 throw한다고 주장합니다. 공리주의 적 관점에서, 어설 션은 어떤 예외를 포착 할 것인지에 대한 세밀한 제어가 필요할 때 적합하지 않습니다.

이 접근 방식에서 실제로 잘못된 유일한 것은 assert 문을 사용하여 매우 설명적인 예외를 만들기가 어렵다는 것입니다. 더 간단한 구문을 찾고 있다면 다음과 같이 할 수도 있습니다 .

class XLessThanZeroException(Exception):
    pass

def CheckX(x):
    if x < 0:
        raise XLessThanZeroException()

def foo(x):
    CheckX(x)
    #do stuff here

또 다른 문제점은 정상적인 조건 검사에 assert를 사용하면 -O 플래그를 사용하여 디버깅 assert를 비활성화하기가 어렵다는 것입니다.

여기에 주장 된 영어 단어 는 맹세 , 긍정 , avow 의 의미로 사용됩니다 . "check" 또는 "should be"를 의미하지는 않습니다 . 그것은 당신 이 코더로서 맹세 한 진술 을하고 있음을 의미합니다 :

# I solemnly swear that here I will tell the truth, the whole truth, 
# and nothing but the truth, under pains and penalties of perjury, so help me FSM
assert answer == 42

코드가 정확하고 단일 이벤트 장애, 하드웨어 오류 등을 제외하면 어떤 주장도 실패하지 않습니다 . 따라서 최종 사용자에 대한 프로그램의 동작이 영향을받지 않아야합니다. 특히 예외적 인 프로그래밍 조건 에서도 어설 션이 실패 할 수 없습니다 . 그것은 결코 일어나지 않습니다. 이 경우 프로그래머가 압축해야합니다.

앞에서 언급했듯이 코드가 특정 지점에 도달하지 않아야 할 때 어설 션을 사용해야합니다. 이는 버그가 있음을 의미합니다. 어설 션을 사용하는 가장 유용한 이유는 불변 / 사전 / 후 조건 일 것입니다. 이것들은 루프 나 함수의 각 반복의 시작 또는 끝에서 참이어야합니다.

예를 들어 재귀 함수 (2 개의 별도 함수이므로 1은 잘못된 입력을 처리하고 다른 하나는 잘못된 코드를 처리하므로 재귀와 구별하기 어렵습니다). 이것은 내가 if 문을 쓰는 것을 잊었는지, 무엇이 잘못되었는지 분명하게 할 것입니다.

def SumToN(n):
    if n <= 0:
        raise ValueError, "N must be greater than or equal to 0"
    else:
        return RecursiveSum(n)

def RecursiveSum(n):
    #precondition: n >= 0
    assert(n >= 0)
    if n == 0:
        return 0
    return RecursiveSum(n - 1) + n
    #postcondition: returned sum of 1 to n

이러한 루프 불변량은 종종 어설 션으로 표현 될 수 있습니다.

가 성능 문제가?

• "빠르게 작동하기 전에 먼저 작동 시키십시오 "를 기억하십시오 .
  프로그램의 거의 몇 퍼센트가 보통 속도와 관련이 있습니다. assert성능 문제로 판명 된 경우 언제든지 쫓아 내거나 단순화 할 수 있으며 대부분의 경우 결코 그렇지 않습니다.

• 실용적 :
  비어 있지 않은 튜플 목록을 처리하는 메소드가 있고 해당 튜플을 변경할 수없는 경우 프로그램 로직이 중단된다고 가정하십시오. 당신은 작성해야합니다 :

  def mymethod(listOfTuples):
      assert(all(type(tp)==tuple for tp in listOfTuples))

  목록이 10 개 항목 인 경우에는 문제가 없지만 백만 항목이 있으면 문제가 될 수 있습니다. 그러나이 귀중한 수표를 완전히 버리지 않고 간단히 다운 그레이드 할 수 있습니다

  def mymethod(listOfTuples):
      assert(type(listOfTuples[0])==tuple)  # in fact _all_ must be tuples!

  저렴하지만 어쨌든 실제 프로그램 오류의 대부분을 잡을 것 입니다.

글쎄, 이것은 공개적인 질문이며, 내가 다루고 싶은 두 가지 측면이 있습니다 : 어설 션을 추가 할 때와 오류 메시지를 작성하는 방법.

목적

초보자에게 그것을 설명하기 위해-주장은 오류를 일으킬 수있는 진술이지만 오류를 잡을 수는 없습니다. 그리고 그들은 보통 자라서는 안되지만, 실제로는 어쨌든 자라기도합니다. 그리고 이것은 심각한 상황으로, 코드를 복구 할 수없는 심각한 오류입니다.

다음으로, '디버깅 목적'을위한 것인데, 이는 정확하지만 매우 불쾌하게 들립니다. 나는 다른 초보자들에게는 다르게 작동하지만 '불변하지 않아야 함'을 선언하는 것이 더 좋습니다. 어떤 초보자는 다르게 행동하지만 다른 사람들은 그것을 사용하지 않거나 정상적인 예외를 대체합니다. 또는 그것으로 제어 흐름.

스타일

파이썬에서는 assert함수가 아닌 서술문입니다! (생각해 내다assert(False, 'is true') 올려서는 안된다는 .

선택적 '오류 메시지'를 언제 어떻게 작성해야합니까?

이 acually 자주 (주장을 할 많은 전용 방법이 유닛 테스트 프레임 워크에 적용 assertTrue(condition), assertFalse(condition), assertEqual(actual, expected)등). 또한 종종 주장에 대해 의견을 제시 할 수있는 방법을 제공합니다.

버리기 코드에서는 오류 메시지없이 할 수 있습니다.

어떤 경우에는 어설 션에 추가 할 것이 없습니다.

데프 덤프 (무언가) : assert isinstance (무언가, 덤프 가능) # ...

그러나 그 외에도 메시지는 다른 프로그래머 (예 : Ipython / Jupyter 등의 대화 형 사용자)와 통신하는 데 유용합니다.

내부 구현 세부 정보를 유출하는 것이 아니라 정보를 제공하십시오.

대신에:

assert meaningless_identifier <= MAGIC_NUMBER_XXX, 'meaningless_identifier is greater than MAGIC_NUMBER_XXX!!!'

쓰다:

assert meaningless_identifier > MAGIC_NUMBER_XXX, 'reactor temperature above critical threshold'

또는 아마도 :

assert meaningless_identifier > MAGIC_NUMBER_XXX, f'reactor temperature({meaningless_identifier }) above critical threshold ({MAGIC_NUMBER_XXX})'

나는 알고 있습니다. 이것은 정적 주장의 경우가 아니지만 메시지의 정보 가치를 가리키고 싶습니다.

부정적이거나 긍정적 인 메시지?

이것은 논란의 여지가 있지만 다음과 같은 것을 읽는 것은 나에게 상처를줍니다.

assert a == b, 'a is not equal to b'

• 이들은 서로 옆에 쓰여진 두 가지 모순 된 것입니다. 따라서 코드베이스에 영향을 줄 때마다 'must'및 'should'와 같은 추가 동사를 사용하여 원하지 않는 것을 말하지 말고 원하는 것을 지정하십시오.

  주장 a == b, 'a는 b와 같아야합니다'

그런 다음 얻는 AssertionError: a must be equal to b것도 읽을 수 있으며 명령문은 코드에서 논리적으로 보입니다. 또한 트레이스 백을 읽지 않고도 무언가를 얻을 수 있습니다 (때로는 사용할 수없는 경우도 있음).

assert예외 의 사용 과 제기는 모두 의사 소통에 관한 것입니다.

• 주장은 개발자가 다루는 코드의 정확성에 대한 진술 입니다. 런타임에 실패한 어설 션은 개발자에게 코드에 수정이 필요한 결함이 있음을 알려줍니다.

• 예외는 런타임에 발생할 수 있지만 처리 할 호출 코드에서 해결 된 현재 코드로 해결할 수없는 비정형 상황에 대한 표시입니다. 예외가 발생했다고 코드에 버그가 있음을 나타내지는 않습니다.

모범 사례

따라서 런타임에 특정 상황의 발생을 개발자에게 알려주고 싶은 버그로 생각하면 ( "안녕 개발자,이 조건은 어딘가에 버그가 있음을 나타냅니다. 코드를 수정하십시오.") 주장을 위해 가십시오. 어설 션이 코드의 입력 인수를 확인하는 경우 일반적으로 입력 인수가 해당 조건을 위반할 때 코드에 "정의되지 않은 동작"이 있음을 설명서에 추가해야합니다.

그와 같은 상황이 눈에 버그를 나타내는 것이 아니라 클라이언트 코드가 처리해야한다고 생각할 수있는 상황은 예외를 발생시킵니다. 예외가 발생하는 상황은 해당 코드 문서의 일부 여야합니다.

사용과 성능 [...] 문제가 있습니까 assert

어설 션 평가에는 시간이 걸립니다. 그러나 컴파일 타임에 제거 할 수 있습니다. 그러나 결과는 다음과 같습니다.

사용하는 데 [...] 코드 유지 관리 문제가 있습니까 assert

일반적으로 어설 션은 코드의 유지 관리 성을 향상시킵니다. 코드는 가정을 명확하게하고 런타임 동안 이러한 가정을 정기적으로 확인하여 가독성을 향상시키기 때문입니다. 이것은 또한 회귀를 잡는 데 도움이 될 것입니다. 그러나 명심해야 할 한 가지 문제가 있습니다. 어설 션에 사용 된 식에는 부작용이 없어야합니다. 위에서 언급했듯이 어설 션은 컴파일 타임에 제거 될 수 있습니다. 즉, 잠재적 부작용도 사라질 것입니다. 이것은 의도하지 않게 코드의 동작을 변경할 수 있습니다.

Assert는
1. 유효한 조건
2. 유효한 진술
3. 진정한 논리;
소스 코드 전체 프로젝트를 실패하는 대신 소스 파일에 부적절한 것이 있다는 경고가 표시됩니다.

예 1에서, 변수 'str'이 널이 아니기 때문에. 따라서 어떤 주장이나 예외도 제기되지 않습니다.

예 1 :

#!/usr/bin/python

str = 'hello Python!'
strNull = 'string is Null'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
hello Python!
FileName ..................... hello
FilePath ..................... C:/Python\hello.py

예제 2에서 var 'str'은 null입니다. 따라서 우리는 assert 문으로 사용자가 잘못된 프로그램보다 앞서 나가는 것을 막고 있습니다 .

예 2 :

#!/usr/bin/python

str = ''
strNull = 'NULL String'

if __debug__:
    if not str: raise AssertionError(strNull)
print str

if __debug__:
    print 'FileName '.ljust(30,'.'),(__name__)
    print 'FilePath '.ljust(30,'.'),(__file__)


------------------------------------------------------

Output:
AssertionError: NULL String

우리가 디버그를 원하지 않고 소스 코드에서 어설 션 문제를 실현 한 순간. 최적화 플래그 비활성화

python -O assertStatement.py
아무것도 인쇄되지 않습니다

PTVS, PyCharm, Wing assert isinstance()문과 같은 IDE 에서는 명확하지 않은 개체에 대한 코드 완성을 활성화하는 데 사용할 수 있습니다.

가치있는 일을 assert위해 제대로 작동 하는 코드를 다루는 경우 다음 코드를 추가하면 어설 션이 활성화됩니다.

try:
    assert False
    raise Exception('Python assertions are not working. This tool relies on Python assertions to do its job. Possible causes are running with the "-O" flag or running a precompiled (".pyo" or ".pyc") module.')
except AssertionError:
    pass