top of page

많은 개발자들이 잘못 사용하고 있는 7가지 Python (파이썬) 함수

많은 개발자들이 잘못 사용하거나 사용하면서도 잘못 사용한다고 깨닫지 못하는 다음의 7가지 "파이썬 함수 (Python Functions)"를 알아 보겠습니다.


coder

1. enumerate() - 0부터 세기만 위한 것이 아닙니다.

컬렉션을 반복할 때, enumerate()는 위치 추적에 가장 적합한 함수입니다.


</> 예제 코드:


⚠️ 문제점: 루프 내부에서 인덱스를 추가하면 불필요한 시각적 노이즈가 발생하는데, 특히 몇 달 후에 코드를 다시 살펴볼 때 더욱 그렇습니다. 또한 자체 문서화도 어렵습니다. 새로운 팀원이 1을 추가하는 이유를 이해하려면 코드를 꼼꼼히 살펴봐야 합니다.


</> 수정된 코드:


이점: start 매개변수에 1부터 세고 싶다는 것을 명시적으로 표시하여 더 명확하게 보여줍니다. 또한, 이 방식은 유지 관리도 더 쉽습니다. 페이지 번호 매기기 등을 위해 시작 번호를 변경해야 하는 경우, 하나의 값만 변경하면 됩니다.


🖨️ 출력 값:

두 가지 접근 방식 모두 다음과 같은 출력을 제공합니다.


2. sorted() - 다중 키 정렬의 활용 부족

복잡한 데이터를 정리할 때, Python의 sorted() 함수를 사용하면 복잡한 정렬 논리를 작성하는 수고를 덜 수 있습니다.


</> 예제 코드:


⚠️ 문제점: 이 방식은 비효율적일 뿐만 아니라 실제로 부정확합니다. 각 정렬은 동일한 값을 가진 항목을 제외하고는 이전 순서를 손상시킵니다. 올바른 순서를 얻으려면 가장 중요하지 않은 키부터 가장 중요한 키 순으로 정렬해야 하는데, 이는 대부분의 사람들이 직관적으로 하는 것과는 정반대입니다. 이는 혼란스럽고 오류가 발생하기 쉽습니다.


</> 수정된 코드:


이점: 튜플(tuple) 방식은 모든 정렬 키를 한 번에 처리하므로 효율성과 유지 관리 용이성이 모두 향상됩니다. 튜플 요소의 순서를 통해 정렬 우선순위를 명확하게 전달합니다. 정렬 방향을 변경해야 하는 경우, -x['quantity'] 를 사용하여 사용자 지정 역순을 구현하는 것만큼 간단합니다.


🖨️ 출력 값:


3. map() - 리스트와 람다의 과도한 사용

map() 함수는 데이터를 변환하는 강력한 도구이지만, 많은 Python 개발자는 이 함수의 모든 잠재력을 활용하지 못하거나 다른 대안을 대신해 이 함수를 사용해야 하는 경우를 이해하지 못합니다.


</> 예제 코드:


⚠️ 문제점: 이 코드는 더 우아한 해결책이 있음에도 불구하고 map()과 람다 함수를 사용합니다. 또한 루프에서 값이 한 번만 사용될 때 결과를 리스트로 변환하면서 메모리를 낭비합니다.


</> 수정된 코드:


이점: 이 버전은 도메인 추출 함수를 직접 전달하고 map() 결과의 지연 반복자 특성을 유지합니다. Counter 클래스는 이러한 계산 작업에 적합하여 코드를 더욱 간결하고 효율적으로 만듭니다. 간단한 변환의 경우 리스트 컴프리헨션을 고려하지만, map()기존 함수를 적용하거나 여러 반복 가능 객체를 병렬로 작업할 때 매우 효과적입니다.


🖨️ 출력 값:


4. all() 과 any() - 불필요한 리스트 만들기

any()나 all() 같은 boolean 함수는 유용하지만 성능상의 이점을 무효화하는 방식으로 자주 오용됩니다.


</> 예제코드:


⚠️ 문제점: 전체 리스트를 메모리에 생성한 후 all()이나 any() 함수로 전달하면 함수의 효율성을 높이는 단락 회로 동작이 무효화됩니다. 대용량 데이터셋의 경우, 상당한 메모리 및 처리 시간이 낭비될 수 있습니다.


</> 수정된 코드:


이점: 제너레이터 표현식(Generator expressions)을 사용하면 이러한 함수가 결과가 결정되자마자 평가를 중지할 수 있습니다.


  • any() - 첫 번째 true 값을 찾으면 즉시 True를 반환합니다.

  • all() - 첫 번째 false 값을 찾으면 즉시 False를 반환합니다.


대용량 데이터 셋을 작업할 때나 시퀀스 초기에 조건 충족이 가능할 때 이 기능을 사용하면 성능이 향상될 수 있습니다.


