Use the Python Shell or REPL from VSCode

Today, one of my students asked how to use the Python shell from VSCode. It is possible to do manually by navigating to the directory of the python file you are working with, writing python and pressing return to enter the shell, then write import filename (without .py extension) and then you may interact with the code. If you import this way, you have to use filename.function() or filename.variable to interact with the code. The other way is to specify what you want to import, for example, from oblig23 import alder. It is doable, but as I wrote in an earlier blog post, the Python shell integration in other IDEs and text editors are much more convenient to work with since you don't have to manually load the python shell from another shell inside a terminal.

So I used some time today to look into if there is better integration with the Python Shell hidden somewhere in VSCode or the Python Extension. After a rather long looking around, I concluded that there isn't. There is, however, a slightly more convenient way to do this with the python interpreter in a terminal than first entering the shell and then importing. If you write python -i filename (with .py) when you are in the directory where the file is (or write the full path if you are not), you get the python shell with all the classes, functions and variables defined in the file imported. If you change the code, then you have to save and import again, either by leaving the shell and using python -i filename again or by staying in the shell and writing from x import y.

Why I replace Bash scripts with Elisp functions

Lately, I have spent some time replacing my Bash scripts with Emacs Lisp functions inside my Emacs configuration. I like programming and I haven't really gotten deeper into Elisp, so one reason was just to learn more Elisp and have some fun. Another reason is that replacing the Bash Shell scripts with Elisp functions removes the need to clone down an extra repository when I install a new system to get things up and running. It simplifies my installscripts a little.

Another advantage of having useful functionality inside my Emacs config is that whatever window manager or maybe even operating system I use, I can still use my functions from inside Emacs. Bash Shell scripts only run on GNU/Linux and POSIX Shell scripts only run on POSIX systems. But Emacs functions can be run inside Emacs on every platform it is available for without any external configuration. I might have to change my settings for wallpaper-command and wallpaper-command-args if I use another window manger, desktop environment or operating system, but most things will just work no matter where I am. Having the functionality in Emacs makes it easier if I ever were to change window manager from Sway as well.

The scripts I was able to replace with Emacs functions this weekend was my radio stream script, my two tv scripts for watching the latest news or satire broadcast from NRK, and my two wallpaper setting scripts, one that goes to the next file in a folder and sets it as the wallpaper so I can cycle through (and also around again when I get to the end) and another one that picks a random wallpaper from within the same folder. During the weekdays I was able to make a script to update my homepage and copy a youtube RSS feed link from a yewtu.be URL in primary selection. It was a lot of fun to dive into Elisp even if it took a lot of time since I was constantly searching for functions I could use for my purposes, both within Emacs and online.

I can still launch my scripts with keyboard shortcuts from my Sway config with emacsclient -e '(functionname)'. I start an Emacs server when I launch Sway, so I can always rely on having Emacs running. For the scripts that need user interaction in an Emacs frame, I can add -r to either reuse an open frame or make a new one.

How I generate my blog from Org files

I have used org-static-blog to generate HTML from org files for a while, but I have changed how I get those files onto my website. Org files are markup files used in Emacs Org Mode. The syntax is more regular than Markdown, there is only one standard unlike Markdown and the facilities in Org Mode to write these files make it a really great format to work with for any Emacs user.

In the past, I would manually delete all files except robots.txt, style.css and my media folder from the folder I exported to with org-static-blog. The reason is that org-static-blog only creates html files from org files where the html file does not already exist and then updates index.html, archive.html and rss.xml to reflect the changes. However, I sometimes edit older blog posts or my about page or change the header or footer which applies to all html pages, so I want to generate all the files every time and to achieve this, I delete all the html files before generating the new ones with the function org-static-blog-publish from my posts folder full of org files. I would then either use scp or FileZilla to upload those to my web server.

What I do now is use Codeberg Pages to serve my website instead. I have forwarded https://mostad.eu/ to https://einar.codeberg.page/ so visitors to mostad.eu get to the URL where html files in my Codeberg repo called pages are served by Codeberg instead. I have also made a shell script (that I will replace with an Elisp function in the future) that removes the previously generated html files, generates the html files with Emacs, and once closed, adds, commits and pushes the files to the repository Codeberg Pages hosts my website from. This way, I can get out a new blog post a lot faster than I would in the past and most of the process is automated.

Thonny, VSCode or Emacs for Python

