PythonCharmers/python-future

types.IntType, types.LongType treated differently to int, long

Open

#264 建立於 2017年1月19日

在 GitHub 查看
 (0 留言) (0 反應) (0 負責人)Python (1,172 star) (327 fork)batch import
0.19bughelp wantedtype-conversion

描述

Currently,

if type(time) not in (int, long): is not converted by futurize --stage1 -w file.py (version 0.15.2) but: if type(time) not in (types.IntType, types.LongType): is converted to: if type(time) not in (int, int)

I would have thought that these two should be treated the same.

貢獻者指南

技術棧
python
領域
toolingdeveloper experience
議題類型
bug
難度面向新貢獻者的預計實作難度，1 表示很小改動，5 表示專家級工作。
3
預計時間有經驗貢獻者完成調查、實作、測試並準備 pull request 的粗略時間範圍。
1-3 hours
活動狀態議題目前的可參與程度：新鮮、活躍、陳舊、阻塞或等待維護者輸入。
stale
清晰度議題是否清楚說明預期改動、驗收標準和下一步。
clear
前置要求
Python 2/3 compatibilityfuturize tool usageunderstanding of type checkspython future library structure
新手友善度1-100 的估計分數，表示該議題對首次貢獻者的友善程度。
50
研究方向
Investigate how futurize stage1 handles type checks. The issue reports that `type(x) not in (int, long)` is not converted but `type(x) not in (types.IntType, types.LongType)` is converted to `(int, int)`. Look in the futurize source code (likely in `libfuturize/fixes/` or similar) for the pattern matching `types.IntType` and ensure the same logic applies to the built in `int` and `long`. The fix should make the conversion consistent. The issue is clear but requires understanding of the tool's fix infrastructure and Python 2/3 type differences.
types.IntType, types.LongType treated differently to int, long · PythonCharmers/python-future#264 | Good First Issue