Python binding construction/deconstruction non-idiomatic

[cynthia]

The current initialization pattern looks like this:

import khaiii
api = khaiii.KhaiiiApi()
api.open()

Which effectively feels like a double construct. The issue is minor, but doesn't feel like idiomatic Python. Since calling the constructor is a contract that implies the caller is willing to do have the object ready, the second open() call feels rather odd. Same applies for the destructor, although this would be less of an issue since delete semantics are consistent and for most of the part the magical close() function will be obstructed away from the user.

What if, for example it worked like this by folding the two constructs into one?

from khaii import Khaiii
k = Khaii(library_path: str = '', resource_directory: str = '', options: dict = {})

[hubert-lee]

Thank you for your suggestion. I think your code is good.

This change does not guarantee backward compatibility. So I have to upgrade major version but will not. Because This project is still not enough to become v1.0. So we will resolve this issue at v0.2.
Thank you for your understanding.

[cynthia]

If the KhaiiiApi is a weak alias to the new wrapper class, or vice versa and it spits out a deprecation warning, it should be backwards compatible - given that you still have a deprecated function on open() that acts as a no-op filler.

[krikit]

구현 과정에서 여러 가지 문제점이 발생하여 위 f5d93fd 커밋은 롤백했습니다. 좀 더 논의가 필요해 보입니다.

1. KhaiiiApi 이름을 Khaii로 바꾸는 문제
   이 부분은 API들 간의 일관성을 유지하려면 Python 바인딩뿐만 아니라 C, C++ API 전체를 바꿔야 하는 큰 공사인데 좀 더 신중히 하기 위해 보류했습니다. 이름만이 문제라면 __init__.py에서 아래와 같이 하는 방법도 있을 겁니다.

from .khaiii import KhaiiiApi as Khaiii

2. 생성자와 open() 메서드를 합치는 문제
   객체지향 언어인 Python과 C++의 경우 open과 close가 각각 생성자와 소멸자에서 담당하면 되지만, C API의 경우는 open/close 세트로 가야 합니다. 일단 Python 바인딩에만 적용해 봤고, open() 메서드는 그대로 두고 생성자에서 리소스 경로와 옵션을 받도록 하여 마지막에 open() 메서드를 호출하도록 구현해 봤습니다. 그리고 open() 메서드를 deprecate 하기 보단 그대로 두면 기존 v0.1 사용자들은 open() 메서드를 두 번 호출하는 정도의 부담만 있고 호환성이 유지되는 편이 낫다고 판단하여 그렇게 해봤습니다.

3. 로그 레벨 설정이 꼬이는 문제
   기존에 Default log level should probably be warn for everything #12 Make log level default to warn on CLI and Python bindings. #12. #14 이슈를 통해 생성자 마지막에 로그 레벨을 "warn"으로 지정하는 코드가 들어갔습니다. 이 코드 다음에 open()을 하게 되면 리소스 오픈 시 로그 레벨은 무조건 "warn"으로 고정되고, 이 코드 전에 들어가면 "info"로 설정되게 됩니다. "warn"이 기본이라면 리소스 오픈 과정과 옵션에 관한 낮은 레벨의 로그를 볼 방법이 없습니다.
   그리고 set_log_level()과 함께 version() 메서드는 리소스를 오픈하지 않고도 호출할 수 있는 API인데, 이런 메서드들이 무조건 생성자에서 리소스 오픈을 거쳐야 하는 비효율성도 존재합니다. 앞으로 리소스 오픈이 필요 없는 API들이 추가되면 다른 문제가 발생할지도 모릅니다.

4. 옵션을 dict 객체로 받는 문제
   생성자와 open() 메서드에서 옵션을 dict 객체로 받도록 수정해 봤습니다. analyze() 메서드에서는 동적 옵션을 dict 형태로 바꿀 경우 매번 JSON 문자열로 변환해야 하고 성능 저하가 우려되어 그대로 JSON 문자열로 받도록 뒀습니다. 이는 C++ API에서 내부적으로 매번 analyze() 호출마다 JSON 파싱을 할 수 없으므로, 문자열의 메모리 address를 이용하여 캐싱하는 부분 때문입니다. 그래서 생성자, open() 메서드에서는 dict 객체를 받고, analyze()에서는 문자열로 받는 혼란이 생기더군요. 그리고 dict 객체와 JSON 객체 간의 미묘한 문법 차이로 인해 사용자에게 혼란을 줄 수도 있다고 생각해서 JSON 문자열로 그대로 두는 것이 낫다고 생각합니다.

결국 2)의 내용만 남게 되어 생성자의 마지막에 open() 메서드를 호출하도록 했는데 3)의 문제가 있는 코드를 이곳에 올려놨습니다. 로그 레벨 설정을 생성자의 마지막에 받도록 하는 부분을 넣어야 하나 고민 중입니다.

[krikit]

생성자에 log_level argument를 추가하고, default 값을 warn으로 설정해 봤습니다. 코드는 위 gist와 동일합니다.