I teach programming, and every year, students that already have some experience nag me about using VSCode as soon as we start writing code. According to the Stackoverflow Survey, around 75% of professional developers use VSCode, so being familiar with it may be useful for those of my students that are interested in becoming developers. (I also teach first year students that will go for media production on their second year and second year students that will get an apprenticeship within IT administration or spend their third year with general studies before higher education, so only a rather small percentage of my students will actually become developers.)

My plan this year is to introduce VSCode to my first year students when we start working with HTML and CSS in the spring since I find it a good tool for webdev (even though I personally use Emacs). For now, my first year students are working on Python. I don't think VSCode is a good tool for Python, especially not for learners. My second year students all use VSCode. We have worked with webdev in JavaScript, HTML, CSS, React and React Native which VSCode is rather good at thus far.

Instead of VSCode for the first year students, I have opted to use Thonny which includes great learner tools like a stepwise debugger that shows in detail how loops and recursion works (the one in VSCode isn't as detailed and as good for learners in my opinion), a variable table which shows which values are associated with variable names, a heap table which together with the debugger shows in even more detail how python actually evaluates expressions and stores them in memory associated with variable names etc, an LLM coding assistant to help the students when they are stuck if they don't want to ask me and the python shell with great integrations where the code in the code window is imported and run in the shell when the Run-command is executed and lots more. I have let the students use VSCode if they are already used to it (mainly because otherwise I would spend every lesson discussing tools instead of working with code), but whenever I make a task where the students are supposed to interact with the python shell, I get non-conforming half-answers back from the VSCode users since the python shell isn't as easily available with the Python extension in VSCode.

Even if you can get the python shell in VSCode with the Microsoft Python extension by writing python in the terminal on the bottom right, you don't get the integrations you get in Thonny which makes interacting with a function definition you have made to test out handing it different paramters more cumbersome. You can of course import your python file, but did you run the shell from where that file is stored? This lack of integration with the shell leads to print-debugging from the VSCode-users as well as complaints whenever there is a task involving the shell. Some students even say no professional developers ever use the python shell. If that is true, it might be because a majority of developers use an editor where the shell isn't very well integrated and therefore isn't as practical a tool as it is in other editors. Maybe those developers use that tool since it is good at other things they also work on, or maybe they haven't learned the usefulness of the shell since they have only used tools that obfuscate it? I don't know and I cannot claim to know since I haven't worked in the business myself, but it could be a chicken and egg-thing.

Personally, I find using a REPL extremely convenient. It is one of the pleasures of using an interpreted programming language. I got used to having one back in the late 80s when I taught myself HyperTalk with the HyperCard Help stack (in English which I barely knew at the time) and the HyperCard MessageBox (a REPL). When working with Python, I use the shell whenever I am uncertain of something, like if there is a method I can use for my purposes or if I am mixing up JavaScript and Python built-in functions etc. It is much faster than using an LLM for those kinds of questions and a lot lighter on energy and NPU/GPU resources. No need for an internet connection to use an off-machine LLM either and no spinning up of GPU fans for a local LLM.

I also use the python shell to try out if solutions I come up with will work before writing them into the code if in doubt. The great thing with a REPL is that you can work out solution from the ground up and get instant feedback if you do a mistake and when the code is ready, you can copy it into a function defintion or a method in a class definition in the code window. I also use the shell to interact with the code once written to check if functions or methods or classes work the way they are supposed to, especially if something seems wonky and I need to find out where I have made a mistake.

Python mode in Emacs gives me the same kind of great integrations with the shell as Thonny does, but within a more text- and keyboard-centric, programmable editor. Just like when using Thonny, there is never a need for print-debugging since I can interact with my code from the shell. I also get the same kind of language support I would have had in VSCode through an LSP server with eglot, company and eldoc (although I am not totally convinced I need it since I was just as efficient before I added that functionality). I first used Microsoft's pyright which is also used by the Python extension for VSCode, but I switched to the community-based python-lsp-server a while ago.

I tried showing my second year students Vim, NeoVim and Emacs the first year I taught development, but it was obvious the students didn't get why it is useful to spend time up front to learn tools that will make you more efficient in the long run. Text-centric CLI tools like Vim and NeoVim and even GUI Emacs seemed extremely foreign to people who grew up on iPads. They also seemed foreign to me that grew up on Macs in the 80s when I first encountered them, but I was convinced by reading up and watching online videos of the usefulness of learning these tools. It was probably also more natural for me since I was already deeply into GNU/Linux when I started looking into these great free software tools.

My students were motivated to learn coding, not text editors, so I realised it was better to try to harvest that motivation as much as possible instead of spending time on tools they didn't get why they needed. VSCode and Thonny are easier to start working with as they demand less learning up front. (Personally, I think there are advantages to the free software editors like being able to use the same editor in the tty for a config file, possibly also over ssh, as for coding, the faster text editing, the community based development model which secures the long time viability of these editors, the extensibility or in the case of Emacs, programmability of the editor makes it a more personalised and inspiring tool and no telemetry or enshittification, but the price is spending some time up front learning to use the tool.) Learning coding is hard enough and takes enough time to fill every class, so I would rather spend time on that than frustrating my students with something they don't yet get the benefit of and which doesn't tap into their motivation.

Those of my students who go on to become developers or admins will have to choose for themselves which editor(s) or IDE(s) to use. Having familiarity with a few editors like Thonny and VSCode is useful for getting to appreciate what different editors do well and knowing at least one of the often used tools of the trade. Being exposed to Emacs which I use for interactive presentations in class as well as my own coding (which I sometimes project on the screen to foster ego-less programming by showing my own mistakes (my main takeaway from "The psychology of computer programming") and show possible solutions as well as to practice the craft simply because I enjoy it) is nice for knowing that there are other alternatives, even though I no longer teach text editors except for the minimum necessary to use Thonny and VSCode. I don't want to push my own choices, which are not mainstream, upon my students, but trust them to make good choices for themselves based on the knowledge and experience they have gained at school, in their work placements and apprenticeships and in their future careers.

The ideal Micro Four Thirds lens setup

A few years ago, after buying my flat, I had very little money. I realised I could get some money in by selling off a few lenses. Since the lens I used the most was the 20 mm f/1.7 pancake, I sold off every other lens and got in enough money to get through the tight times. I had originally bought most of my lenses used, so I got back more or less what I invested in them in the first place.

The 20 mm served me well for the following two years as my only lens. The wide standard focal length is probably the most versatile focal length you can have if you only have one prime lens. In addition, the 20 mm pancake is small enough that my "large" Panasonic Lumix GX8 (which is still a lot thinner and lighter, but not smaller in width and height than any of the small full frame cameras) fits into jacket pockets which means I can bring a camera that is ergonomic enough to fit well in my hand and with good enough composition tools like the tilting EVF around as my daily carry camera. The f/1.7 aperture makes it a good lens for any lighting condition. The advantage of MFT when it comes to depth of field (since longer is almost always better) means that I can shoot at f/1.7 after sunset or indoors on low ISOs and still have the same depth of field as on a f/3.5 lens of an equivalent full frame focal length (40 mm). The disadvantage of more noise on higher ISOs on smaller sensors like APSC, MFT and 1 inch isn't a problem if you shoot fast enough lenses, but you get the advantage of the longer depth of field even in low light. The 20 mm has somewhat slow autofocus, so for video, I would use manual focus. I also experimented with manual focus for photography with it which also works well.

The 20 mm is in my opinion the most versatile and practical lens in the whole MFT system. I have used it for landscape, street, indoor events including video, close-up (with Ex.tele-conv, it becomes a 28 mm with a relatively larger reproduction ratio or you can crop when shooting RAW), environmental portraits, head shots and upper body portraits. I just wish it was weather sealed so I could confidently leave it on my camera during a blizzard. In other words, the 20 mm pancake will usually be the main lens in any lens set for me. Now that I have a bit more money again, I have felt that occasionally, it would be nice to have something wider or something longer. For a confirmation ceremony in a large hall, I bought the Sigma 60 f/2.8. I was very tempted by the Olympus 75 f/1.8, but it is a lot more expensive, larger and even though f/1.8 would be nice, f/2.8 is still fast enough to make decent images in low light. The Sigma is also small enough that I could keep it in my suit pocket when I used the 20 mm before and after the ceremony and easily switch over once inside. The 20 mm has taught me the value of small and light lenses.

I also missed the Lumix G 42.5 f/1.7 which is the best portrait and close up lens in the medium telephoto range unless you need one of the f/1.2 pro lenses. It also isn't larger than it needs to be like the otherwise great Sigma 56 f/1.4 which is an APSC lens and therefore larger than necessary for the focal length and aperture on MFT. The combination of built-in stabilisation, better sharpness and close focus abilities makes it a better choice than the Olympus 45 f/1.8 in my opinion. I have used it a lot for close-up in the past and also for the occasional portrait. I also missed having something wider occasionally, so when I saw a GM1 with a Lumix G 14 mm f/2.5 and a 12-32 for a decent price, that was a no brainer. I like the idea of the GM1 and my first MFT camera was the GM5, but both of those cameras are too unergonomic and fiddly in practical use for me. The lack of stabilisation is also a major drawback. The GX8 is so much more comfortable, and again, with the 20 mm or the 14 mm, it is small enough to fit in a jacket pocket which means the GM1's only advantage is lighter weight. I will sell the GM1 with its 12-32 and keep the 14 mm pancake.

I also bought the TTartisan 23 mm f/1.4 manual focus prime on a whim. My idea was that the slightly longer focal length would produce more winners for me since it would force me to think more about my composition. I owned the Panasonic Leica 25 f/1.4 in the past and even if it often felt too narrow, it also produced more winners than the zooms and primes I had owned before it. I actually came to it from the 20 mm pancake which at that time annoyed me because of it slightly slow auto-focus. This was also earlier in my photography journey. This time around, the 23 felt a bit restrictive coming from the 20 mm, but it did not actually help me produce anything I couldn't make with the 20. Even if it is rather small, it also surprised me by feeling heavy. Maybe the balance is towards the front of the lens or something, because on paper, it really isn't heavy at all. What the lens brings to the table is better manual focusing than the 20 mm, ideal for hyperfocal focusing for street or landscape. It is nice, but I don't really need it.

I still haven't written anything about the ideal setup. Up to this point, I did not really think in terms of a set of lenses, more in terms of what did I feel I wanted, needed or missed. I started thinking more about a versatile set for my uses at this point. There are many lenses I am curious about, but which focal lengths, apertures and features do I actually need? I am a hobby photographer that mainly shoot land/city/seascapes, (rural) street, travel and the occasional portrait. I live in southern Norway, close to the coast, which means wind, rain, snow, wave splashes, cold or a combination of these often occur. My GX8 camera is weather-sealed, but unfortunately, most of the small and light primes in the MFT system are not. On the other hand, most of the time, even in light rain or snow, being a bit careful and maybe keeping a hand on top of the lens is enough to keep the smaller 14 and 20 pancakes and the 42.5 safe. I have used these lenses a lot in all kinds of weather without any trouble, but I would feel more comfortable if they were weather-sealed.

When I started thinking more in terms of a set of lenses, I did a lot of thinking about what I actually need. I usually need a wide standard lens like the 20 mm. It is an ideal focal length as a walk-around lens. For travelling, maybe a medium wide angle like the Olympus or Youngnuo 17 would be better for large buildings and getting more context, but for most other things, a wide standard is better. I am not a fan of the exaggerated perspective a wider wide-angle lens produces unless it is used deliberately as an expressive means. I did use the Sigma 19 mm f/2.8 for a while as my walk-around lens some years ago and it was a very good lens, but I often felt that it exaggerated the perspective just a bit more than I like. That sensation disappeared when I went back to the 20 mm again. So even if the 20 mm can sometimes feel a bit narrow in very narrow streets when travelling, I think it is the main lens for me in any lens setup. When I could have only one lens, the 20 mm f/1.7 was that lens. Even when I can have more lenses, I keep the 20 on the camera and only occasionally use other lenses. It isn't perfect, but it is the best walk-around lens for me and after spending a lot of time with it, I know it well.

Occasionally, I want to exaggerate perspective or I am in a very tight place like an alley or in a small room where the 20 mm is just too tight. Then something wider would be useful. I already own the 14 mm f/2.5 which is a good lens. Robin Wong complained about auto-focus speed, but maybe that was a problem with the mark I on Olympus cameras. I have owned both the mark I and the mark II and I have never experienced slow autofocus with the GX8 (unlike the 20 mm pancake which is more like a full frame DSLR lens than a fast MFT lens in auto focus speed). It is also small and light which means it fits well into any lens set. It is sharp enough and it is faster than most zooms although the 15 f/1.7 is even faster and maybe with a bit nicer rendering, but that lens is also larger, heavier and more expensive. The 14 is much better than its reputation and extremely practical since it is the smallest and lightest autofocusing lens in the MFT system. (It can also become an 11 mm with the wide angle conversion lens and there is also a close-up attachment for it that can make it better at close focusing (which it already is quite good at). For my purposes, I think buying those are not really worth it since I seldom need anything wider than 14 and I have other lenses for close-up.)

For landscapes, the occasional animal, bird photo or portrait I sometimes need a longer lens. The 20 is good for portraits, but for closer head shots or upper body shots, you get a bit too close to the subject which makes the proportions of the face seem strange. I usually shoot environmental portraits which the 20 mm is good at, so for me, a longer lens is actually less about portraits and more about landscapes, birds or animals. I don't shoot any sport, but when Tour of Norway cycled by a few years ago, I made an attempt with the Sigma 56 f/1.4 that I owned at the time and got some decent shots. I don't usually shoot events either, but occasionally, I am at an outdoor concert or the Norwegian National Day celebrations or a confirmation or wedding and it is nice to have a lens that could work in such a situation.

For landscapes, weather is a factor. Ideally, I would have a lens I could use during a blizzard in -20 Celsius by the coast with a lot of humidity. Even though I own the 42.5 f/1.7, I don't use it that much because it feels a bit on the short side for telephoto landscapes, animals at a distance and events and I seldom shoot portraits that aren't environmental. The Sigma 60 f/2.8 is more ideal for those scenarios, except that it isn't weather sealed. I don't often shoot in low light at events or outdoors for landscapes. When I bought the Sigma 60, I also thought about the 12-60 f/2.8-4, but felt that f/4 was a bit too slow for the event I bought the Sigma for. The Olympus 75 has a better focal length and faster aperture than the other alternatives and back when I owned the Sigma 56, I sometimes used it for landscapes. I don't shoot birds or animals often enough that I need a dedicated telephoto zoom like the 35-100 f/2.8 or the Olympus 40 - 150 f/2.8. These lenses feel too large and expensive for something I only occasionally do and 60 is long enough for my needs.

I am still not 100% certain about the telephoto side, but I did buy the 12-60 f/2.8-4 since it is a useful occasional telephoto, superish zoom ans bad weather lens. Since it covers the whole focal range I need, I can confidently go out in bad weather during winter with it on my camera. I can also use it as the second lens together with the 20 mm when travelling. Especially when travelling with other people and not knowing what to expect, a superish zoom can be useful. The 12-60 is super enough to cover all my needs with enough speed, but not so super that it looses its optical excellence or aperture speed like the 14-140 f/3.5-5.6. Maybe I will invest in the Olympus 75 f/1.8 if I find myself shooting a lot of low light events or landscapes, but as an occasional telephoto, the 12-60 at f/4 on the long end is good enough. It is larger and heavier which is the disadvantage of a zoom over primes and it is slower, but I can use it during winter or bad weather without worrying and it has a versatile zoom range. An advantage of the 12-60 is that it focuses closely and even though the spec sheet says 0.3 x magnification and the 42.5 f/1.7 spec sheet says 0.4 x, in reality, I get more magnification with the 12-60. Maybe 0.3x is at the wide end and they forgot to write the magnification at the long end?

My ideals are to have as few lenses as possible and as small and light as possible, but at the same time have all the lenses I need. I will sell the TTartisans 23 mm even if it is a good lens since I already have the 20 mm. I will also sell the 60 f/2.8 since I seldom shoot indoor events which is the main advantage of this f/2.8 over the 12-60 f/2.8 - 4. I am more hesitant to sell the 42.5 f/1.7 since it makes an excellent three prime set with the 14 and 20 pancakes even though I do not actually use it very much. The low light capabilities of f/1.7 can be useful when the 12-60 f/2.8-4 is too slow and weather sealing isn't needed. If I continue to not use it much over time, it will go, but for now, I hold onto it as a fourth lens.

I have been thinking about and trying out a lot of different MFT lenses over the years. In the past I was more concerned with getting the very best lenses, but over time, I have come to appreciate the value of compromising on some aspects, like auto-focus speed with the 20 mm or aperture size on the long side of the 12-60 or slightly on the 14 to gain practical advantages like small size and light weight, weather sealing or a practical zoom range. A camera and lens combination that you can keep in a jacket pocket like the GX8 + 20 mm pancake is more valuable than something like the GX8 + the OM System 20 mm f/1.4 which technically is a better lens and even brings weather sealing to the table, but is too large and heavy to be kept on the camera in a jacket pocket. On the days where weather sealing matters, I can bring the camera in a small camera bag with the 12-60 mounted so I don't have to mount it in bad weather, or I can carry the camera in my hand with a wrist wrap with the 12-60 on from the moment I leave home or wherever I stay.

Another advantage of having few, small and light lenses are that there is space in my small camera bag insert for my charger, extra batteries, ND filter, mini-tripod etc. as well as the lenses. When I travel, I can travel with any shoulder bag or backpack and use the insert from my camera bag to keep my whole camera system. Or I can keep the camera with the 20 mm in my jacket pocket ready for action and have the rest of the equipment in the camera bag insert in a suitcase.