3
爲什麼決定將觀察者緯度/經度值視爲弧度，而將字符串值視爲十進制度？pyephem - 觀察者緯度/經度類型
在處理Python中的緯度/經度值時，我通常會處理浮動對象。如果星星右對齊，那麼可能有一個int對象或兩個漂浮物，但大多是漂浮物。我總是天真地寫下這樣的代碼：
lat = 0.0
lon = 0.0
observer = ephem.Observer()
observer.lat = lat
observer.lon = lon
# etc... etc...
然後，我被燒了。我被燒，因爲我的緯度/經度值是十進制度數，而不是弧度。這通常是不好的，因爲我最終撓撓腦袋想知道我做錯了什麼。最後，我最終轉換爲弧度。現在理論上，我能做到這一點，以獲得正確的結果：
observer = ephem.Observer()
observer.lat = str(lat)
observer.lon = str(lon)
，但似乎也靠不住，我還以爲我的價值觀必須是弧度！哦，等一下，只有當它是一個浮動。我明白接受字符串或浮動對象是好的，但接受基於python類型的不同數字類型似乎不一致。我希望這兩個任務採取同樣的數字類型，像這樣：
lat = lon = 0.55
observer.lat = lat # float lat is assumed to be in radians
observer.lon = lon # float lon is assumed to be in radians
lat = lon = '0.55'
observer.lat = lat # string lat is assumed to be in radians
observer.lon = lon # string lon is assumed to be in radians
然後轉換操作符可以爲十進制度/ DMS提供：
lat = '25.0'
lon = 25.0
observer.lat = ephem.to_rad(lat)
observer.lon = ephem.to_rad(lon)
然後to_rad功能會明確地假定小數學位被提供爲浮子或絃樂對象。在這一點上，接口將是一致的。我通過_libastro.c非常簡短地挖掘並研究了to_angle函數，它是這個問題的核心。
我想不出一個很好的理由不實施這個。事實上，我會自願去做！但在我開槍之前，我知道我不是libastro/pyephem專家，所以我想打開這個問題來確保這是有道理的。這完全有可能是因爲很好的理由，我只是無法理解而感到困惑。
如果有經驗的用戶或熟悉軟件核心的人可以發表評論，我將不勝感激。
謝謝您提前！