The documentation for sys.float_info says that this is the way to get the smallest possible float:

>>> math.ulp(0.0)
5e-324

The value of sys.float_info.min (part of a previous answer that I deleted) gives the smallest normalized float, a much bigger value.

Use np.nextafter.

>>> import numpy as np
>>> np.nextafter(0, 1)
4.9406564584124654e-324
>>> np.nextafter(np.float32(0), np.float32(1))
1.4012985e-45

> .Machine$double.xmin
[1] 2.225074e-308

on my computer. YMMV. You do know that different computers can have different floating point?

Often you can work around precision problems by thinking. If you do calculation with no thought -- just pretending that the computer's "real" numbers are real real numbers -- then no amount of precision is enough to always get correct answers.

Edit: BTW "smallest usable positive number" doesn't define anything. That may account for the disagreement in numbers here. Look up denormalized numbers, which most but not all computers have.

Since Python 3.9 there is math.nextafter in the stdlib. Read on for alternatives in older Python versions.

Increment a python floating point value by the smallest possible amount

The nextafter(x,y) functions return the next discretely different representable floating-point value following x in the direction of y. The nextafter() functions are guaranteed to work on the platform or to return a sensible value to indicate that the next value is not possible.

The nextafter() functions are part of POSIX and ISO C99 standards and is _nextafter() in Visual C. C99 compliant standard math libraries, Visual C, C++, Boost and Java all implement the IEEE recommended nextafter() functions or methods. (I do not honestly know if .NET has nextafter(). Microsoft does not care much about C99 or POSIX.)

None of the bit twiddling functions here fully or correctly deal with the edge cases, such as values going though 0.0, negative 0.0, subnormals, infinities, negative values, over or underflows, etc. Here is a reference implementation of nextafter() in C to give an idea of how to do the correct bit twiddling if that is your direction.

There are two solid work arounds to get nextafter() or other excluded POSIX math functions in Python < 3.9:

Use Numpy:

>>> import numpy
>>> numpy.nextafter(0,1)
4.9406564584124654e-324
>>> numpy.nextafter(.1, 1)
0.10000000000000002
>>> numpy.nextafter(1e6, -1)
999999.99999999988
>>> numpy.nextafter(-.1, 1)
-0.099999999999999992

Link directly to the system math DLL:

import ctypes
import sys
from sys import platform as _platform

if _platform == "linux" or _platform == "linux2":
    _libm = ctypes.cdll.LoadLibrary('libm.so.6')
    _funcname = 'nextafter'
elif _platform == "darwin":
    _libm = ctypes.cdll.LoadLibrary('libSystem.dylib')
    _funcname = 'nextafter'
elif _platform == "win32":
    _libm = ctypes.cdll.LoadLibrary('msvcrt.dll')
    _funcname = '_nextafter'
else:
    # these are the ones I have access to...
    # fill in library and function name for your system math dll
    print("Platform", repr(_platform), "is not supported")
    sys.exit(0)

_nextafter = getattr(_libm, _funcname)
_nextafter.restype = ctypes.c_double
_nextafter.argtypes = [ctypes.c_double, ctypes.c_double]

def nextafter(x, y):
    "Returns the next floating-point number after x in the direction of y."
    return _nextafter(x, y)

assert nextafter(0, 1) - nextafter(0, 1) == 0
assert 0.0 + nextafter(0, 1) > 0.0

And if you really really want a pure Python solution:

# handles edge cases correctly on MY computer 
# not extensively QA'd...
import math
# 'double' means IEEE 754 double precision -- c 'double'
epsilon  = math.ldexp(1.0, -53) # smallest double that 0.5+epsilon != 0.5
maxDouble = float(2**1024 - 2**971)  # From the IEEE 754 standard
minDouble  = math.ldexp(1.0, -1022) # min positive normalized double
smallEpsilon  = math.ldexp(1.0, -1074) # smallest increment for doubles < minFloat
infinity = math.ldexp(1.0, 1023) * 2

