PythonCharmers/python-future

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

Open

#264 opened on Jan 19, 2017

View on GitHub
 (0 comments) (0 reactions) (0 assignees)Python (1,172 stars) (327 forks)batch import
0.19bughelp wantedtype-conversion

Description

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.

Contributor guide

Tech stack
python
Domain
toolingdeveloper experience
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-3 hours
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Python 2/3 compatibilityfuturize tool usageunderstanding of type checkspython future library structure
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
50
Research direction
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.