Learn to automate sales tasks with Python and CrewAI. Replace rigid Salesforce Flows with autonomous agents that handle complex reasoning and multi-step workflows efficiently.

Automating Recurring Sales Tasks with Python and AI Agents

Build voice-to-form automations for field technicians using Python and Salesforce. Learn hybrid architecture, STT setup, and secure API integration for hands-free data entry.

Building Python-Powered Voice-to-Form Automations for Field Technicians

Learn how to orchestrate multi-agent sales automation in Python. Bridge Salesforce Data Cloud with specialized agents for scalable, state-managed workflows.

Orchestrating Multi-Agent Sales Automation in Python

Build low-latency local voice AI pipelines in Python. Replace cloud APIs with Ollama, Whisper, and Coqui TTS for privacy and speed.

Building Local Voice AI Pipelines in Python: A Developer's Guide

Learn agentic workflows in Python. Master orchestration, state management, and verification loops to replace unreliable vibe coding with deterministic engineering.

Mastering Agentic Workflows: Python Skills for 2026 Developers

<picture>
  <source media="(min-width: 1px)" srcset="/images/python_freethreading_banner.png 1x" type="image/png" />
  <img src="/images/python_freethreading_banner.png" alt="Python's Free-Threading Mode: Is It Time to Care?" style="width:100%; border-radius:12px; margin-bottom: 2rem;" loading="eager" width="1200" height="630" />
</picture>