def nextafter(x,y):    
    """returns the next IEEE double after x in the direction of y if possible"""
    if y==x:
       return y         #if x==y, no increment
             
    # handle NaN
    if x!=x or y!=y:
        return x + y       
    
    if x >= infinity:
        return infinity
        
    if x <= -infinity:
        return -infinity

    if -minDouble < x < minDouble:
        if y > x:
            return x + smallEpsilon
        else:
            return x - smallEpsilon  
        
    m, e = math.frexp(x)        
    if y > x:
        m += epsilon
    else:
        m -= epsilon
        
    return math.ldexp(m,e)

Or, use Mark Dickinson's excellent solution

Obviously the Numpy solution is the easiest.

>>> import sys
>>> sys.float_info
sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308,
 min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15,
 mant_dig=53, epsilon=2.2204460492503131e-16, radix=2, rounds=1)

The smallest is sys.float_info.min (2.2250738585072014e-308) and the biggest is sys.float_info.max (1.7976931348623157e+308). See documentation for other properties.

sys.float_info.min is the normalized min. You can usually get the denormalized min as sys.float_info.min * sys.float_info.epsilon. Note that such numbers are represented with a loss of precision. As expected, the denormalized min is less than the normalized min.

You can't prevent Python from generating a denormal float, but you can detect when it has done so by looking at the bit pattern of the result. If all the exponent bits are zero, you have a denormal. You can see the IEEE-754 binary64 format on Wikipedia. Since bitwise operations like & don't work on a float, the combination of struct.pack and struct.unpack are used to obtain the bit pattern as an integer.

import struct

def is_denormal(x):
    bit_pattern = struct.unpack('q', struct.pack('d', x))[0]
    return (bit_pattern & 0x7ff0000000000000) == 0

x = 1.0
while True :
    y = x
    x /= 2.0
    if is_denormal(x):
        break

print(y)
2.2250738585072014e-308

Of course not, and epsilon has little to do with it. For example,

>>> x = 1e-200
>>> x
1e-200

is far from epsilon, but

>>> x * x
0.0

underflows to 0. If we actually used epsilon instead, then, e.g., multiplying it by 0.25 would underflow to 0 too.

Provided your platform C compiler and hardware support the 754 standard, though, the sign of the zero would match the sign of the multiplicand:

>>> x * -x
-0.0

epsilon is the difference between 1 and the next representable float. That's not the same as the smallest float, which would be the closest number to 0, not 1.

There are two smallest floats, depending on your criteria. min is the smallest normalized float. The smallest subnormal float is min * epsilon.

>>> sys.float_info.min
2.2250738585072014e-308
>>> sys.float_info.min * sys.float_info.epsilon
5e-324

Note the distinction between normalized and subnormal floats: min is not actually the smallest float, it's just the smallest one with full precision. Subnormal numbers cover the range between 0 and min, but they lose a lot of precision. Notice that 5e-324 has only one significant digit. Subnormals are also much slower to work with, up to 100x slower than normalized floats.

>>> (sys.float_info.min * sys.float_info.epsilon) / 2
0.0
>>> 4e-324
5e-324
>>> 5e-325
0.0

These tests confirm that 5e-324 truly is the smallest float. Dividing by two underflows to 0.

See also: What is the range of values a float can have in Python?

Check out sys.float_info

>>> import sys
>>> sys.float_info 
sys.float_info(max=1.7976931348623157e+308, max_exp=1024, max_10_exp=308, min=2.2250738585072014e-308, min_exp=-1021, min_10_exp=-307, dig=15, mant_dig=53, epsilon=2.220446049250313e-16, radix=2, rounds=1)

From the docs

min       DBL_MIN      minimum positive normalized float 
min_exp   DBL_MIN_EXP  minimum integer e such that radix**(e-1) is a normalized float

On my system it is mentioned as min=2.2250738585072014e-308