5. zip() - 잘림 동작 무시

zip() 함수는 여러 반복 가능한 객체의 요소를 우아하게 연결하지만, 주의하지 않으면 기본 동작으로 인해 미묘한 버그가 발생할 수 있습니다.

</> 예제코드:

🖨️ 예제 코드의 출력 값:


⚠️ 문제점: zip()의 기본 기능은 가장 짧은 입력 시퀀스로 자동 축소하기 때문에, 멘토가 없는 학생은 오류나 경고 없이 출력에서 ​​사라집니다. 이러한 데이터 손실은 추적하기 어려운 미묘한 버그로 이어질 수 있습니다.


</> 수정된 코드:


이점: zip_longest()는 데이터가 자동으로 삭제되지 않도록 보장합니다. fillvalue의 값을 지정하면 일치하는 요소가 없음을 명시적으로 표시하고 조치가 필요하다는 명확한 표시를 제공합니다. 이 방법은 zip() 보다 더욱 강력하죠.


🖨️ 출력 값:

두 번째 접근 방식은 아래와 같이 올바르게 출력됩니다.


6. dict.get() - 기본값을 효과적으로 사용하지 않음

종종 최적화되지 않은 방식으로 사용되는 방법을 살펴볼 차례입니다. Python에서 dictionary를 처리하는 방식은 get() 메서드를 어떻게 사용하느냐에 따라 우아할 수도 있고, 투박할 수도 있습니다.


</> 예제코드:


⚠️ 문제점: 첫 번째 방법 1은 불필요하게 장황하고, 두 번째 방법 2는 get()을 사용한 후 조건문 검사를 해야 합니다. 위의 두 방법 모두 코드를 읽기 어렵게 만들고 오류 발생 가능성을 높입니다.


</> 수정된 코드:


이점: dict.get()의 두 번째 매개변수를 사용하면 장황한 조건문이 사라집니다. 이 접근 방식은 분기를 줄이고 가독성을 높이며, 존재하지 않는 키에 액세스하는 일반적인 오류를 방지합니다. 특히 API 응답, 사용자 입력 또는 누락된 값이 자주 발생하는 구성 데이터를 처리할 때 유용합니다.


7. functools.lru_cache() - 캐시 구성 오류

마지막으로 functools 모듈에서 흔히 잘못 사용되는 lru_cache라는 데코레이터를 살펴보겠습니다. 메모이제이션(memoization)은 강력한 최적화 기법이지만, 많은 개발자가 파이썬 내장 캐싱 데코레이터를 제대로 활용하지 못합니다.


</> 예제코드:


⚠️ 문제점: lru_cache를 매개변수 없이 사용하면, 기본 캐시 사이즈인 128개 항목을 적용하게 됩니다. 수천 개의 서로 다른 사용자 ID로 호출될 수 있는 함수의 경우, 이로 인해 캐시가 자주 삭제되고 불필요한 데이터베이스 쿼리가 발생할 수 있습니다.

</> 수정된 코드:


이점: 이 버전은 예상되는 고유 사용자 수에 맞게 더 큰 캐시 크기를 명시적으로 설정합니다. typed=True 매개변수는 캐시가 여러 유형의 인수(예: int의 사용자 ID와 str의 사용자 ID)를 구분하도록 하여 잠재적인 버그를 방지합니다. 캐시된 함수에서 변경 불가능한 반환 값(리스트 대신 튜플)을 사용하는 것도 예기치 않은 부작용을 방지하는 좋은 방법입니다.


</> 이제 다음과 같이 사용할 수 있습니다.


마무리

Python 내장 함수 사용 방식의 이러한 미묘한 차이는 언뜻 보기에는 사소해 보일 수 있지만, 이러한 차이점들이 모여 더 읽기 쉽고, 효율적이며, 유지 관리가 용이한 코드를 만들어냅니다. 최고의 Python 개발자는 단순히 코드를 잘 동작하게 만드는 데 그치지 않습니다. 언어의 모든 기능을 활용하여 우아한 솔루션을 개발합니다.


차후에 이러한 기능 중 하나를 사용할 때, 제대로 사용하고 있는지 잠시 생각해 보세요. 일상적인 코딩 패턴의 작은 개선은 시간이 지남에 따라 누적되어 코드베이스가 크게 향상되고 향후 발생할 수 있는 문제도 줄어듭니다.



참고:


pngegg (11)_result.webp

<Raank:랑크 /> 구독 하기 : Subscribe

감사합니다! : Thanks for submitting!

©2024 by <Raank:랑크 /> Knowledge is Power

  • Linkedin
  • Knowledge Arcadia - Icon 8c
  • Raanktone - Icon 16 - 1
  • Qubitronix
  • Naver Blog
bottom of page