<h1>Python&#39;s Free-Threading Mode: Is It Time to Care?</h1>
<p>Python 3.13 shipped with something people argued about for two decades: the ability to disable the GIL.</p>
<p>Python 3.14 made it officially supported.</p>
<p>But &quot;officially supported&quot; doesn&#39;t mean &quot;deploy it on Friday.&quot; And it definitely doesn&#39;t mean &quot;it&#39;s fast.&quot;</p>
<h2>Where things actually stand</h2>
<p><strong>Python 3.13</strong> (October 2024): Free-threading shipped as experimental. You compile a separate binary (<code>python3.13t</code>). The specializing adaptive interpreter was <strong>disabled</strong> in free-threaded mode, causing a <strong>20-40% single-threaded performance regression</strong>. That&#39;s not a minor hit.</p>
<p><strong>Python 3.14</strong> (October 2025): Free-threading is officially supported (Phase II, per PEP 779). The specializing interpreter is re-enabled. Single-threaded penalty dropped to <strong>5-10%</strong>. First version where free-threading is a realistic option.</p>
<p><strong>Python 3.15</strong> (alpha): Current development. Free-threaded builds show ~9% overhead on Linux x86_64, ~6% on macOS ARM64 vs. GIL-enabled on same version.</p>
<p>Phase III — making free-threaded the default — has no PEP. No timeline. Realistic estimate: 2028-2029.</p>
<p><strong>The GIL is removable. The GIL is not removed. Those are different things.</strong></p>
<h2>The real benchmark numbers</h2>
<p>Not opinions. Measurements. From Meta&#39;s free-threading-benchmarking repo (pyperformance suite, April 2026).</p>
<h3>Single-threaded: you pay a tax</h3>
<table>
<thead>
<tr>
<th>Build</th>
<th>vs Python 3.12.6</th>
<th>vs GIL-enabled same version</th>
</tr>
</thead>
<tbody><tr>
<td>3.15.0a8 (GIL)</td>
<td>1.063x faster</td>
<td>baseline</td>
</tr>
<tr>
<td>3.15.0a8 (NOGIL)</td>
<td>1.027x slower</td>
<td><strong>~9% slower (Linux), ~6% (macOS ARM64)</strong></td>
</tr>
</tbody></table>
<p>Every Python object is larger now. The <code>PyObject</code> struct went from 16 bytes to ~32 bytes — it now includes <code>ob_tid</code>, <code>ob_mutex</code>, <code>ob_gc_bits</code>, <code>ob_ref_local</code>, <code>ob_ref_shared</code>. That&#39;s the cost of safe concurrent access.</p>
<p>The garbage collector changed from generational (3 generations) to non-generational (single generation with stop-the-world pauses). pymalloc was replaced with mimalloc.</p>
<p><strong>6-9% slower, 15-20% more memory. That&#39;s the price of free-threading.</strong></p>
<h3>Multi-threaded: where it wins</h3>
<ul>
<li><strong>Mandelbrot computation:</strong> Near-linear scaling with threads. GIL-enabled: zero scaling. Adding threads does nothing.</li>
<li><strong>Monte Carlo simulation:</strong> ~N× speedup with N threads.</li>
<li><strong>PyTorch inference:</strong> The GIL becomes the bottleneck with as few as 8-10 threads. Free-threading eliminates this.</li>
<li><strong>Dose-3D project:</strong> &quot;Astonishing&quot; results — less than half a day to adapt, multiprocessing bottleneck gone.</li>
</ul>
<p><strong>The pattern: CPU-bound Python code currently using multiprocessing is the primary beneficiary.</strong> If you&#39;re on asyncio or I/O-bound, free-threading doesn&#39;t help you.</p>
<h2>The ecosystem support picture</h2>
<p>This is the real gating factor. Not Python itself — the packages.</p>
<h3>What works</h3>
<table>
<thead>
<tr>
<th>Package</th>
<th>First version with support</th>
</tr>
</thead>
<tbody><tr>
<td>NumPy</td>
<td>2.1.0</td>
</tr>
<tr>
<td>SciPy</td>
<td>1.15.0</td>
</tr>
<tr>
<td>pandas</td>
<td>2.2.3</td>
</tr>
<tr>
<td>PyTorch</td>
<td>2.6.0</td>
</tr>
<tr>
<td>scikit-learn</td>
<td>1.6.0</td>
</tr>
<tr>
<td>Cython</td>
<td>3.1.0 (critical — many packages depend on it)</td>
</tr>
<tr>
<td>pydantic</td>
<td>2.11.0</td>
</tr>
<tr>
<td>Pillow</td>
<td>11.0.0</td>
</tr>
</tbody></table>
<p><strong>The scientific Python stack is solid.</strong> If you&#39;re in this space, free-threading is usable today.</p>
<h3>What doesn&#39;t work yet</h3>
<ul>
<li><strong>OpenCV</strong> — no release</li>
<li><strong>grpcio</strong> — no release</li>
<li><strong>vLLM</strong> — in progress</li>
<li><strong>JupyterLab</strong> — doesn&#39;t fully work (use free-threaded kernel with GIL-enabled Jupyter)</li>
<li><strong>spaCy</strong> — discussion open</li>
</ul>
<p><strong>The silent killer: importing a C extension without <code>Py_mod_gil</code> support silently enables the GIL.</strong> Your free-threaded Python becomes GIL-enabled the moment you import an unsupported package. You might not even notice.</p>
<h2>How to try it</h2>
<p>You don&#39;t need to compile from source:</p>
<pre><code class="language-bash"># macOS
brew install python-freethreading

# Linux (Ubuntu)
sudo apt-get install python3.14-nogil

# Using uv
uv venv --python 3.14t

