docs: use tigris-boto3-ext in Python rename examples

[ovaistariq]

Summary

• Replace the manual before-sign.s3.CopyObject event registration in the Python rename docs and runnable example with rename_object and TigrisRename from tigris-boto3-ext.
• Add tigris-boto3-ext to examples/python/requirements.txt, Pipfile, and regenerated Pipfile.lock.

Test plan

• npm run dev and verify the Python tab on /docs/objects/object-rename/ renders the new helper / context-manager snippets.
• Run examples/python/rename-object.py against a real bucket to confirm the rename succeeds end-to-end.

🤖 Generated with Claude Code

---

Note

Low Risk
Low risk documentation/example-only change; main risk is potential dependency/version drift in the Python example environment due to updated Pipfile.lock (not production code).

Overview
Updates the Python rename-object docs and runnable example to use tigris-boto3-ext (rename_object helper and TigrisRename context manager) instead of manually registering a before-sign.s3.CopyObject event header.

Adds tigris-boto3-ext to the Python example dependencies (requirements.txt, Pipfile) and regenerates Pipfile.lock, bringing in updated pinned versions for boto3/related packages in that lockfile.

^{Reviewed by Cursor Bugbot for commit c8f2e75. Bugbot is set up for automated code reviews on this repo. Configure here.}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
docs-redirect	Ready	Preview, Comment	May 2, 2026 6:09am
tigris-os-docs	Ready	Preview, Comment	May 2, 2026 6:09am

[greptile-apps]

Greptile Summary

This PR replaces the manual before-sign.s3.CopyObject event hook in the Python rename docs and runnable example with the rename_object helper and TigrisRename context manager from tigris-boto3-ext, and wires up the dependency in Pipfile, Pipfile.lock, and requirements.txt.

• The python_version marker for tigris-boto3-ext in requirements.txt is >= '3.8', but Pipfile.lock (the authoritative generated source) pins it to >= '3.9'. Users on Python 3.8 installing from requirements.txt will hit a pip failure.

Confidence Score: 4/5

Safe to merge after fixing the python_version marker in requirements.txt.

One P1 defect: the wrong Python version marker for tigris-boto3-ext in requirements.txt would cause an install failure for Python 3.8 users. The rest of the changes are clean and correct.

examples/python/requirements.txt — wrong python_version marker for tigris-boto3-ext.

Important Files Changed

Filename	Overview
examples/python/requirements.txt	Added tigris-boto3-ext==0.3.0 but with a wrong python_version marker (>= 3.8 instead of >= 3.9), which can cause pip to fail on Python 3.8.
docs/objects/object-rename.mdx	Python tab updated to use tigris-boto3-ext; cleaner and correct, but missing a note that all copy_object calls inside TigrisRename are treated as renames.
examples/python/rename-object.py	Simplified to use rename_object helper; unnecessary response captures removed; clean refactor.
examples/python/Pipfile	Added tigris-boto3-ext = "*" correctly.
examples/python/Pipfile.lock	Regenerated lock file; tigris-boto3-ext 0.3.0 pinned with python_version >= 3.9, along with bumped boto3/botocore/jmespath/s3transfer/urllib3 versions.

_{Reviews (1): Last reviewed commit: "docs: use tigris-boto3-ext in Python ren..." | Re-trigger Greptile}

[greptile-apps]

The Python version marker for tigris-boto3-ext here says >= '3.8', but the Pipfile.lock resolves the package with python_version >= '3.9'. If a user on Python 3.8 installs from this file, pip will attempt to install tigris-boto3-ext==0.3.0, but the package itself requires Python 3.9+, causing a hard install failure.

Suggested change

	tigris-boto3-ext==0.3.0; python_version >= '3.8'
	tigris-boto3-ext==0.3.0; python_version >= '3.9'

[greptile-apps]

Missing context-manager scope warning

The old Python tab included an explicit note that registering the before-sign event affects every copy_object call. TigrisRename scopes that effect to the with block, but the docs don't mention this — users might not realise that any copy_object call made on the same client inside that block is treated as a rename, including incidental copies unrelated to the rename batch.