Skip to content

Commit

Permalink
Update python-models.md (#6531)
Browse files Browse the repository at this point in the history
  • Loading branch information
mirnawong1 authored Nov 25, 2024
2 parents ddb55a6 + eb2a696 commit 321aed1
Showing 1 changed file with 28 additions and 0 deletions.
28 changes: 28 additions & 0 deletions website/docs/docs/build/python-models.md
Original file line number Diff line number Diff line change
Expand Up @@ -598,6 +598,34 @@ Python models have capabilities that SQL models do not. They also have some draw
- **These capabilities are very new.** As data warehouses develop new features, we expect them to offer cheaper, faster, and more intuitive mechanisms for deploying Python transformations. **We reserve the right to change the underlying implementation for executing Python models in future releases.** Our commitment to you is around the code in your model `.py` files, following the documented capabilities and guidance we're providing here.
- **Lack of `print()` support.** The data platform runs and compiles your Python model without dbt's oversight. This means it doesn't display the output of commands such as Python's built-in [`print()`](https://docs.python.org/3/library/functions.html#print) function in dbt's logs.

- <Expandable alt_header="Alternatives to using print() in Python models">

The following explains other methods you can use for debugging, such as writing messages to a dataframe column:

- Using platform logs: Use your data platform's logs to debug your Python models.
- Return logs as a dataframe: Create a dataframe containing your logs and build it into the warehouse.
- Develop locally with DuckDB: Test and debug your models locally using DuckDB before deploying them.

Here's an example of debugging in a Python model:

```python
def model(dbt, session):
dbt.config(
materialized = "table"
)
df = dbt.ref("my_source_table").df()
# One option for debugging: write messages to temporary table column
# Pros: visibility
# Cons: won't work if table isn't building for some reason
msg = "something"
df["debugging"] = f"My debug message here: {msg}"
return df
```
</Expandable>

As a general rule, if there's a transformation you could write equally well in SQL or Python, we believe that well-written SQL is preferable: it's more accessible to a greater number of colleagues, and it's easier to write code that's performant at scale. If there's a transformation you _can't_ write in SQL, or where ten lines of elegant and well-annotated Python could save you 1000 lines of hard-to-read Jinja-SQL, Python is the way to go.

## Specific data platforms {#specific-data-platforms}
Expand Down

0 comments on commit 321aed1

Please sign in to comment.