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@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 > -- https://mail.python.org/mailman/listinfo/python-list
