fix(python): updated python examples to show correct usage of pass through for activities (#4131)

Author: flippedcoder

docs/develop/python/core-application.mdx

@@ -119,6 +119,8 @@ To return a value of the Workflow, use `return` to return an object.
 
 To return the results of a Workflow Execution, use either `start_workflow()` or `execute_workflow()` asynchronous methods.
 
+For performance and behavior reasons, users should pass through all modules, including Activities, Nexus services, and third-party plugins, whose calls will be deterministic using [`imports_passed_through`](https://python.temporal.io/temporalio.workflow.unsafe.html#imports_passed_through) or at Worker creation time by customizing the runner's restrictions with [`with_passthrough_modules`](https://python.temporal.io/temporalio.worker.workflow_sandbox.SandboxRestrictions.html#with_passthrough_modules).
+
 <div className="copycode-notice-container">
   <a href="https://github.com/temporalio/documentation/blob/main/sample-apps/python/your_app/your_workflows_dacx.py">
     View the source code
@@ -128,7 +130,10 @@ To return the results of a Workflow Execution, use either `start_workflow()` or
 
 ```python
 from temporalio import workflow
-# ...
+
+with workflow.unsafe.imports_passed_through():
+    from your_activities_dacx import your_activity
+    from your_dataobject_dacx import YourParams
 # ...
 @workflow.defn(name="YourWorkflow")
 class YourWorkflow:
@@ -160,7 +165,10 @@ You can customize the Workflow name with a custom name in the decorator argument
 
 ```python
 from temporalio import workflow
-# ...
+
+with workflow.unsafe.imports_passed_through():
+    from your_activities_dacx import your_activity
+    from your_dataobject_dacx import YourParams
 # ...
 @workflow.defn(name="YourWorkflow")
 class YourWorkflow:
@@ -365,7 +373,10 @@ A single argument to the Activity is positional. Multiple arguments are not supp
 
 ```python
 from temporalio import workflow
-# ...
+
+with workflow.unsafe.imports_passed_through():
+    from your_activities_dacx import your_activity
+    from your_dataobject_dacx import YourParams
 # ...
 @workflow.defn(name="YourWorkflow")
 class YourWorkflow:
@@ -435,7 +446,10 @@ You must provide either `schedule_to_close_timeout` or `start_to_close_timeout`.
 
 ```python
 from temporalio import workflow
-# ...
+
+with workflow.unsafe.imports_passed_through():
+    from your_activities_dacx import your_activity
+    from your_dataobject_dacx import YourParams
 # ...
 @workflow.defn(name="YourWorkflow")
 class YourWorkflow:

docs/develop/python/failure-detection.mdx

@@ -112,12 +112,12 @@ You could do this in response to an Activity Failure, if the failure of that Act
 
 ```python
 try:
-	credit_card_confirmation = await workflow.execute_activity_method()
+  credit_card_confirmation = await workflow.execute_activity_method()
 except ActivityError as e:
-	workflow.logger.error(f"Unable to process credit card {e.message}")
-	raise ApplicationError(
-		"Unable to process credit card", "CreditCardProcessingError"
-	)
+  workflow.logger.error(f"Unable to process credit card {e.message}")
+    raise ApplicationError(
+      "Unable to process credit card", "CreditCardProcessingError"
+    )
 ```
 
 This works differently in a Workflow than raising exceptions from Activities.

docs/develop/python/python-sdk-sandbox.mdx

@@ -36,7 +36,7 @@ Temporal's Python SDK uses a sandbox environment for Workflow runs to make devel
 If a Workflow Execution performs a non-deterministic event, an exception is thrown, which results in failing the Task Worker.
 The Workflow will not progress until the code is fixed.
 
-The Temporal Python sandbox offers a mechanism to _pass through modules_ from outside the sandbox. By default, this includes all standard library modules and Temporal modules. For performance and behavior reasons, users are encouraged to pass through all third-party modules whose calls will be deterministic. For more information, see [Passthrough modules](#passthrough-modules).
+The Temporal Python sandbox offers a mechanism to _pass through modules_ from outside the sandbox. By default, this includes all standard library modules and Temporal modules. For performance and behavior reasons, users should pass through all models, Activities, Nexus services, or other modules that are in separate files whose calls will be deterministic. For more information, see [Passthrough modules](#passthrough-modules).
 
 ## How it works
 
@@ -108,14 +108,13 @@ The [`SandboxRestrictions`](https://python.temporal.io/temporalio.worker.workflo
 
 ### Passthrough modules
 
-By default, the sandbox completely reloads non-standard-library and non-Temporal modules for every workflow run. Passing through a module means that the module will not be reloaded every time the Workflow runs. Instead, the module will be imported from outside the sandbox and used directly in the Workflow. This can improve performance because importing a module can be a time-consuming process, and passing through a module can avoid this overhead.
-:::note
+By default, the sandbox completely reloads non-standard-library and non-Temporal modules for every Workflow run. Passing through a module means that the module will not be reloaded every time the Workflow runs. Instead, the module will be imported from outside the sandbox and used directly in the Workflow. This can improve performance because importing a module can be a time-consuming process, and passing through a module can avoid this overhead.
 
+:::note
 It is important to note that you should only import _known-side-effect-free_ third-party modules: meaning they don't have any unintended consequences when imported and used multiple times. This is because passing through a module means that it will be used multiple times in a workflow without being reloaded, so any side effects it has will be repeated. For this reason, it's recommended to only pass through modules that are known to be deterministic, meaning they will always produce the same output given the same input.
-
 :::
 
-One way to pass through a module is at import time in the workflow file using the [`imports_passed_through`](https://python.temporal.io/temporalio.workflow.unsafe.html#imports_passed_through) context manager.
+One way to pass through a module is at import time in the Workflow file using the [`imports_passed_through`](https://python.temporal.io/temporalio.workflow.unsafe.html#imports_passed_through) context manager.
 
 ```python
 # my_workflow_file.py
@@ -130,7 +129,7 @@ class MyWorkflow:
      # ...
 ```
 
-Alternatively, this can be done at worker creation time by customizing the runner's restrictions.
+Alternatively, this can be done at Worker creation time by customizing the runner's restrictions.
 
 ```python
 # my_worker_file.py

docs/develop/python/set-up.mdx

@@ -183,7 +183,9 @@ Create a Workflow file (workflows.py):
 ```python
 from datetime import timedelta
 from temporalio import workflow
-from activities import greet
+
+with workflow.unsafe.imports_passed_through():
+    from activities import greet
 
 @workflow.defn
 class SayHelloWorkflow:
@@ -208,8 +210,10 @@ Create a Worker file (worker.py):
 import asyncio
 from temporalio.client import Client
 from temporalio.worker import Worker
-from workflows import SayHelloWorkflow
-from activities import greet
+
+with workflow.unsafe.imports_passed_through():
+    from workflows import SayHelloWorkflow
+    from activities import greet
 
 async def main():
     client = await Client.connect("localhost:7233")