Why Jupyter Kernel can’t Compile it’s own Cells?

I hope my suggestion is implementable (which I’m not seeing anywhere at the moment);
yet, it might be unrealistic due to possilble conceptual misunderstandings
and/or terminology misuses from my side.

Dislaimer! If you have a very little time,
and yet a VERY BIG LOVE for VSCode or python
— feel free to Ctrl+F “The Summury” at the very end of my question,
where you’ll be able to decide for yourself if its worthwhile.

..So.

It all comes back to the days when I’ve been using Visual Basic for Applications
(MS Excel to be specific); I had some 3 years of close relationship with VBA-Excel environment,
so the best way to explain both my understanding and what’s might be missing
— is through the following table of comparison
(from back- to front-end, so to speak):

Code-development layers in… ▶▶▶	a: VBA-Excel (various)	b: VSCode-Jupyter (`.py` and few others)	B: VSCode-Jupyter (`.ipynb`)
1. Compiler.	VBA (excel.exe).	code.exe +Jupyter extension. lacking key-feature (which is in question).	same as b1.
2. Interpreter.	same as a1.	python.exe (separate, 3rd-party feature).	same as b2.
3. ‘Project’.	a part of a1. a ‘main’ script file, to which all other script files are linked to (through ‘compilation‘).	— might be (possibly?..) implemented through Jupyter extension upgrade.	same as b3.
4. Scripts.	a few off-topic specifics. could be semi-automatically linked into one ‘Project’ on a level of Compiler.	you just go `import scriptname`, and call its callable, or public, or whatever. kind of the same as a4, except the topic of my question.	`JSON`-based markdown and Jupyter code cells. kind of the same as b4, except the topic of my question.

So, this questionsuggestion
is about VSCode and Jupyter; and more preciesly
— it’s about Jupyter code cells:

Jupyter code cells
(or analogus) in… ▶▶▶ a: VBA-Excel b: .py B: .ipynb

Jupyter code cells (or analogus) in… ▶▶▶	a: VBA-Excel	b: `.py`	B: `.ipynb`
5. ‘Declaring’ method.	`Sub subname()` actually, in VB `Sub` plays role of pythonic `def`, but in hereby context — it is more similar to code cells.	`# %%` you just type this caption anywhere in your code, and the Jupyter extension treats it as if it was a separate file (to run, or debug).	same as b5, except instead of just one `# %%` — you have a mixed zoo of markdown(s) and code cells.

5. ‘Declaring’ method.

Sub subname()

actually, in VB
Sub plays role
of pythonic def,
but in hereby context
— it is more similar
to code cells.

# %%

you just type this caption anywhere
in your code, and the Jupyter extension
treats it as if it was a separate file
(to run, or debug).

same as b5,
except instead of just one # %%
— you have a mixed zoo of markdown(s)
and code cells.

Therefore, in that last (5th) row of our table
— all three cases are providing to user a similar way
of running and debugging ever smaller pieces of code,
whether they need:

a thorough investigation of some part of the script; or
just to do extremely fast experimental runs
(to delete them shortly after).

And all this
— right inside your extremely-complicated script,
without any need to worry about accidental executions,
right?

Wrong! Wrong!
Here is how it’s actually implemented (as of today):

Scripts layouts
with Jupyter code cells
(or analogus) in… ▶▶▶ a: VBA-Excel b: .py B: .ipynb

Scripts layouts with Jupyter code cells (or analogus) in… ▶▶▶	a: VBA-Excel	b: `.py`	B: `.ipynb`
6. Structures it all usually reduces to — in order to actually `do_stuff()`.	Script_1: `declare_publics()` `open_some_folder(path)` `delete_System32()` ^ keep an eye on this one. Script_2: `do_stuff()` `open_champaigne_bottle()`	Script_1: `# %%` (1st cell): `declare_publics()` `open_some_folder(path)` `# %%` (2nd cell): `delete_System32()` ^ keep an eye on this one. Script_2: `# %%` (3rd cell): `import Script_1` `do_stuff()` `open_champaigne_bottle()`	a single Notebook: `# %%` (1st cell): `declare_publics()` `open_some_folder(path)` `# %%` (2nd cell): `delete_System32()` ^ keep an eye on this one. Markdown (because why not) `# %%` (3rd cell): `# import Script_1` (commented for later) `do_stuff()` `open_champaigne_bottle()`
7. Consequences of `do'ing_stuff()` right as above — via running a Script_2, or ‘the 3rd cell’.	👍 stuff actually done, with champaigne bottle just opened.	`BSOD`, or smth. 👎	same as b7.
8. ..Why?	well, because in order to `do_stuff()` with Script_2, or may be `do_other_things()` with Script_N — one may find lines like `declare_publics()` and `open_some_folder(path)`, and such (like, most basic functions) are both extremely important and ‘popular‘; and therefore — one may want to configure them in, or access them from just one place where they would live (like Script 1; or ‘the 1st cell’). continue in b8. ▶▶▶	and! because when one actually is writing a code (like from bed to bed; consulting with Google on each 5th, or 10th ‘sentence’) — one saves few metric tonns of their time if they’re NOT scrolling through tabs, or windows, or THOUSANDS of lines of their code with their tiny hands and 8 y.o. mouse wheels — in order to just. reload. a Kernel. continue in B8. ▶▶▶	or doing the same as b8 — except in order to navigate to ‘the 1st cell’ (or a Markdown’s with most important ones), and click ‘Run cell’ on it; and then, by using (of course! why not..) some ‘Alt +Left Arrow’ — to go to your current working position; or via ‘the outline’, plus few random (ATTENTION-requiring) scrollings afterwards — each. single. time. …
9. No, why consequences?..	ah.. well, because when you `do_stuff()` (or other things) in VBA; and when that requires you to `open_some_folder(path)` (just per say) — all you have to do is just click ‘Debug > Compile’ in the main menu. ..and any callable (I mean, any callable) — just. becomes. ‘accessible’. continue in b8. ▶▶▶	— that is, unlike both `.py` and `.ipynb` cases in the current VSCode, where you need to run the whole Script_1 — because you will get ‘`open_some_folder` is not defined’ ERROR otherwise. or you will have to do ‘the scrolling’ part — in order to run only ‘the 1st cell’ (not to mention other dependencies). continue in B8. ▶▶▶	meaning, that either way — you are NOT able to use Script_1 for ‘fast and experimental’; or ‘exaggerated’ stuff — like `delete_System32()`. ..any of which — again, requiers a LOT of body language and attention. at least with VSCode and python.

