Introduction

Supporting coroutine code across Python 3.4 and 3.5 is mainly a syntax-compatibility problem. Python 3.4 uses generator-based coroutines with @asyncio.coroutine and yield from, while Python 3.5 introduces async and await. If you must support both, keep shared files parseable by 3.4 and isolate newer syntax.

What Changed Between 3.4 and 3.5

Python 3.4 coroutine style:

• @asyncio.coroutine
• yield from

Python 3.5 coroutine style:

• async def
• await

Important detail: Python 3.4 parser cannot read async def syntax at all. Even guarded runtime checks cannot help if source file fails to parse.

Safe Cross-Version Coroutine Style

For strict compatibility with both versions, write coroutines in 3.4 style.

1import asyncio
2
3@asyncio.coroutine
4def fetch_value(delay):
5    yield from asyncio.sleep(delay)
6    return 42
7
8@asyncio.coroutine
9def main():
10    value = yield from fetch_value(0.1)
11    print(value)
12
13loop = asyncio.get_event_loop()
14loop.run_until_complete(main())

This avoids parser errors on 3.4 while still running on 3.5.

Isolate Modern Syntax to Separate Modules

If you want modern async and await for newer runtimes, place it in separate files that are imported only when version is high enough.

1import sys
2
3PY35_PLUS = sys.version_info >= (3, 5)
4
5if PY35_PLUS:
6    from .modern_async import run_task
7else:
8    from .legacy_async import run_task

Both modules can expose same public function names to keep caller code stable.

Keep Event Loop APIs Uniform

Use wrappers to hide loop differences and reduce duplicate logic.

1import asyncio
2
3
4def run(coro):
5    loop = asyncio.get_event_loop()
6    return loop.run_until_complete(coro)

With one entry helper, migration from old to new style touches fewer call sites.

Testing Strategy for Dual Support

Cross-version support without test matrix is unreliable. Run CI jobs for each claimed version and include async behavior tests.

Recommended test cases:

• normal coroutine completion
• cancellation behavior
• timeout handling
• exception propagation

Without these tests, subtle behavior drift between versions can go unnoticed.

Packaging and Dependency Constraints

Use explicit metadata and dependency pinning for old runtimes. Ensure third-party async libraries still support 3.4 and 3.5 if you claim compatibility.

Document supported interpreter versions clearly in project README and packaging config. Hidden support assumptions create support burden for maintainers.

Migration Plan Away from Legacy Versions

Python 3.4 and 3.5 are end-of-life, so long-term maintenance costs are high. If possible, plan phased deprecation.

Suggested path:

1. Freeze compatibility branch.
2. Maintain security-only fixes for legacy users.
3. Move mainline to modern Python versions.
4. Replace generator-style coroutines with async and await.

This keeps code quality improving while preserving transition window. Publish that timeline early so downstream teams can coordinate deployment and dependency upgrades without emergency rewrites.

Avoid Mixed Style Confusion

Do not mix old and new coroutine styles randomly in the same file. Even where technically possible, readability and debugging suffer.

Use a project rule:

• legacy branch uses old style only
• modern branch uses async and await only

Consistency reduces cognitive overhead for contributors.

Common Pitfalls

• Adding async def to modules that must import on Python 3.4.
• Believing runtime version checks can bypass parser incompatibility.
• Mixing coroutine styles in one module without clear boundaries.
• Claiming backward compatibility without version-matrix CI.
• Delaying deprecation planning and carrying unsupported runtimes indefinitely.

Summary

• Python 3.4 and 3.5 compatibility is primarily a syntax parse issue.
• Use @asyncio.coroutine and yield from in shared compatible code.
• Isolate modern async syntax in version-gated modules.
• Validate behavior with explicit multi-version CI tests.
• Plan migration away from end-of-life interpreter targets.
• Document support policy clearly for users.