The code version of python -i <filename>

[Abdur-Rahmaan Janhangeer]

Oh thanks a lot, i was way from list this week

Just a note: it's pretty amazing to have at Chris Angelico at your local PUG

Else,

Well, let's say you have a lib that you need to provide users with a shell
for them to try
out functions, no need to translate functions to  cli args. Like Django
provides a shell
for users to use. The aim of injection is to allow code usage without
imports.

The presentation write-up is pretty new to me as I never approached clean
code
presentations. My presentations have always been hard text on screen
<https://youtu.be/pvwvRi6iMds>.

As all coders my natural instinct is to ... code a prez tool from scratch!

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius


On Fri, Sep 17, 2021 at 5:04 AM dn via Python-list <python-list at python.org>
wrote:

> Abdur-Rahmaan,
> Apologies for delay: several last-minute tasks were landed on me, so I
> haven't been able to 'read the list' since last week.
>
>
> > If i have a file name flower.py and i add x = 1 in it.
> > When i run python -i flower.py i get a shell
> >>>>
> >
> > If type x i get 1
> >>>> x
> > 1
> >
> > The values are auto injected.
> >
> > How do i start a shell by code with values already injected? Thanks
>
>
> What do you want to achieve with this?
>
>
> At this week's local PUG meeting, I was 'the warm-up act' for (our own)
> @Chris Angelico giving a talk about 'the walrus operator', his part in
> that PEP, and how anyone-and-everyone can contribute to the Python
> eco-system.
>
> My contribution was to start at the Python-Apprentice level, talking
> about different types of 'operators', and preparing the stage?beach for
> the more advanced 'walrus'. It culminated in a live-coding demo of
> Conditional expressions/the "ternary operator".
>
> Live-coding demos are always better (for the audience) than passively
> watching a progression of slides! However, that territory is labelled
> 'here be dragons', for presenters! (continuing the tradition of slide
> projectors which don't accept my cartridge/carousel, white boards
> lacking pens with ink, over-head projectors with blown lamps (and a used
> spare), RGB projectors which only/don't accept VGA cables, ...)
>
> Further: we've all suffered YouTube wannabes telling us how easy it is
> to do 'something', typing and mis-typing and re-typing, and generally
> wasting our time... (have they not heard of video-editing?) Those of us
> who present 'live' (unlike my video-lectures), can't rely upon a later
> 'cosmetic' stage to apply lip-stick on any 'pigs' in our typing!
>
> Rather than using a "script" document (as-in 'speaker's notes') to
> prompt me with what to type next, the remote presentation tool
> (BigBlueButton web-conferencing) allows the 'projection' of a (desktop)
> terminal window - whilst hiding my text-editor. Thus, at the appropriate
> moment, I was copy-pasting from my 'script' in xed, into the terminal's
> Python REPL. Worked very well - it appears as if I'm a very fast typist!
> Of course, sometimes I was copying one line of code at a time, and at
> others, multiple lines - thus (*still*) giving opportunity to 'fluff my
> lines'. Hah!
>
> For live-demos, I like to use pedagogical (teaching) 'patterns' of a
> structured narrative (as one would with a lecture) but trying to
> encourage involvement (if not "active learning"), using a "worked
> example" (learning through demonstration), and "discovery" (which
> because it is effectively a 'presentation', really means 'gradual
> revelation').
>
> (apologies for any non-obvious, non-Python, jargon - cognitive
> psychology (learning how we learn) is my research field)
>
> Thus, the demo proceeds on a step-by-step basis. At each step the
> process is:
> 1 present a problem/ask a question
> 2 ensure understanding/invite comments/accept suggestions
> 3 present code snippet*
> and (presumably) execute same to produce an 'answer'
> 4 comment/discuss/critique
>
> - which, unless 'the end', should lead us back to nr1 for the 'next
> step'...
>
> * in other scenarios, this might involve use of code suggested by the
> audience!
>
> Before reading this thread, I had been thinking that Jupyter might
> empower the combination of Python, 'steps', and 'live-coding'. However,
> a notebook will likely display future steps on-screen, before the
> current one has been completed (which defeats 'gradual revelation' -
> somewhat like jumping to 'the last page to find-out who dunnit') -
> unlike (say) presentation slides where no-one can see 'what comes
> next'/jump ahead, before the earlier 'lesson' has been learned.
>
> NB I'm not seeking 'information hiding' or encapsulation by its Java
> definition; but do want people to consider (only) one sub-problem at a
> time, and thus building-up to the whole solution! If one first
> understands the problem(s) and then contributes to generating a
> solution, you will learn far more effectively than if I simply
> lecture/read the Python manual-entry to you!
>
> Courtesy of this discussion, am wondering if it might be possible to
> structure what is currently a 'teaching notes' or "script" document
> (from which I was copy-pasting), and build a 'projector' program which
> will run a sub-interpreter* to run exactly one 'step' of the
> 'live-coding' demo at a time (whilst also retaining the option of REPL
> access, to be able prove or expose short-comings (nr 4, above), and
> without revealing the 'what comes next'?
>
> * rather than python -i; am considering Lib.runpy, and/or Lib.code
>
>
> How might any of this relate to your interest?
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
>