jprdonnelly/pyscript
1
0
Fork 0
mirror of https://github.com/pyscript/pyscript.git synced 2026-03-01 17:03:33 -05:00
Code Issues Projects Releases Wiki Activity

Refactor the pyscript python package. (#1713)

Browse Source
This commit is contained in:
Antonio Cuni
2023-09-15 11:57:06 +00:00
committed by GitHub
parent 840bc803b7
commit 5191c45113
10 changed files with 54 additions and 73 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
pyscript.core/docs/README.md
View File

@@ -111,7 +111,7 @@ import { hooks } from "https://cdn.jsdelivr.net/npm/@pyscript/core";
// example
hooks.onInterpreterReady.add((utils, element) => {
console.lot(element, 'found', 'pyscript is ready');
console.log(element, 'found', 'pyscript is ready');
});
// the hooks namespace
@@ -148,9 +148,9 @@ Please note that a *worker* is a completely different environment and it's not p
However, each worker string can use `from pyscript import x, y, z` as that will be available out of the box.
## PyScript Module API
## PyScript Python API
The python module offers various utilities in either the main thread or the worker.
The `pyscript` python package offers various utilities in either the main thread or the worker.
The commonly shared utilities are:
@@ -257,15 +257,6 @@ We might decide to allow TOML too in the future, but the direct config as attrib
</div>
</details>
<details>
<summary><strong>why worker attribute needs an external file?</strong></summary>
<div markdown=1>
It would create confusion to have worker code embedded directly in the page and let *PyScript* forward the content to be executed as worker, but the separation of concerns felt more aligned with the meaning of bootstrapping a worker: it inevitably happens elsewhere and with little caveats or features here and there, so it's OK for now to keep that separation explicit.
</div>
</details>
<details>
<summary><strong>what are the worker's caveats?</strong></summary>
<div markdown=1>