6. Structures
it all usually reduces to
— in order to actually
do_stuff().

Script_1:

declare_publics()
open_some_folder(path)

delete_System32()
^ keep an eye on this one.

Script_2:

do_stuff()
open_champaigne_bottle()

Script_1:
# %% (1st cell):
declare_publics()
open_some_folder(path)
# %% (2nd cell):
delete_System32()
^ keep an eye on this one.

Script_2:
# %% (3rd cell):
import Script_1

do_stuff()
open_champaigne_bottle()

a single Notebook:
# %% (1st cell):
declare_publics()
open_some_folder(path)
# %% (2nd cell):
delete_System32()
^ keep an eye on this one.
Markdown
(because why not)
# %% (3rd cell):
# import Script_1
(commented for later)
do_stuff()
open_champaigne_bottle()

7. Consequences
of do'ing_stuff()
right as above
— via running a Script_2,
or ‘the 3rd cell’.

👍 stuff actually done,
with champaigne bottle
just opened.

BSOD, or smth. 👎

same as b7.

8. ..Why?

well, because
in order to do_stuff()
with Script_2, or may be do_other_things()
with Script_N
— one may find lines like declare_publics() and open_some_folder(path),
and such (like, most basic functions) are both extremely important and ‘popular‘;
and therefore
— one may want
to configure them in,
or access them from just one place where they would live
(like Script 1; or ‘the 1st cell’).

continue in b8. ▶▶▶

and! because when one
actually is writing a code
(like from bed to bed;
consulting with Google
on each 5th, or 10th ‘sentence’)
— one saves few metric tonns
of their time if they’re NOT
scrolling through tabs,
or windows, or THOUSANDS
of lines of their code with their
tiny hands and 8 y.o.
mouse wheels
— in order to
just. reload.
a Kernel.

continue in B8. ▶▶▶

or doing the same as b8
— except in order
to navigate to ‘the 1st cell’
(or a Markdown’s with
most important ones),
and click ‘Run cell’
on it; and then, by using
(of course! why not..)
some ‘Alt +Left Arrow’
— to go to your current
working position;
or via ‘the outline’,
plus few random
(ATTENTION-requiring)
scrollings afterwards
— each. single.
time.

…

9. No, why consequences?..

ah..
well, because
when you do_stuff()
(or other things) in VBA;
and when that requires you to
open_some_folder(path)
(just per say)
— all you have to do is
just click ‘Debug > Compile’
in the main menu.

..and any callable
(I mean, any callable)
— just. becomes.
‘accessible’.

continue in b8. ▶▶▶

— that is,
unlike both .py
and .ipynb cases
in the current VSCode,
where you need to run
the whole Script_1
— because you will
get ‘open_some_folder
is not defined’ ERROR
otherwise.

or you will have to do
‘the scrolling’ part
— in order to run only
‘the 1st cell’ (not to mention
other dependencies).

continue in B8. ▶▶▶

meaning,
that either way
— you are NOT
able to use Script_1
for ‘fast and experimental’;
or ‘exaggerated’ stuff
— like delete_System32().

..any of which
— again, requiers a LOT
of body language
and attention.

at least with VSCode
and python.

“The Summury”.

..So, I had looked into PyCharm and standalone Jupyter
(from Anaconda), and I also did some few thousand lines of code in Google Colab
(which is almost identical to how VSCode treats .ipynb files in our table),
and from what I had seen
— I can say, that none of them are providing the same
running and debugging features, as VBA-Excel does.

That is, until someone here will shed a light
on some other VSCode extension, or other IDE out there,
that already fits my ‘suggestion’ anyhow.

???.. Or
— will may be explain,
why this sort of things are just impossible
with ‘3rd-party interpreters’, like python.exe
(or for any other reason).

Or any other feedback, of course.

I mean.. if VSCode does have all these options..
like, if it easily distinguishes a variable from storage.type.function
(say, via > Developer: Inspect Editor Tokens and Scopes, when it colores them)
— why can’t it, idk; ‘list’ positions of all def‘s, and public‘s and such,
and then, sort of, “goto” them (just for one cell)
— ???..

Idk how exactly do ‘compilers’ work, btw:
never met them that close.