# conda-forge
conda create -n nogil -c conda-forge python-freethreading
</code></pre>
<p>Verify:</p>
<pre><code class="language-python">import sys
sys._is_gil_enabled()  # Should be False
</code></pre>
<p><strong>Windows gotcha:</strong> The Python.org installer shares <code>site-packages</code> between GIL and free-threaded builds. Use separate virtual environments.</p>
<h2>The bugs you&#39;ll hit</h2>
<p><strong>Borrowed reference unsafety.</strong> <code>PyDict_GetItem</code> returns borrowed references that can become invalid. New <code>PyDict_FetchItem</code> APIs exist but aren&#39;t adopted everywhere. Silent data corruption, not crashes.</p>
<p><strong>Stop-the-world GC pauses.</strong> Single-generation GC with stop-the-world pauses. Python 3.14 adds incremental GC to mitigate, but latency-sensitive apps will feel it.</p>
<p><strong>Data races in pure Python.</strong> The interpreter won&#39;t crash. But shared mutable state (dict caches, module-level config) can produce wrong results. The GIL masked these bugs. Removing it reveals them.</p>
<p><strong>Extension compatibility.</strong> The biggest one. Import a non-free-threaded C extension and the GIL silently re-enables. You think you&#39;re running free-threaded. You&#39;re not.</p>
<h2>PyPy vs free-threaded CPython</h2>
<p>PyPy has never had a GIL in the traditional sense. Its JIT is generally 4-5x faster than CPython for single-threaded workloads.</p>
<p>So why isn&#39;t everyone on PyPy?</p>
<p><strong>C API compatibility.</strong> PyPy&#39;s compatibility layer has significant overhead. NumPy and SciPy run slower on PyPy than CPython. The entire scientific Python ecosystem assumes CPython&#39;s ABI.</p>
<p>Free-threaded CPython keeps full C API compatibility. That&#39;s the point — you get threading without leaving the CPython ecosystem.</p>
<table>
<thead>
<tr>
<th></th>
<th>CPython (GIL)</th>
<th>CPython (free-threaded)</th>
<th>PyPy</th>
</tr>
</thead>
<tbody><tr>
<td>Single-thread perf</td>
<td>Baseline</td>
<td>-5 to -10%</td>
<td>+400% (JIT)</td>
</tr>
<tr>
<td>Multi-thread perf</td>
<td>Blocked</td>
<td>Near-linear scaling</td>
<td>Limited by cpyext</td>
</tr>
<tr>
<td>C API compat</td>
<td>Full</td>
<td>Full</td>
<td>Partial</td>
</tr>
<tr>
<td>Package compat</td>
<td>Full</td>
<td>Growing</td>
<td>Poor (C exts)</td>
</tr>
</tbody></table>
<p><strong>PyPy is faster. Free-threaded CPython is more compatible.</strong> For most teams, compatibility wins.</p>
<h2>Should you migrate?</h2>
<p><strong>No, if:</strong></p>
<ul>
<li>Your code is I/O-bound (web APIs, database queries)</li>
<li>You&#39;re on asyncio and it&#39;s working</li>
<li>You depend on packages without free-threaded wheels</li>
</ul>
<p><strong>Maybe, if:</strong></p>
<ul>
<li>CPU-bound workloads currently using multiprocessing</li>
<li>Memory overhead of multiprocessing is a bottleneck</li>
<li>Your dependency tree has free-threaded wheels</li>
</ul>
<p><strong>Yes, if:</strong></p>
<ul>
<li>Scientific computing with C-extension-heavy workloads</li>
<li>Building new infrastructure for the next 5+ years</li>
<li>You&#39;ve verified your full dependency tree works</li>
</ul>
<h2>What I&#39;m doing</h2>
<p>I&#39;m not migrating production systems. But I&#39;m running our test suites against a free-threaded Python binary. Because in 12-18 months, when the ecosystem catches up, I want to know exactly what breaks.</p>
<p><strong>Start testing against it now. Don&#39;t deploy it yet.</strong> That&#39;s the right posture for 2026.</p>
<p>The GIL&#39;s removal is the most significant change to Python&#39;s concurrency model in the language&#39;s history. But significant doesn&#39;t mean ready. It means important enough to start paying attention.</p>
<hr>
<p><em>This is an independent comparison with no affiliate links. I&#39;m not sponsored by any tool or language mentioned. Benchmark data from Meta&#39;s free-threading-benchmarking repository and the pyperformance suite.</em></p>


Python 3.13 shipped with something people argued about for two decades: the ability to disable the GIL. Python 3.14 made it officially supported. But officially supported doesn't mean deploy it on Friday. And it definitely doesn't mean it's fast.

Python's Free-Threading Mode: Is It Time to Care?

PyO3 v0.28 adds full support for free-threaded Python 3.14 and the GIL release API. This guide covers building, packaging, and shipping Python extensions in Rust with maturin — from first function to published PyPI wheel.

Step-by-step guide to creating a Rust-backed Python extension using PyO3 v0.28 and maturin

How to Write and Ship Your First PyO3 Python Extension

Install Rust and maturin

Install Rust via rustup (rustup toolchain install stable), create a Python virtualenv, and run pip install maturin==1.8.3.

Scaffold the project

