My least favorite part of Python 3 is the new 28 byte int structure which spills over to 32 bytes at 1,073,741,824 (2^30).

    >>> sys.getsizeof(1073741823)
    28
    >>> sys.getsizeof(1073741824)
    32

As a directly result of the complicated implementation of Python 3 ints, we lost some important optimizations.

In Python/ceval.c, BINARY_SUBSCR can no longer easily have a fast path for tuple and list indexing with integers. This makes somelist[0] about as slow as somedict[0]:

    timeit36 -s 's=[0]' 's[0]'   # 0.0320 usec
    timeit36 -s 's={0:0}' 's[0]' # 0.0331 usec

Likewise, the builtin sum() function lost speed on its fast path for summing integers. That path is still there but it now uses the slow PyLong_AsLongAndOverflow() function instead of the PyInt_AS_LONG() fast macro.

    $ timeit27 'sum(xrange(1000000))'  #  7.32 msec
    $ timeit36 'sum(range(1000000))'   # 19.20 msec 

IMO, Python 3 int/long unification should have just dropped the trailing "L" from the display of long integers and called it done.

From the user's point of view, that would have unified the two types enough to mostly not care. You would still have two different types for int and long, but otherwise the switch back and forth was already somewhat seamless in Python 2.7.

The range of single cell ints was enormous (up to 9,223,372,036,854,775,807 or 2^63-1). It fulfilled typical use cases without spilling into slower and more complex multi-cell calculations and without impeding useful downstream optimizations for common cases.

    >>> sys.maxint
    9223372036854775807
    >>> sys.getsizeof(sys.maxint)
    24
    >>> sys.getsizeof(sys.maxint + 1)
    36

Once Python 3 was released and the API guaranteed that all integers were the same type regardless of size, that design choice was set in stone. So, now we will have to live with it forever :-(