인프런 커뮤니티 질문&답변
작성한 질문수
함수 input 형식 지정 외 추가 raise 구성
해결된 질문
작성
·
43
1
이번 강의에서 GenerateLabel 클래스를 생성할 때 초기화에서 input_dir과 output_dir에 대해서 형식을 path로 미리 지정해주었습니다.
그런데 아래 validate_path 함수에서 추가적으로 if not all~ 구문을 사용해서 해당 인자들의 형식을 확인하도록 코드를 구성하셨는데 이러한 이유가 따로 있으신가요? 만약 해당 형식이 아니면 처음 클래스를 초기화할 때부터 에러가 발생하지 않나요?
항상 좋은 강의 만들어주셔서 감사드립니다.
답변 2
0
^^ 네,
혹시 강의 차시 또는 말씀하시는 코드를 함께 제공해 주면 정확한 답변이 가능할 것 같아요^^
주신 질문의 의도를 볼 때, typing 에 맞지 않는 경우에 python 은 입력 값을 강제하는 기능이 없기 때문에 별도로 validate_path 를 작성한 것이었을 겁니다. 해당 기능은 production 상황을 위해 필요한 것이며, dev 환경에서는 굳이 중요한 부분은 아닙니다.
하지만, 다른 언어들의 좋은 장점, 즉 variable 의 입력 값의 type 이 강제적으로 선언되고 사전에 통제될 수 있는 수단을 차용하면 에러를 사전에 방지하고 안정적인 production 환경을 가져갈 수 있다는 점에서, 그와 같은 습관을 기르자는 측면에서 아마 코드를 추가했었을 겁니다.
자세한 코드가 없는 상황에서 기억에 의존해 답변하는데는 한계가 있어^^ 혹시 답변이 부족했다면, 추가로 질문주세요~
열공!
0
안녕하세요, 인프런 AI 인턴입니다. 임해빈님.
질문을 통해 주신 사항은 클래스 초기화 시와 내부 메서드에서 형식 검사를 중복해서 수행하는 이유에 대한 것입니다. 보통 클래스 초기화 시에 입력 값의 형식을 검사하지만, 이후에도 메서드에서 재검사하는 이유는 몇 가지가 있습니다.
다양한 입력 가능성 처리: 전체 코드의 일관성을 유지하기 위해 역할이 다른 메소드에서도 형식을 검증해서 예측하지 못한 오류를 방지할 수 있습니다. 이렇게 하여, 사용자가 클래스의 초기화 이후 다른 메소드에서 예기치 않은 형식 변경을 시도할 때에도 안전 장치를 마련할 수 있게 됩니다.
모듈의 재사용성: 메서드가 다른 코드베이스에서 독립적으로 사용될 가능성을 염두에 두었다면, 이러한 경우를 대비해 메서드 자체에서도 형식을 점검할 필요가 있습니다. 이는 모듈이 더 나은 재사용성을 가지도록 합니다.
디버깅/테스트 용이: 여러 위치에서 중복 검사를 수행하면, 디버깅이나 테스트 시 특정 지점에서 문제가 발생하는지를 보다 쉽게 확인할 수 있습니다.
이와 같은 이유로 유효성 검사를 중복해서 수행하는 경우가 많으며, 이는 보다 안정적인 코드를 만들기 위한 방안입니다. 만약 이러한 방식 없이 코드를 간소화하고자 한다면, 코드의 특정 부분에서 유연성과 안전성을 잃을 가능성도 고려해야 합니다.
유사한 주제에 대해 추가적인 정보를 찾았습니다. 궁금하신 경우, Azure OpenAI 실습 불가 링크를 참고해보실 수 있습니다. 이는 의도된 주제와는 다르지만, Azure 관련 정보에 대한 토론이 포함되어 있습니다.
저는 임해빈님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.