Run maturin new --bindings pyo3 my_extension to generate Cargo.toml, pyproject.toml, and src/lib.rs with all the right defaults.

Write your Rust function

Add #[pyfunction] to your Rust functions and register them in the #[pymodule] entry point using m.add_function(wrap_pyfunction!(your_fn, m)?).

Build and test locally

Run maturin develop --release to compile and install into your virtualenv. Import your module in Python and verify correctness before benchmarking.

Profile and confirm speedup

Use timeit to compare your Rust function against the Python baseline. Always benchmark release builds on real data representative of production workloads.

Generate CI and publish

Run maturin generate-ci github to create a GitHub Actions workflow. Push a version tag (v0.1.0) to trigger wheel builds for Linux, macOS, and Windows and automatic PyPI publish.

PyO3 v0.28 and maturin: Writing Python Extensions in Rust That Actually Ship


      <img src="/api/og?title=Python%20Hosting%20Options&subtitle=Vercel%2C%20Fly.io%2C%20Render%2C%20Railway%2C%20AWS%2C%20GCP%2C%20Azure" alt="Python hosting options comparison banner" />
      <h2>Pick Hosting Based on Framework and Latency Needs</h2>
      <p>Python apps span classic WSGI (Django, Flask) and modern ASGI (FastAPI, Starlette) with WebSockets and background workers. Your ideal host depends on concurrency model, cold‑start tolerance, data locality, and how much DevOps you want to own.</p>

      <h2>What We Compare</h2>
      <ul>
        <li><strong>Runtime model:</strong> Serverless functions vs containers vs VMs.</li>
        <li><strong>Cold starts and concurrency:</strong> Impact on APIs and WebSockets.</li>
        <li><strong>Data & networking:</strong> Managed DBs, VPC access, private services.</li>
        <li><strong>Observability:</strong> Logs, metrics, traces; ease of debugging.</li>
        <li><strong>Total cost:</strong> Requests vs vCPU/RAM vs long‑lived instances.</li>
      </ul>

      <h2>Quick Take</h2>
      <ul>
        <li><strong>Heroku:</strong> Easiest PaaS for Django/Flask; excellent DX; predictable dyno pricing.</li>
        <li><strong>Fly.io:</strong> Global low‑latency containers; great for FastAPI, sockets, and colocated Postgres.</li>
        <li><strong>Render:</strong> Simple apps/workers/cron with managed Postgres; sensible defaults.</li>
        <li><strong>Railway:</strong> Fast provisioning for prototypes/startups; usage‑based costs.</li>
        <li><strong>AWS/GCP/Azure:</strong> Maximum control/compliance with containers and managed DBs.</li>
        <li><strong>Vercel:</strong> Great when it’s a Next.js front‑end with light Python APIs.</li>
        <li><strong>DigitalOcean App Platform:</strong> Straightforward container PaaS with managed DBs and reasonable pricing.</li>
      </ul>

      <h2>Vercel</h2>
      <p>Vercel focuses on JavaScript/edge, but supports Python serverless functions for APIs and simple backends. Great for small FastAPI endpoints, webhooks, and glue code powering a Next.js front‑end. For long‑lived connections or heavy CPU, containers elsewhere may fit better.</p>
      <ul>
        <li><strong>Pros:</strong> Excellent DX, previews, global edge routing for front‑ends; simple Python functions for APIs.</li>
        <li><strong>Cons:</strong> Limited for long‑running Python and background workers; cold‑start considerations.</li>
      </ul>

      <h2>Fly.io</h2>
      <p>Fly runs containers close to users with private networking and persistent volumes. Great for Django/FastAPI with Postgres near the app. You control regions and can run background workers alongside web processes. WebSockets are first‑class.</p>
      <ul>
        <li><strong>Pros:</strong> Global regions, low latency, easy Postgres, good for websockets and workers.</li>
        <li><strong>Cons:</strong> You own scaling profiles and some ops; regional data consistency needs planning.</li>
      </ul>

      <h2>Render</h2>
      <p>Render offers simple apps, workers, cron jobs, and managed Postgres with CDN for static assets. It is a straightforward home for Django/FastAPI with predictable pricing and auto‑deploys from Git.</p>
      <ul>
        <li><strong>Pros:</strong> Easy setup, managed DBs, background workers, cron, SSL/CDN built‑in.</li>
        <li><strong>Cons:</strong> Fewer global regions than Fly; edge latency requires a CDN in front.</li>
      </ul>

      <h2>Railway</h2>
      <p>Railway makes provisioning services (web, DB, queues) quick with templates. Great for prototypes and startups that want speed. Pricing is usage‑based; watch idle costs. Good FastAPI/Django support with simple env management.</p>
      <ul>
        <li><strong>Pros:</strong> Fast onboarding, services marketplace, simple secrets/envs.</li>
        <li><strong>Cons:</strong> Regions and network controls are simpler; advanced compliance needs other clouds.</li>
      </ul>

      <h2>Heroku</h2>
      <p>Heroku popularized push‑to‑deploy for Python. A <code>Procfile</code> declares web and worker processes (e.g., <code>web: gunicorn app.wsgi</code>, <code>worker: celery -A app worker</code>). Add-ons simplify Postgres, Redis, and observability. Review free tier changes; paid dynos provide predictable monthly costs.</p>
      <ul>
        <li><strong>Pros:</strong> Mature DX, add‑ons, low ops, great docs, buildpacks for common stacks.</li>
        <li><strong>Cons:</strong> Not the cheapest at scale; region/latency options are limited vs newer edge platforms.</li>
      </ul>

      <h2>DigitalOcean App Platform</h2>
      <p>App Platform runs containers or source‑based builds with managed Postgres/Redis and a CDN. It’s a sweet spot for teams who want simple pricing, familiar infrastructure, and less vendor lock‑in than larger clouds.</p>
      <ul>
        <li><strong>Pros:</strong> Simple, affordable plans; managed DBs; autoscaling; regional choices.</li>
        <li><strong>Cons:</strong> Fewer enterprise features; you’ll wire some observability and edge behavior yourself.</li>
      </ul>

      <h2>AWS</h2>
      <p>Multiple paths: <em>Lambda</em> for serverless APIs (great with FastAPI via ASGI adapters), <em>App Runner/ECS/Fargate</em> for containers, and <em>EC2</em> for full control. Pair with RDS/Aurora, ElastiCache, SQS, and EventBridge. Superb when you need VPC/private networking and compliance.</p>
      <ul>
        <li><strong>Pros:</strong> Maximum control, managed databases/queues, VPC, identity/governance.</li>
        <li><strong>Cons:</strong> Higher ops complexity; cold starts if Lambda not tuned; costs need budgets/alerts.</li>
      </ul>

      <h2>GCP</h2>
      <p><em>Cloud Run</em> runs containers with scale‑to‑zero, ideal for FastAPI/Django containers. <em>App Engine</em> still works for classic apps. Pair with Cloud SQL, Memorystore, Pub/Sub. Clear logs and revisions make rollbacks painless.</p>
      <ul>
        <li><strong>Pros:</strong> Container‑first simplicity, good autoscaling, straightforward pricing, strong logs.</li>
        <li><strong>Cons:</strong> You’ll wire CDN/image transforms; VPC access requires config.</li>
      </ul>

      <h2>Azure</h2>
      <p><em>App Service</em> and <em>Functions</em> host Python well, with smooth Azure AD and enterprise networking. Pair with Azure SQL/Postgres, Redis, Service Bus. Good for enterprises deep in Microsoft ecosystems.</p>
      <ul>
        <li><strong>Pros:</strong> Enterprise identity, networking, monitoring; predictable governance.</li>
        <li><strong>Cons:</strong> Region latency may require Front Door/CDN; some features need manual tuning.</li>
      </ul>

      <h2>Performance & Concurrency</h2>
      <p>Use ASGI (Uvicorn/Hypercorn) for concurrent I/O; keep CPU‑bound work in workers or offloaded to queues. Warm serverless functions or provision min instances to reduce cold starts. Co‑locate DB/Redis with the app to avoid cross‑region latency. Validate WebSockets support; not all serverless products handle them well.</p>

      <h2>Deployment & Buildpacks</h2>
      <p>Prefer reproducible builds: pin Python version, use <code>pip-tools</code> or <code>poetry</code>, and multi‑stage Dockerfiles. For WSGI apps, run <code>gunicorn</code> with smart worker counts; for ASGI, use <code>uvicorn</code> or <code>gunicorn -k uvicorn.workers.UvicornWorker</code>. Keep static/media on object storage (S3/Spaces) and serve via CDN.</p>

      <h2>Background Jobs & Schedules</h2>
      <p>Queue CPU or long IO in workers: Celery/RQ/Huey with Redis/RabbitMQ. Use platform schedulers or cron for periodic tasks. Ensure idempotency and timeouts; instrument job success rates and runtimes.</p>

      <h2>Costs, Ops, and Observability</h2>
      <p>Serverless shines for spiky/low‑traffic APIs; containers win for steady load. Track function invocations, egress, DB connections, and idle time. Add structured logs, metrics, traces, and error tracking from day one. Ship security headers, rotate secrets, and patch dependencies regularly.</p>

      <h2>Decision Guide</h2>
      <ul>
        <li><strong>API with bursts, low idle:</strong> Lambda (AWS) or Cloud Run (min instances 0–1) for cost efficiency.</li>
        <li><strong>Global low latency + sockets:</strong> Fly.io for containerized FastAPI with Postgres close by.</li>
        <li><strong>Straightforward Django app:</strong> Render or Railway for speed, managed DBs, and easy workers.</li>
        <li><strong>Enterprise/VPC/compliance:</strong> AWS/GCP/Azure with containers and private networking.</li>
      </ul>

      <h2>Migrations</h2>
      <h2>Case Study (Composite)</h2>
      <p>A data‑heavy Django app with bursty traffic moved from a single VM to Cloud Run. We containerized with a slim Python base, switched to ASGI for async endpoints, offloaded reports to Celery workers on Cloud Run Jobs, and placed Cloud CDN in front. p95 latency dropped 32%, cold‑start impact disappeared after setting min instances to 1, and monthly costs fell ~18% vs the VM once traffic normalized.</p>

      <h2>Checklist</h2>
      <ul>
        <li>Pick ASGI for I/O concurrency; keep CPU in workers.</li>
        <li>Co‑locate DB/Redis; keep static/media in object storage behind a CDN.</li>
        <li>Pin Python and deps; add health/readiness probes for containers.</li>
        <li>Instrument logs/metrics/traces; alert on p95 latency, error rate, cold starts.</li>
        <li>Budget egress and function invocations; review after first week in prod.</li>
      </ul>
      <ol>
        <li>Decide ASGI vs WSGI and pick the server (Uvicorn/Gunicorn/Uvicorn‑Gunicorn).</li>
        <li>Containerize with a slim base image; multi‑stage build to keep images small.</li>
        <li>Externalize config via env; use managed secrets; set health checks and readiness probes.</li>
        <li>Place a CDN/edge in front; cache static/media; compress with Brotli.</li>
        <li>Add RUM/APM; set budgets/alerts for p95 latency, error rate, cold starts.</li>
      </ol>

      <p>Need help choosing? See our <a href="/services">Services</a> or <a href="/contact">talk to us</a>—we’ll recommend the leanest Python hosting setup for your goals.</p>
    

The 2025 guide to hosting Python apps and APIs—serverless, containers, edge, costs, and trade‑offs for Django/FastAPI/Flask.

Select the best hosting platform for your Django, FastAPI, or Flask application

How to Choose Python Hosting

Assess Your Workload

Determine if you need serverless (bursty traffic), containers (steady load), or VMs (full control).

Choose ASGI vs WSGI

Use ASGI (Uvicorn) for FastAPI/async apps or WSGI (Gunicorn) for traditional Django/Flask.

Consider Data Locality

Co-locate your database with your app. Use managed Postgres from Fly.io, Render, or your cloud provider.

Containerize Your App

Build with a slim Python base image, use multi-stage builds, and add health/readiness probes.

Set Up CDN and Caching

Place a CDN in front for static assets and enable Brotli compression for better performance.

Add Monitoring

Instrument with structured logs, metrics, and traces. Set alerts for p95 latency and error rates.

#Python