Python for Trading: Tools, Structure, and Pitfalls

The ecosystem

The look-ahead traps specific to Python

# WRONG: signal and execution on the same bar
signal = close > close.rolling(50).mean()
returns = signal * close.pct_change()
# The signal uses today's close; the return is today's move.
# You could not have known the close before it happened.

# CORRECT: shift the signal forward
returns = signal.shift(1) * close.pct_change()

# WRONG: centred rolling window
ma = close.rolling(50, center=True).mean()
# Uses 25 future bars in every value.

# WRONG: full-sample normalisation
z = (feature - feature.mean()) / feature.std()
# Every historical value knows the whole sample's statistics.

# CORRECT: expanding or rolling statistics
z = (feature - feature.rolling(250).mean())
     / feature.rolling(250).std()

# WRONG: fillna with a later value
df = df.fillna(method='bfill')
# Backward fill copies future data into the past.

Every one of these runs without error and produces attractive results. The backward fill case is particularly common, because filling missing data feels like routine cleaning rather than a modelling decision.

Structuring a trading project

project/
  data/
      loaders.py      fetch and validate; same interface
                      for historical and live
      validators.py   outlier checks, gap checks, staleness
  strategy/
      signals.py      PURE functions: (data, params) -> signal
      rules.py        PURE: (signal, state) -> desired positions
  risk/
      sizing.py       position size from equity and stop
      limits.py       veto authority over every order
  execution/
      interface.py    abstract: place, cancel, poll
      backtest.py     simulated implementation
      live.py         broker implementation
  state/
      store.py        persistent positions, orders, equity
  research/
      notebooks/      exploration only, never production
  tests/
      test_signals.py deterministic unit tests
      test_lookahead.py  shifts every input by one bar and
                         asserts results change appropriately

Key rule: strategy/ imports nothing from execution/ or data
fetching.  It receives data and returns decisions.  This is
what lets the same code run in backtest and live.

Practical pitfalls

• Floating point for money. Use integers of the smallest unit, or the decimal module, for cash and quantities. Accumulated floating point error in position tracking causes real reconciliation failures.
• Naive timestamps. Always use timezone-aware datetimes and store in UTC. Mixing naive and aware timestamps is a leading cause of off-by-one-session bugs.
• Chained assignment in pandas. Silently failing to modify the dataframe you think you are modifying. Use explicit assignment and check the result.
• Index alignment surprises. Operations between series with different indices produce silent NaNs rather than errors, which propagate into signals.
• Mutable default arguments. A classic Python trap that causes state to leak between calls in a long-running process.
• Unhandled exceptions in the trading loop. A single uncaught error can leave a position open with no stop. Wrap every cycle and fail closed.
• Notebooks in production. Convenient for research, unacceptable for execution: out-of-order execution and hidden state make behaviour unreproducible.

When performance matters

For strategies holding positions for minutes or longer, Python is fast enough and the bottleneck is almost always data loading rather than computation. Performance work is worth doing when research iteration becomes slow, not because live execution demands it.

• Vectorise research code, but keep the execution path explicit so timing remains visible.
• Use Parquet rather than CSV for stored data; the difference in load times is large enough to change how often you iterate.
• Cache computed features rather than recomputing them on every run.
• Profile before optimising. The slow part is rarely where you expect, and it is usually input and output rather than arithmetic.
• Consider polars or numpy directly for large panel datasets where pandas becomes memory-bound.
• Do not rewrite in a compiled language for latency unless you have measured that latency is actually your constraint, which for most retail strategies it is not.