update

docs/source/getting_started.ipynb

@@ -399,15 +399,9 @@
  "\n",
  "It turns out that the above problem often happens with functions like `iloc`, `loc` and `pipe`, whose return type is `Any` (and when you think about it, these can indeed return any possible datatype). When mypy sees that the return type is `Any`, it reasons that that could still be a `DataSet[Schema]` object, so it doesn't raise an error. It's only during runtime that we find out here that the return type actually is a `DataFrame`, but `mypy` doesn't do any runtime checks.\n",
  "\n",
- "Fortunately, Python offers other ways to do type checking during runtime. Here, we will use the `typeguard` package. "
- ]
- },
- {
- "cell_type": "code",
- "execution_count": null,
- "metadata": {},
- "outputs": [],
- "source": [
+ "Fortunately, Python offers other ways to do type checking during runtime. Here, we will use the `typeguard` package. \n",
+ "\n",
+ "```python\n",
  "from typeguard import typechecked\n",
  "\n",
  "@typechecked\n",
@@ -418,17 +412,12 @@
  " .iloc[:3]\n",
  " )\n",
  "\n",
- "try:\n",
- " res = foo()\n",
- "except TypeError as e:\n",
- " print(e)"
- ]
- },
- {
- "cell_type": "markdown",
- "metadata": {},
- "source": [
- "Alright, we now caught the error dead in its tracks! \n",
+ "res = foo()\n",
+ "```\n",
+ "\n",
+ "Which will raise a `TypeError` indicating that the returned object is a `DataFrame` instead of a `DataSet[Schema]`.\n",
+ "\n",
+ "(Of note, as of typeguard 4.0, the above unfortunately does not work in notebooks anymore, only in regular Python code.)\n",
  "\n",
  "We can improve this with one more step: instead of adding the `@typechecked` decorator to every function by hand (which could be error prone), `typeguard` can do this automatically when running the unit tests. To do this, simply run your unit tests using `pytest --typeguard-packages=foo.bar` (where `foo.bar` is your package name)\n",
  "\n",
@@ -501,4 +490,4 @@
  },
  "nbformat": 4,
  "nbformat_minor": 2
-}
+}