Podcast appearances and mentions of Mark Shannon

Topics covered in this episode: * The Python Language Summit 2025* Fixing Python Properties * complexipy* * juvio* Extras Joke Watch on YouTube About the show Sponsored by Posit: pythonbytes.fm/connect Connect with the hosts Michael: @mkennedy@fosstodon.org / @mkennedy.codes (bsky) Brian: @brianokken@fosstodon.org / @brianokken.bsky.social Show: @pythonbytes@fosstodon.org / @pythonbytes.fm (bsky) Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Monday at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Michael #1: The Python Language Summit 2025 Write up by Seth Michael Larson How can we make breaking changes less painful?: talk by Itamar Oren An Uncontentious Talk about Contention: talk by Mark Shannon State of Free-Threaded Python: talk by Matt Page Fearless Concurrency: talk by Matthew Parkinson, Tobias Wrigstad, and Fridtjof Stoldt Challenges of the Steering Council: talk by Eric Snow Updates from the Python Docs Editorial Board: talk by Mariatta PEP 772 - Packaging Governance Process: talk by Barry Warsaw and Pradyun Gedam Python on Mobile - Next Steps: talk by Russell Keith-Magee What do Python core developers want from Rust?: talk by David Hewitt Upstreaming the Pyodide JS FFI: talk by Hood Chatham Lightning Talks: talks by Martin DeMello, Mark Shannon, Noah Kim, Gregory Smith, Guido van Rossum, Pablo Galindo Salgado, and Lysandros Nikolaou Brian #2: Fixing Python Properties Will McGugan “Python properties work well with type checkers such Mypy and friends. … The type of your property is taken from the getter only. Even if your setter accepts different types, the type checker will complain on assignment.” Will describes a way to get around this and make type checkers happy. He replaces @property with a descriptor. It's a cool technique. I also like the way Will is allowing different ways to use a property such that it's more convenient for the user. This is a cool deverloper usability trick. Brian #3: complexipy Calculates the cognitive complexity of Python files, written in Rust. Based on the cognitive complexity measurement described in a white paper by Sonar Cognitive complexity builds on the idea of cyclomatic complexity. Cyclomatic complexity was intended to measure the “testability and maintainability” of the control flow of a module. Sonar argues that it's fine for testability, but doesn't do well with measuring the “maintainability” part. So they came up with a new measure. Cognitive complexity is intended to reflects the relative difficulty of understanding, and therefore of maintaining methods, classes, and applications. complexipy essentially does that, but also has a really nice color output. Note: at the very least, you should be using “cyclomatic complexity” try with ruff check --select C901 But also try complexipy. Great for understanding which functions might be ripe for refactoring, adding more documentation, surrounding with more tests, etc. Michael #4: juvio uv kernel for Jupyter ⚙️ Automatic Environment Setup: When the notebook is opened, Juvio installs the dependencies automatically in an ephemeral virtual environment (using uv), ensuring that the notebook runs with the correct versions of the packages and Python

In this asynchronous episode we're interviewing a fellow core developer Yury Selivanov to talk about asyncio's past and future, composable design, immutability, and databases you'd actually like using. We also broke the 2-hour episode barrier!## Timestamps(00:00:00) INTRO(00:01:33) PART 1: INTERVIEW(00:02:27) What drives you?(00:04:47) How do you choose what to work on?(00:08:10) Hyperfocus(00:09:28) Things from Rust that Python could use(00:14:50) Nothing is sacred when you depend on glibc(00:18:47) TypeScript typing is god-tier(00:22:04) Adding async and await to Python(00:34:11) Adding new keywords to the language(00:41:17) Jumping into a new codebase(00:49:22) Any design regrets?(00:58:46) Contextvars(01:10:40) Is the frozenmap PEP happening?(01:19:21) uvloop(01:23:25) What makes Gel lovable?(01:39:57) PART 2: PR OF THE WEEK(01:47:08) Saturday talks at PyCon should be fun(01:50:35) PART 3: WHAT'S GOING ON IN CPYTHON(01:50:47) Ken Jin's tail-call interpreter(01:55:05) Barney Gale's glob.glob() optimization(01:55:43) Brandt's boolean guards to narrow types to values in the JIT(01:56:33) Mark Shannon's stack limits implemented with addresses, not counters(01:58:34) Brandt's removal of _DYNAMIC_EXIT(01:58:53) Mark Shannon's async for branches instrumented(01:59:36) Free-threading changes(01:59:58) Sam Gross' regression tests can now run in --parallel-threads(02:00:34) Tomasz Pytel's thread safety crusade(02:01:01) Xuanteng Huang's __annotations__ race fix(02:01:11) Kumar's per-thread linked lists for tasks(02:02:54) Serhiy's crashes related to PySys_GetObject() fixed(02:03:22) Sam's usage of stack pointers in thread stack traversal(02:03:38) Dino Viehland's lock avoidance during object cleanup(02:04:23) OUTRO

Over 40 core developers spent a week in Bellevue WA putting finishing touches on Python 3.13, planning, prototyping, and implementing features for Python 3.14. We talked to half of them. We laughed, we cried. We were happy watching graphs go up, and sad watching them go down. It was intense. There was even cake, no joke!## Timestamps(00:00:00) INTRO(00:02:05) PART 1: THE CAKE IS NOT A LIE(00:04:09) Interview with sprint organizer Itamar Oren(00:07:48) Surprise waffle machine(00:08:36) PART 2: DEVELOPERS IN THEIR OWN WORDS(00:08:47) Brandt Bucher(00:10:49) Tian Gao(00:12:31) Hugo van Kemenade(00:16:35) Thomas Wow-ters(00:24:08) Yury Selivanov(00:29:33) Mark Shannon(00:30:56) Raymond Hettinger(00:32:06) Russell Keith-Magee(00:33:18) Mariatta(00:41:41) Larry Hastings(00:46:07) Barry Warsaw(00:53:10) Jelle Zijlstra(00:56:20) Alex Waygood(00:57:39) Gregory P. Smith(01:04:08) Petr Viktorin(01:04:49) Emily Morehouse-Valcarcel(01:08:27) Interlude: Łukasz was right for once(01:09:28) Lysandros Nikolaou(01:17:38) Dino Viehland(01:23:22) Carl Meyer(01:24:29) Eric Smith(01:32:00) Eric Snow(01:41:46) Janitor 1(01:50:01) Janitor 2(01:53:03) OUTRO

We speak to the Dublin Restaurant owner who is being forced to return his outdoor seating space to the local council Speaking to Pat this morning was Mark Shannon of Bistro One.

In this season finale, we're checking the pulse on all things programmatic. Matt Evered chats with experts from StackAdapt, Mark Shannon and Brandon Langevin about the latest digital advertising trends, and explores emerging channels in the programmatic space.©StackAdapt Inc.2023

Watch on YouTube About the show Sponsored by Microsoft for Startups Founders Hub. Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show announcements: @pythonbytes@fosstodon.org Hi folks. For our final episode of 2022 here on Python Bytes, we're crossing the streams with my other show, Talk Python To Me. I present to you one of the more important episodes of the year, the release of Python 3.11 with it's new features and 40% performance improvements. Thank you for listening to Python Bytes in 2022, have a great holiday break, and Brian and I will see you next week. Python 3.11 is here! Keeping with the annual release cycle, the Python core devs have released the latest version of Python. And this one is a big one. It has more friendly error messages and is massively faster than 3.10 (between 10 to 60% faster) which is a big deal for a year over year release of a 30 year old platform. On this episode, we have Irit Katriel, Pablo Galindo Salgado, Mark Shannon, and Brandt Bucher all of whom participated in releasing Python this week on the show to tell us about that process and some of the highlight features. Guests Irit Katriel @iritkatriel Mark Shannon linkedin.com Pablo Galindo Salgado @pyblogsal Brandt Bucher github.com Resources from the show Michael's Python 3.11 Course talkpython.fm/py311 Python 3.11.0 is now available blog.python.org PEP 101 - Releasing Python peps.python.org PEP 678 – Enriching Exceptions with Notes peps.python.org PEP 654 – Exception Groups and except* peps.python.org PEP 657 – Include Fine Grained Error Locations in Tracebacks peps.python.org Python Buildbot python.org Making Python Faster Talk Python Episode talkpython.fm Specializing, Adaptive Interpreter on Talk Python talkpython.fm Specialist Visualizer github.com "Zero cost" exception handling github.com Pyodide pyodide.org pyscript pyscript.net

Python 3.11 is here! Keeping with the annual release cycle, the Python core devs have released the latest version of Python. And this one is a big one. It has more friendly error messages and is massively faster than 3.10 (between 10 to 60% faster) which is a big deal for a year over year release of a 30 year old platform. On this episode, we have Irit Katriel, Pablo Galindo Salgado, Mark Shannon, and Brandt Bucher all of whom participated in releasing Python this week on the show to tell us about that process and some of the highlight features. Links from the show Guests Irit Katriel: @iritkatriel Mark Shannon: linkedin.com Pablo Galindo Salgado: @pyblogsal Brandt Bucher: github.com Python 3.11.0 is now available: blog.python.org PEP 101 - Releasing Python: peps.python.org PEP 678 – Enriching Exceptions with Notes: peps.python.org PEP 654 – Exception Groups and except*: peps.python.org PEP 657 – Include Fine Grained Error Locations in Tracebacks: peps.python.org Python Buildbot: python.org Making Python Faster Talk Python Episode: talkpython.fm Specializing, Adaptive Interpreter on Talk Python: talkpython.fm Specialist Visualizer: github.com "Zero cost" exception handling: github.com Pyodide: pyodide.org pyscript: pyscript.net Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Twitter: @talkpython Follow Michael on Twitter: @mkennedy Sponsors Sentry Error Monitoring, Code TALKPYTHON Command Line Heroes AssemblyAI Talk Python Training

In this bonus episode of How Agencies Thrive, Matt Evered, Education and Development Manager at StackAdapt leads a discussion about marketing data with Alex Billington from Funnel and Mark Shannon from StackAdapt.

Today is the last of our series of North Boros churches.  We talk with Chris Skerlong of Community Presbyterian .church of Ben Avon and Mark Shannon of Emsworth UP Church about their congregations throughout the ages.  

Watch the live stream: Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training Test & Code Podcast Patreon Supporters Brian #1:distinctipy “distinctipy is a lightweight python package providing functions to generate colours that are visually distinct from one another.” Small, focused tool, but really cool. Say you need to plot a dynamic number of lines. Why not let distinctipy pick colors for you that will be distinct? Also can display the color swatches. Some example palettes here: https://github.com/alan-turing-institute/distinctipy/tree/main/examples from distinctipy import distinctipy # number of colours to generate N = 36 # generate N visually distinct colours colors = distinctipy.get_colors(N) # display the colours distinctipy.color_swatch(colors) Michael #2: Soda SQL Soda SQL is a free, open-source command-line tool. It utilizes user-defined input to prepare SQL queries that run tests on dataset in a data source to find invalid, missing, or unexpected data. Looks good for data pipelines and other CI/CD work! Daniel #3: Python in Nature There's a review article from Sept 2020 on array programming with NumPy in the research journal Nature. For reference, in grad school we had a fancy paper on quantum entanglement that got rejected from Nature Communications, a sub-journal to Nature. Nature is hard to get into. List of authors includes Travis Oliphant who started NumPy. Covers NumPy as the foundation, building up to specialized libraries like QuTiP for quantum computing. If you search “Python” on their site, many papers come up. Interesting to see their take on publishing software work. Brian #4: Supercharging GitHub Actions with Job Summaries From a tweet by Simon Willison and an article: GH Actions job summaries Also, Ned Batchelder is using it for Coverage reports “You can now output and group custom Markdown content on the Actions run summary page.” “Custom Markdown content can be used for a variety of creative purposes, such as: Aggregating and displaying test results Generating reports Custom output independent of logs” Coverage.py example: - name: "Create summary" run: | echo '### Total coverage: ${{ env.total }}%' >> $GITHUB_STEP_SUMMARY echo '[${{ env.url }}](${{ env.url }})' >> $GITHUB_STEP_SUMMARY Michael #5:Language Summit is write up out via Itamar, by Alex Waygood Python without the GIL: A talk by Sam Gross Reaching a per-interpreter GIL: A talk by Eric Snow The "Faster CPython" project: 3.12 and beyond: A talk by Mark Shannon WebAssembly: Python in the browser and beyond: A talk by Christian Heimes F-strings in the grammar: A talk by Pablo Galindo Salgado Cinder Async Optimisations: A talk by Itamar Ostricher The issue and PR backlog: A talk by Irit Katriel The path forward for immortal objects: A talk by Eddie Elizondo and Eric Snow Lightning talks, featuring short presentations by Carl Meyer, Thomas Wouters, Kevin Modzelewski, Samuel Colvin and Larry Hastings Daniel #6:AllSpice is Git for EEs Software engineers have Git/SVN/Mercurial/etc None of the other engineering disciplines (mechanical, electrical, optical, etc), have it nearly as good. Altium has their Vault and “365,” but there's nothing with a Git-like UX. Supports version history, diffs, all the things you expect. Even self-hosting and a Gov Cloud version. “Bring your workflow to the 21st century, finally.” Extras Brian: Will McGugan talks about Rich, Textual, and Textualize on Test & Code 188 Also 3 other episodes since last week. (I have a backlog I'm working through.) Michael: Power On-Xbox Documentary | Full Movie The 4 Reasons To Branch with Git - Illustrated Examples with Python A Python spotting - via Jason Pecor 2022 StackOverflow Developer Survey is live, via Brian TextSniper macOS App PandasTutor on webassembly Daniel: I know Adafruit's a household name, shout-out to Sparkfun, Seeed Studio, OpenMV, and other companies in the field. Joke: A little awkward

Mark Shannon Discusses the Recent Growth and Outlook for the U.S. Tile Market by Floor Focus Magazine

There has a been a bunch of renewed interested in making Python faster. While for some of us, Python is already plenty fast. For others, such as those in data science, scientific computing, and even the large tech companies, making Python even a little faster would be a big deal. This episode is the first of several that dive into some of the active efforts to increase the speed of Python while maintaining compatibility with existing code and packages. Who better to help kick this off than Guido van Rossum and Mark Shannon? They both join us to share their project to make Python faster. I'm sure you'll love hearing what they are up to. Links from the show Guido van Rossum: @gvanrossum Mark Shannon: linkedin.com Faster Python Plan: github.com/faster-cpython The “Shannon Plan”: github.com/markshannon Sam Gross's nogil work: docs.google.com Watch this episode on YouTube: youtube.com ---------- Stay in touch with us ---------- Subscribe on YouTube (for live streams): youtube.com Follow Talk Python on Twitter: @talkpython Follow Michael on Twitter: @mkennedy Sponsors Shortcut Linode AssemblyAI Talk Python Training

Ken talks with Mark Shannon, Talent Acquisition Director, UPS  See omnystudio.com/listener for privacy information.

Guido van Rossum is the creator of the Python programming language and a Distinguished Engineer at Microsoft. Apple Podcasts | Spotify | Google PodcastsWe discuss Guido’s new work on making CPython faster (PEP 659), Tiers of Python Interpreter Execution, and high impact, low hanging fruit performance improvements.Highlights(an edited summary)[00:21] What got you interested in working on Python performance?Guido: In some sense, it was probably a topic that was fairly comfortable to me because it means working with a core of Python, where I still feel I know my way around. When I started at Microsoft, I briefly looked at Azure but realized I never enjoyed that kind of work at Google or Dropbox. Then I looked at Machine Learning, but it would take a lot of time to do something interested with the non-Python, and even Python-related bits.[02:31] What was different about the set of Mark Shannon’s ideas on Python performance that convinced you to go after them?Guido: I liked how he was thinking about the problem. Most of the other approaches around Python performance like PyPy and Cinder are not suitable for all use cases since they aren’t backward compatible with extension modules. Mark has the perspective and experience of a CPython developer, as well as a viable approach that would maintain backward compatibility, which is the hardest problem to solve. The Python Bytecode interpreter is modified often across minor releases (for eg: 3.8 → 3.9) for various reasons like new opcodes, so modifying that is a relatively safe approach. Utsav: [09:45] Could you walk us through the idea of the tiers of execution of the Python Interpreter?Guido: When you execute a program, you don't know if it's going to crash after running a fraction of a millisecond, or whether it's going to be a three-week-long computation. Because it could be the same code, just in the first case, it has a bug. And so, if it takes three weeks to run the program, maybe it would make sense to spend half an hour ahead of time optimizing all the code that's going to be run. But obviously, especially in dynamic languages like Python, where we do as much as we can without asking the user to tell us exactly how they need it done, you just want to start executing code as quickly as you can. So that if it's a small script, or a large program that happens to fail early, or just exits early for a good reason, you don't spend any time being distracted by optimizing all that code.So, what we try to do there is keep the bytecode compiler simple so that we get to execute the beginning of the code as soon as possible. If we see that certain functions are being executed many times over, then we call that a hot function, and some definition of “hot”. For some purposes, maybe it's a hot function if it gets called more than once, or more than twice, or more than 10 times. For other purposes, you want to be more conservative, and you can say, “Well, it's only hot if it's been called 1000 times.”The specializing adaptive compiler (PEP 659) then tries to replace certain bytecodes with bytecodes that are faster, but only work if the types of the arguments are specific types. A simple hypothetical example is the plus operator in Python. It can add lots of things like integers, strings, lists, or even tuples. On the other hand, you can't add an integer to a string. So, the optimization step - often called quickening, but usually in our context, we call it specializing - is to have a separate “binary add” integer bytecode, a second-tier bytecode hidden from the user. This opcode assumes that both of its arguments are actual Python integer objects, reaches directly into those objects to find the values, adds those values together in machine registers, and pushes the result back on the stack. The binary adds integer operation still has to make a type check on the arguments. So, it's not completely free but a type check can be implemented much faster than a sort of completely generic object-oriented dispatch, like what normally happens for most generic add operations. Finally, it's always possible that a function is called millions of times with integer arguments, and then suddenly a piece of data calls it with a floating-point argument, or something worse. At that point, the interpreter will simply execute the original bytecode. That's an important part so that you still have the full Python semantics.Utsav [18:20] Generally you hear of these techniques in the context of JIT, a Just-In-Time compiler, but that’s not being implemented right now.Just-In-Time compilation has a whole bunch of emotional baggage with it at this point that we're trying to avoid. In our case, it’s unclear what and when we’re exactly compiling. At some point ahead of program execution, we compile your source code into bytecode. Then we translate the bytecode into specialized bytecode. I mean, everything happens at some point during runtime, so which part would you call Just-In-Time? Also, it’s often assumed that Just-In-Time compilation automatically makes all your code better. Unfortunately, you often can't actually predict what the performance of your code is going to be. And we have enough of that with modern CPUs and their fantastic branch prediction. For example, we write code in a way that we think will clearly reduce the number of memory accesses. When we benchmark it, we find that it runs just as fast as the old unoptimized code because the CPU figured out access patterns without any of our help. I wish I knew what went on in modern CPUs when it comes to branch prediction and inline caching because that is absolute magic. Full TranscriptUtsav: [00:14] Thank you, Guido, for joining me on another episode of the Software at Scale podcast. It's great to have you here. Guido: [00:20] Great to be here on the show. Utsav: [00:21] Yeah. And it's just fun to talk to you again. So, the last time we spoke was at Dropbox many, many years ago. And you got retired, and then you decided that you wanted to do something new. And you work on performance now at Microsoft, and that's amazing. So, to start off with, I just want to ask you, you could pick any project that you wanted to, based on some slides that I've seen. So, what got you interested in working on Python performance?Guido: [00:47] In some sense, it was probably a topic that was fairly comfortable to me because it means working with a core of Python, where I still feel I know my way around. Some other things I considered briefly in my first month at Microsoft, I looked into, “Well, what can I do with Azure?”, and I almost immediately remembered that I was not cut out to be a cloud engineer. That was never the fun part of my job at Dropbox. It wasn't the fun part of my job before that at Google either. And it wouldn't be any fun to do that at Microsoft. So, I gave up on that quickly. I looked in machine learning, which I knew absolutely nothing about when I joined Microsoft. I still know nothing, but I've at least sat through a brief course and talked to a bunch of people who know a lot about it. And my conclusion was actually that it's a huge field. It is mostly mathematics and statistics and there is very little Python content in the field. And it would take me years to do anything interesting with the non-Python part and probably even with the Python part, given that people just write very simple functions and classes, at best in their machine learning code. But at least I know a bit more about the terminology that people use. And when people say kernel, I now know what they mean. Or at least I'm not confused anymore as I was before.Utsav: [02:31] That makes sense. And that is very similar to my experience with machine learning. Okay, so then you decided that you want to work on Python performance, right? And then you are probably familiar with Mark Shannon's ideas?Guido: [02:43] Very much so. Yeah.Utsav: [02:44] Yeah. So, was there anything different about the set of ideas that you decided that this makes sense and I should work on a project to implement these ideas?Guido: [02:55] Mark Shannon's ideas are not unique, perhaps, but I know he's been working on for a long time. I remember many years ago, I went to one of the earlier Python UK conferences, where he gave a talk about his PhD work, which was also about making Python faster. And over the years, he's never stopped thinking about it. And he sort of has a holistic attitude about it. Obviously, the results remain to be seen, but I liked what he was saying about how he was thinking about it. And if you take PyPy, it has always sounded like PyPy is sort of a magical solution that only a few people in the world understand how it works. And those people built that and then decided to do other things. And then they left it to a team of engineers to solve the real problems with PyPy, which are all in the realm of compatibility with extension modules. And they never really solved that. [04:09] So you may remember that there was some usage of PyPy at Dropbox because there was one tiny process where someone had discovered that PyPy was actually so much faster that it was worth it. But it had to run in its own little process and there was no maintenance. And it was a pain, of course, to make sure that there was a version of PyPy available on every machine. Because for the main Dropbox application, we could never switch to PyPy because that depended on 100 different extension modules. And just testing all that code would take forever. [04:49] I think since we're talking about Dropbox, Pyston was also an interesting example. They've come back actually; you've probably heard that. The Pyston people were much more pragmatic, and they've learned from PyPy’s failures. [05:04] But they have always taken this attitude of, again, “we're going to start with CPython,” which is good because that way they are sort of guaranteed compatibility with extension modules. But still, they make these huge sets of changes, at least Pyston one, and they had to roll back a whole bunch of things because, again, of compatibility issues, where I think one of the things, they had a bunch of very interesting improvements to the garbage collection. I think they got rid of the reference counting, though. And because of that, the behavior of many real-world Python programs was completely changed. [05:53] So why do I think that Mark's work will be different or Mark's ideas? Well, for one, because Mark has been in Python core developer for a long time. And so, he knows what we're up against. He knows how careful we have with backwards compatibility. And he knows that we cannot just say get rid of reference counting or change the object layout. Like there was a project that was recently released by Facebook basically, was born dead, or at least it was revealed to the world in its dead form, CI Python (Cinder), which was a significantly faster Python implementation, but using sort of many of the optimizations came from changes in object layout that just aren't compatible with extension modules. And Mark has sort of carved out these ideas that work on the bytecode interpreter itself. [06:58] Now, the bytecode is something where we know that it's not going to sort of affect third-party extension modules too much if we change it, because the bytecode changes in every Python release. And internals of the interpreter of the bytecode interpreter, change in every Python release. And yes, we still run into the occasional issue. Every release, there is some esoteric hack that someone is using that breaks. And they file an issue in the bug tracker because they don't want to research or they haven't yet researched what exactly is the root cause of the problem, because all they know is their users say, “My program worked in Python 3.7, and it broke in Python 3.8. So clearly, Python 3.8 broke something.” And since it only breaks when we're using Library X, it must be maybe Library X's fault. But Library X, the maintainers don't know exactly what's going on because the user just says it doesn't work or give them a thousand-line traceback. And they bounce it back to core Python, and they say, “Python 3.8 broke our library for all our users, or 10% of our users,” or whatever. [08:16] And it takes a long time to find out, “Oh, yeah, they're just poking inside one of the standard objects, using maybe information they gleaned from internal headers, or they're calling a C API that starts with an underscore.” And you're not supposed to do that. Well, you can do that but then you pay the price, which is you have to fix your code at every next Python release. And in between, sort of for bug fix releases like if you go from 3.8.0 to 3.8.1, all the way up to 3.8.9, we guarantee a lot more - the bytecodes stay stable. But 3.9 may break all your hacks and it changes the bytecode. One thing we did I think in 3.10, was all the jumps in the bytecode are now counted in instructions rather than bytes, and instructions are two bytes. Otherwise, the instruction format is the same, but all the jumps jump a different distance if you don't update your bytecode. And of course, the Python bytecode compiler knows about this. But people who generate their own bytecode as a sort of the ultimate Python hack would suffer.Utsav: [09:30] So the biggest challenge by far is backwards compatibility.Guido: [09:34] It always is. Yeah, everybody wants their Python to be faster until they find out that making it faster also breaks some corner case in their code.Utsav: [09:45] So maybe you can walk us through the idea of the tiers of execution or tiers of the Python interpreter that have been described in some of those slides.Guido: [09:54] Yeah, so that is a fairly arbitrary set of goals that you can use for most interpreted languages. Guido: [10:02] And it's actually a useful way to think about it. And it's something that we sort of plan to implement, it's not that there are actually currently tiers like that. At best, we have two tiers, and they don't map perfectly to what you saw in that document. But the basic idea is-- I think this also is implemented in .NET Core. But again, I don't know if it's sort of something documented, or if it's just this is how their optimizer works. So, when you just start executing a program, you don't know if it's going to crash after running a fraction of a millisecond, or whether it's going to be a three-week-long computation. Because it could be the same code, just in the first case, it has a bug. And so, if it takes three weeks to run the program, maybe it would make sense to spend half an hour ahead of time optimizing all the code that's going to be run. But obviously, especially in dynamic language, and something like Python, where we do as much as we can without asking the user to tell us exactly how they need it done, you just want to start executing the code as quickly as you can. So that if it's a small script, or a large program that happens to fail early, or just exits early for a good reason, you don't spend any time being distracted by optimizing all that code. [11:38] And so if this was a statically compiled language, the user would have to specify that basically, when they run the compiler, they say, “Well, run a sort of optimize for speed or optimize for time, or O2, O3 or maybe optimized for debugging O0.” In Python, we try not to bother the user with those decisions. So, you have to generate bytecode before you can execute even the first line of code. So, what we try to do there is keep the bytecode compiler simple, keep the bytecode interpreter simple, so that we get to execute the beginning of the code as soon as possible. If we see that certain functions are being executed many times over, then we call that a hot function, and you can sort of define what's hot. For some purposes, maybe it's a hot function if it gets called more than once, or more than twice, or more than 10 times. For other purposes, you want to be more conservative, and you can say, “Well, it's only hot if it's been called 1000 times.” [12:48] But anyway, for a hot function, you want to do more work. And so, the specializing adaptive compiler, at that point, tries to replace certain bytecodes with bytecodes that are faster, but that work only if the types of the arguments are specific types. A simple example but pretty hypothetical is the plus operator in Python at least, can add lots of things. It can add integers, it can add floats, it can add strings, it can list or tuples. On the other hand, you can't add an integer to a string, for example. So, what we do there, the optimization step - and it's also called quickening, but usually in our context, we call it specializing - is we have a separate binary add integer bytecode. And it's sort of a second-tier bytecode that is hidden from the user. If the user asked for the disassembly of their function, they will never see binary add integer, they will also always see just binary add. But what the interpreter sees once the function has been quickened, the interpreter may see binary add integers. And the binary add integer just assumes that both of its arguments, that's both the numbers on the stack, are actual Python integer objects. It just reaches directly into those objects to find the values, adds those values together in machine registers, and push the result back on the stack. [14:35] Now, there are all sorts of things that make that difficult to do. For example, if the value doesn't fit in a register for the result, or either of the input values, or maybe even though you expected it was going to be adding two integers, this particular time it's going to add to an integer and a floating-point or maybe even two strings. [15:00] So the first stage of specialization is actually… I'm blanking out on the term, but there is an intermediate step where we record the types of arguments. And during that intermediate step, the bytecode actually executes slightly slower than the default bytecode. But that only happens for a few executions of a function because then it knows this place is always called with integers on the stack, this place is always called with strings on the stack, and maybe this place, we still don't know or it's a mixed bag. And so then, the one where every time it was called during this recording phase, it was two integers, we replace it with that binary add integer operation. The binary adds integer operation, then, before it reaches into the object, still has to make a type check on the arguments. So, it's not completely free but a type check can be implemented much faster than a sort of completely generic object-oriented dispatch, like what normally happens for the most generic binary add operations. [16:14] So once we've recorded the types, we specialize it based on the types, and the interpreter then puts in guards. So, the interpreter code for the specialized instruction has guards that check whether all the conditions that will make the specialized instruction work, are actually met. If one of the conditions is not met, it's not going to fail, it's just going to execute the original bytecode. So, it's going to fall back to the slow path rather than failing. That's an important part so that you still have the full Python semantics. And it's always possible that a function is called hundreds or millions of times with integer arguments, and then suddenly a piece of data calls it with a floating-point argument, or something worse. And the semantics still say, “Well, then it has to do with the floating-point way.Utsav: [17:12] It has to deoptimize, in a sense.Guido: [17:14] Yeah. And there are various counters in all the mechanisms where, if you encounter something that fails the guard once, that doesn't deoptimize the whole instruction. But if you sort of keep encountering mismatches of the guards, then eventually, the specialized instruction is just deoptimized and we go back to, “Oh, yeah, we'll just do it the slow way because the slow way is apparently the fastest, we can do.” Utsav: [17:45] It's kind of like branch prediction.Guido: [17:47] I wish I knew what went on in modern CPUs when it comes to branch prediction and inline caching because that is absolute magic. And it's actually one of the things we're up against with this project, because we write code in a way that we think will clearly reduce the number of memory accesses, for example. And when we benchmark it, we find that it runs just as fast as the old unoptimized code because the CPU figured it out without any of our help. Utsav: [18:20] Yeah. I mean, these techniques, generally you hear them in a context of JIT, a Just-In-Time compiler, but y’all are not implementing that right now.Guido: [18:30] JIT is like, yeah, in our case, it would be a misnomer. What we do expect to eventually be doing is, in addition to specialization, we may be generating machine code. That's probably going to be well past 3.11, maybe past 3.12. So, the release that we still have until October next year is going to be 3.11, and that's where the specializing interpreters going to make its first entry. I don't think that we're going to do anything with machine code unless we get extremely lucky with our results halfway through the year. But eventually, that will be another tier. But I don't know, Just-In-Time compilation has a whole bunch of emotional baggage with it at this point that we're trying to avoid.Utsav: [19:25] Is it baggage from other projects trying it?Guido: [19:29] People assume that Just-In-Time compilation automatically makes all your code better. It turns out that it's not that simple. In our case, compilation is like, “What exactly is it that we compile?” At some point ahead of time, we compile your source code into bytecode. Then we translate the bytecode into specialized bytecode. I mean, everything happens at some point during runtime, so which thing would you call Just-In-Time? Guido: [20:04] So I'm not a big fan of using that term. And it usually makes people think of feats of magical optimization that have been touted by the Java community for a long time. And unfortunately, the magic is often such that you can't actually predict what the performance of your code is going to be. And we have enough of that, for example, with the modern CPUs and their fantastic branch prediction.Utsav: [20:35] Speaking of that, I saw that there's also a bunch of small wins y'all spoke about, that y’all can use to just improve performance, things like fixing the place of __dict__ in objects and changing the way integers are represented. What is just maybe one interesting story that came out of that?Guido: [20:53] Well, I would say calling Python functions is something that we actually are currently working on. And I have to say that this is not just the Microsoft team, but also other people in the core dev team, who are very excited about this and helping us in many ways. So, the idea is that in the Python interpreter, up to and including version 3.10, which is going to be released next week, actually, whenever you call a Python function, the first thing you do is create a frame object. And a frame object contains a bunch of state that is specific to that call that you're making. So, it points to the code object that represents the function that's being called, it points to the globals, it has a space for the local variables of the call, it has space for the arguments, it has space for the anonymous values on the evaluation stack. But the key thing is that it’s still a Python object. And there are some use cases where people actually inspect the Python frame objects, for example, if they want to do weird stuff with local variables. [22:18] Now, if you're a debugger, it makes total sense that you want to actually look at what are all the local variables in this frame? What are their names? What are their values and types? A debugger may even want to modify a local variable while the code is stopped in a breakpoint. That's all great. But for the execution of most code, most of the time, certainly, when you're not using a debugger, there's no reason that that frame needs to be a Python object. Because a Python object has a header, it has a reference count, it has a type, it is allocated as its own small segment of memory on the heap. It's all fairly inefficient. Also, if you call a function, then you create a few objects, then from that function, you call another function, all those frame objects end up scattered throughout the entire heap of the program. [23:17] What we have implemented in our version of 3.11, which is currently just the main branch of the CPython repo, is an allocation scheme where when we call a function, we still create something that holds the frame, but we allocate that in an array of frame structures. So, I can't call them frame objects because they don't have an object header, they don't have a reference count or type, it's just an array of structures. This means that unless that array runs out of space, calls can be slightly faster because you don't jump around on the heap. And allocation sort of is to allocate the next frame, you compare two pointers, and then you bump one counter, and now you have a new frame structure. And so, creation, and also deallocation of frames is faster. Frames are smaller because you don't have the object header. You also don't have the malloc overhead or the garbage collection overhead. And of course, it's backwards incompatible. So, what do we do now? Fortunately, there aren't that many ways that people access frames. And what we do is when people call an API that returns a frame object, we say, “Okay, well sure. Here's the frame in our array. Now we're going to allocate an object and we're going to copy some values to the frame object,” and we give that to the Python code. So, you can still introspect it and you can look at the locals as if nothing has changed. [25:04] But most of the time, people don't look at add frames. And this is actually an old optimization. I remember that the same idea existed in IronPython. And they did it differently. I think for them, it was like a compile-time choice when the bytecode equivalent in IronPython was generated for a function, it would dynamically make a choice whether to allocate a frame object or just a frame structure for that call. And their big bugaboo was, well, there is a function you can call sys dunder __getFrame__ and it just gives you the frame object. So, in the compiler, they were looking, were you using the exact thing named system dunder __getFrame__ and then they would say, “Oh, that's getFrame, now we're going to compile you slightly slower so you use a frame object.” We have the advantage that we can just always allocate the frame object on the fly. But we get similar benefits. And oh, yeah, I mentioned that the frame objects are allocated in array, what happens if that array runs out? Well, it's actually sort of a linked list of arrays. So, we can still create a new array of frames, like we have space for 100 or so which, in many programs, that's plenty. And if your call stack is more than 100 deep, we'll just have one discontinuity, but the semantics are still the same and we still have most of the benefits.Utsav: [26:39] Yeah, and maybe as a wrap-up question, there are a bunch of other improvements happening in the Python community for performance as well, right? There's Mypyc, which we're familiar with, which is using types, Mypy types to maybe compiled code to basically speed up. Are there any other improvements like that, that you're excited about, or you're interested in just following?Guido: [27:01] Well, Mypyc is very interesting. It gives much better performance boost, but only when you fully annotate your code and only when you actually follow the annotations precisely at runtime. In Mypy, if you say, “This function takes two integers,” and it returns an integer, then if you call it with something else, it's going to immediately blow up. It'll give you a traceback. But the standard Python semantics are that type annotations are optional, and sometimes they're white lies. And so, the types that you see at runtime may not actually be compatible with the types that were specified in the annotations. And it doesn't affect how your program executes. Unless you sort of start introspecting the annotations, your program runs exactly the same with or without annotations. [28:05] I mean, there are a couple of big holes that are in the type system, like any. And the type checker will say, “Oh, if you put any, everything is going to be fine.” And so, using that, it's very easy to have something that is passed, an object of an invalid type, and the type checker will never complain about it. And our promise is that the runtime will not complain about it either unless it really is a runtime error. Obviously, if you're somehow adding an integer to a string at runtime, it's still going to be a problem. But if you have a function that, say, computes the greatest common divisor of two numbers, which is this really cute little loop, if you define the percent operator in just the right way, you can pass in anything. I think there are examples where you can actually pass it to strings, and it will return a string without ever failing. [29:07] And so basically, Mypyc does things like the instance attributes are always represented in a compact way where there is no dunder __dict__. The best that we can do, which we are working on designing how we're actually going to do that, is make it so that if you don't look at the dunder __dict__ attribute, we don't necessarily have to store the instance attributes in a dictionary as long as we preserve the exact semantics. But if you use the dunder __dict__, at some later point, again, just like the frame objects, we have to materialize a dictionary. And Mypyc doesn't do that. It's super-fast if you don't use dunder __dict__. If you do use dunder __dict__, it just says, “dunder __dict__ not supported in this case.” [29:59] Mypyc really only compiles a small subset of the Python language. And that's great if that's the subset you're interested in. But I'm sure you can imagine how complex that is in practice for a large program.Utsav: [30:17] It reminds me of JavaScript performance when everything is working fast and then you use this one function, which you're not supposed to use to introspect an object or something, and then performance just breaks down. Guido: [30:29] Yeah, that will happen. Utsav: [30:31] But it's still super exciting. And I'm also super thankful that Python fails loudly when you try to add a number in the string, not like JavaScript,Guido: [30:41] Or PHP, or Perl.Utsav: [30:44] But yeah, thank you so much for being a guest. I think this was a lot of fun. And I think it walked through the performance improvement y’all are trying to make in an accessible way. So, I think it’s going to be useful for a lot of people. Yeah, thank you for being a guest.Guido: [30:58] My pleasure. It’s been a fun chat. Get on the email list at www.softwareatscale.dev

Watch the live stream: Watch on YouTube About the show Sponsored by us: Check out the courses over at Talk Python And Brian's book too! Special guest: Ethan Swan Michael #0: Changing themes to DIY Brian #1: SQLFluff Suggested by Dave Kotchessa. A SQL Linter, written in Python, tested with pytest Configurable, and configuration can live in many places including tox.ini and pyproject.toml. Great docs Rule reference with anti-pattern/best practice format Includes dialects for ANSI, PostgreSQL, MySQL, Teradata, BigQuery, Snoflake Note in docs: “SQLFluff is still in an open alpha phase - expect the tool to change significantly over the coming months, and expect potentially non-backward compatible api changes to happen at any point.” Michael #2: JupyterLab Desktop JupyterLab App is the cross-platform standalone application distribution of JupyterLab. Bundles a Python environment with several popular Python libraries ready to use in scientific computing and data science workflows. JupyterLab App works on Debian and Fedora based Linux, macOS and Windows operating systems. Ethan #3: Requests Cache Create a requests_cache session and call HTTP methods from there You can also do it without a session but that's a bit weird, looks like it's monkey patching requests or something… Results are cached Very handy for repeatedly calling endpoints especially if the returned data is large, or the server has to do some compute Reminds me of @functools.lru_cache Can set things like how long the cache should last (when to invalidate) Funny easter egg in example: “# Cache 400 responses as a solemn reminder of your failures” Brian #4: pypi-rename This is a cookiecutter template from Simon Willison Backstory: To refresh my memory on how to publish a new package with flit I created a new pytest plugin. Brian Skinn noticed it somehow, and suggested a better name. Thanks Brian. So, how to nicely rename. I searched and found Simon's template, which is… A cookiecutter template. So you can use cookiecutter to do some of this work for you. But it's based on setuptools, and I kinda like flit lately, so I just used the instructions. The README.md includes instructions for the steps needed: Create renamed version Publish under new name Change old one to depend on new one, but be mostly empty Modify readme to tell people what's going on Publish old name as a notice Now people looking for old one will find new one. People just installing old one will end up with new one also since it's a dependency. Michael #5: Django 4 coming with Redis Adapter #33012 closed New feature (fixed) → Add a Redis cache backend. Adds support for Redis to be used as a caching backend with Django. Redis is the most popular caching backend, adding it to django.core.cache module would be a great addition for developers who previously had to rely on the use of third party packages. It will be simpler than that provided by django-redis, for instance customising the serialiser is out-of-scope for the initial pass. Ethan #6: PEP 612 It wasn't possible to type a function that took in a function and returned a function with the same signature (which is what many decorators do) This creates a ParamSpec – which is much like a TypeVar, for anyone who has used them to type generic functions/classes It's a reminder that typing is still missing features and evolving, and it's good to accept the edge cases for now – “gradual typing” Reading Fluent Python by Ramalho has influenced my view on this – don't lose your mind trying to type crazy stuff, just accept that it's “gradual” Mention how typing is still evolving in Python and it's good to keep an eye out for new features that help you (see also PEP 645 – using int? for Optional[int]; and PEP 655 – annotating some TypedDict keys as required and others not required) Extras Michael Earsketch Django Critical CVE: CVE-2021-35042 Vulnerable versions: >= 3.0.0, < 3.1.13 Patched version: 3.1.13 Django 3.1.x before 3.1.13 and 3.2.x before 3.2.5 allows QuerySet.order_by SQL injection if order_by is untrusted input from a client of a web application. Ethan Pedalboard I happened upon this project recently and checked back, only to see that Brett Cannon was the last committer! A doc fix, like he suggested last episode Brian Zero Cost Exceptions in Python 3.11 Suggested by John Hagen Guido, Mark Shannon, and others at Microsoft are working on speeding up Python faster-cpython/ideas repo includes a slide deck from Guido which includes “Zero overhead” exception handling. Python 3.11 “What's New” page, Optimizations section includes: “Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.) MK: I played with this a bit. Joke: QA 101

Mark Shannon Discusses Crossville's Tile Business and His Retirement by Floor Focus Magazine

Watch the live stream: Watch on YouTube About the show Sponsored by Sentry: Sign up at pythonbytes.fm/sentry And please, when signing up, click Got a promo code? Redeem and enter PYTHONBYTES Special guest: Vincent D. Warmerdam koaning.io, Research Advocate @ Rasa and maintainer of a whole bunch of projects. Intro: Hello and Welcome to Python Bytes Where we deliver Python news and headlines directly to your earbuds. This is episode 235, recorded May 26 2021 I’m Brian Okken [HTML_REMOVED] [HTML_REMOVED] Brian #1: Flask 2.0 articles and reactions Change list Async in Flask 2.0 Patrick Kennedy on testdriven.io blog Great description discussion of how the async works in Flask 2.0 examples how to test async routes An opinionated review of the most interesting aspects of Flask 2.0 Miguel Grinberg video covers route decorators for common methods, ex @app.post(``"``/``"``) instead of @app.route("/", methods=["POST"]) web socket support async support Also includes some extensions Miguel has written to make things easier Great discussion, worth the 25 min play time. See also: Talk Python Episode 316 Michael #2: Python 3.11 will be 2x faster? via Mike Driscoll From the Python Language summit Guido asks "Can we make CPython faster?” We covered the Shannon Plan for speedups. Small team funded by Microsoft: Eric Snow, Mark Shannon, myself (might grow) Constrains: Mostly don’t break things. How to reach 2x speedup in 3.11 Adaptive, specializing bytecode interpreter “Zero overhead” exception handling Faster integer internals Put __dict__ at a fixed offset (-1?) There’s machine code generation in our future Who will benefit Users running CPU-intensive pure Python code •Users of websites built in Python Users of tools that happen to use Python Vincent #3: DEON, a project with meaningful checklists for data science projects! It’s a command line app that can generate checklists. You customize checklists There’s a set of examples (one for for each check) that explain why the checks it is matter. Make a little course on calmcode to cover it. Brian #4: 3 Tools to Track and Visualize the Execution of your Python Code Khuyen Tran Loguru — print better exceptions we covered in episode 111, Jan 2019, but still super cool snoop — print the lines of code being executed in a function covered in episode 141, July 2019, also still super cool heartrate — visualize the execution of a Python program in real-time this is new to us, woohoo Nice to have one persons take on a group of useful tools Plus great images of them in action. Michael #5: DuckDB + Pandas via __AlexMonahan__ What’s DuckDB? An in-process SQL OLAP database management system SQL on Pandas: After your data has been converted into a Pandas DataFrame often additional data wrangling and analysis still need to be performed. Using DuckDB, it is possible to run SQL efficiently right on top of Pandas DataFrames. Example import pandas as pd import duckdb mydf = pd.DataFrame({'a' : [1, 2, 3]}) print(duckdb.query("SELECT SUM(a) FROM mydf").to_df()) When you run a query in SQL, DuckDB will look for Python variables whose name matches the table names in your query and automatically start reading your Pandas DataFrames. For many queries, you can use DuckDB to process data faster than Pandas, and with a much lower total memory usage, without ever leaving the Pandas DataFrame binary format (“Pandas-in, Pandas-out”). The automatic query optimizer in DuckDB does lots of the hard, expert work you’d need in Pandas. Vincent #6: I work for a company called Rasa. We make a python library to make virtual assistants and there’s a few community projects. There’s a bunch of cool showcases, but one stood out when I was checking our community showcase last week. There’s a project that warns folks about forest fire updates over text. The project is open-sourced on GitHub and can be found here. There’s also a GIF demo here. Amit Tallapragada and Arvind Sankar observed that in the early days of the fires, news outlets and local governments provided a confusing mix of updates about fire containment and evacuation zones, leading some residents to evacuate unnecessarily. They teamed up to build a chatbot that would return accurate information about conditions in individual cities, including nearby fires, air quality, and weather data. What’s cool here isn’t just that Vincent is biased (again, he works for Rasa), it’s also a nice example of grass-roots impact. You can make a lot of impact if there’s open APIs around. They host a scraper that scrapes fire/weather info every 10 seconds. It also fetches evacuation information. You can text a number and it will send you up-to-date info based on your city. It will also notify you if there’s an evacuation order/plan. They even do some fuzzy matching to make sure that your city is matched even when you make a typo. Extras Michael PyCon US 2024 and 2025 Announced Vincent: Human-Learn: a suite of tools to have humans define models before resorting to machines. It’s scikit-learn compatible. One of the main features is that you’re able to draw a model! There’s a small guide that shows how to outperform a deep learning implementation by doing exploratory data analysis. It turns out, you can outperform Keras sometimes. There’s a suite of tools to turn python functions into scikit-learn compatible models. Keyword arguments become grid-search-able. Tutorial on calmcode.io to anybody interested. Can also be used for Bulk Labelling. Joke

The CPython implementation has grown and evolved significantly over the past ~25 years. In that time there have been many other projects to create compatible runtimes for your Python code. One of the challenges for these other projects is the lack of a fully documented specification of how and why everything works the way that it does. In the most recent Python language summit Mark Shannon proposed implementing a formal specification for CPython, and in this episode he shares his reasoning for why that would be helpful and what is involved in making it a reality.

Sponsored by Techmeme Ride Home podcast: pythonbytes.fm/ride Special guest: Steve Dower - @zooba Brian #1: Making Enums (as always, arguably) more Pythonic “I hate enums” Harry Percival Hilarious look at why enums are frustrating in Python and a semi-reasonable workaround to make them usable. Problems with enums of strings: Can’t directly compare enum elements with the values Having to use .value is dumb. Can’t do random choice of enum values Can’t convert directly to a list of values If you use IntEnum instead of Enum and use integer values instead of strings, it kinda works better. Making your own StringEnum also is better, but still doesn’t allow comparison. Solution: class BRAIN(str, Enum): SMALL = 'small' MEDIUM = 'medium' GALAXY = 'galaxy' def __str__(self) -> str: return str.__str__(self) Derive from both str and Enum, and add a *__str(self)__* method. Fixes everything except random.choice(). Michael #2: Python 3.10 will be up to 10% faster 4.5 years in the making, from Yury Selivanov work picked up by Pablo Galindo, Python core developer, Python 3.10/3.11 release manager LOAD_METHOD, CALL_METHOD, and LOAD_GLOBAL improved “Lot of conversations with Victor about his PEP 509, and he sent me a link to his amazing compilation of notes about CPython performance. One optimization that he pointed out to me was LOAD/CALL_METHOD opcodes, an idea first originated in PyPy.” There is a patch that implements this optimization Based on: LOAD_ATTR stores in its cache a pointer to the type of the object it works with, its tp_version_tag, and a hint for PyDict_GetItemHint. When we have a cache hit, LOAD_ATTR becomes super fast, since it only needs to lookup key/value in type's dict by a known offset (the real code is a bit more complex, to handle all edge cases of descriptor protocol etc). Steve #3: Python 3.9 and no more Windows 7 PEP 11 -- Removing support for little used platforms | Python.org Windows 7 - Microsoft Lifecycle | Microsoft Docs Default x64 download Brian #4: Writing Robust Bash Shell Scripts David Pashley Some great tips that I learned, and I’ve been writing bash scripts for decades. set -u : exits your script if you use an uninitialized variable set -e : exit the script if any statement returns a non-true return value. Prevents errors from snowballing. Expect the unexpected, like missing files, missing directories, etc. Be prepared for spaces in filenames. if [ "$filename" = "foo" ]; Using trap to handle interrupts, exits, terminal kills, to leave the system in a good state. Be careful of race conditions Be atomic Michael #5: Ideas for 5x faster CPython Twitter post by Anthony Shaw calling attention to roadmap by Mark Shannon Implementation plan for speeding up CPython: The overall aim is to speed up CPython by a factor of (approximately) five. We aim to do this in four distinct stages, each stage increasing the speed of CPython by (approximately) 50%: 1.5**4 ≈ 5 Each stage will be targeted at a separate release of CPython. Stage 1 -- Python 3.10: The key improvement for 3.10 will be an adaptive, specializing interpreter. The interpreter will adapt to types and values during execution, exploiting type stability in the program, without needing runtime code generation. Stage 2 -- Python 3.11: Improved performance for integers of less than one machine word. Faster calls and returns, through better handling of frames. Better object memory layout and reduced memory management overhead. Stage 3 -- Python 3.12 (requires runtime code generation): Simple "JIT" compiler for small regions. Stage 4 -- Python 3.13 (requires runtime code generation): Extend regions for compilation. Enhance compiler to generate superior machine code. Wild conversation over here. One excerpt, from Larry Hastings: Speaking as the Gilectomy guy: borrowed references are evil. The definition of the valid lifetime of a borrowed reference doesn't exist, because they are a hack (baked into the API!) that we mostly "get away with" just because of the GIL. If I still had wishes left on my monkey's paw I'd wish them away (1). (1) Unfortunately, I used my last wish back in February, wishing I could spend more time at home.* Steve #6: CPython core developer sprints Hosted by pythondiscord.com https://youtu.be/gXMdfBTcOfQ - Core dev Q&A Extras Brian: Tools I found recently that are kinda awesome in their own way - Brian mcbroken.com - Is the ice cream machine near you working? just a funny single purpose website vim-adventures.com - with a dash. Practice vim key bindings while playing an adventure game. Super cool. Joke: Hackobertfest 2020 t-shirt https://twitter.com/McCroden/status/1319646107790704640 5 Most Difficult Programming Languages in the World (Not really long enough for a full topic, but funny. I think I’ll cut short the last code example after we record) suggested by Troy Caudill Author: Lokajit Tikayatray malboge, intercal, brainf*, cow, and whitespace whitespace is my favorite: “Entire language depends on space, tab, and linefeed for writing any program. The Whitespace interpreter ignores Non-Whitespace characters and considers them as code comments.” Intercal is kinda great in that One thing I love about this article is that the author actually writes a “Hello World!” for each language. Examples of “Hello World!” malboge (=

Episode ninety of A History of Rock Music in Five Hundred Songs looks at “Runaway” by Del Shannon, and at the early use of synthesised sound in rock music. Click the full post to read liner notes, links to more information, and a transcript of the episode.   Patreon backers also have a ten-minute bonus episode available, on “Blue Moon” by the Marcels. Tilt Araiza has assisted invaluably by doing a first-pass edit, and will hopefully be doing so from now on. Check out Tilt’s irregular podcasts at http://www.podnose.com/jaffa-cakes-for-proust and http://sitcomclub.com/ —-more—- A note Almost every version of “Runaway” currently available is in stereo, and the stereo version of the song has a slightly different vocal take to the original mono version. Unfortunately, there appear to be multiple “original mono versions” too. To check that what I’m using here, a mono track available as a bonus on a reissue of the album Runaway With Del Shannon, is actually the hit single version, I downloaded two vinyl rips of the single and one vinyl rip of a mono hits compilation from the sixties that had been uploaded to YouTube. Unfortunately no two copies of the song I could find online would play in synch – they all appear to be mastered at slightly different speeds, possibly due to the varispeeding I talk about in the episode. I’ve gone with the version I did because it’s a clean-sounding mono version, but it may not be exactly what people heard in 1961. Resources As always, I’ve created a Mixcloud streaming playlist with full versions of all the songs in the episode. This one is in two parts because of the number of songs by Del Shannon in the mix. Part one, part two. Only one biography of Del Shannon has ever been written, and that’s out of print and (to judge from the Amazon reviews) not very well written, so I’ve relied again on other sources. Those include the liner notes to this CD, a good selection of Shannon’s work (with the proviso that “Runaway” is in stereo — see above; the articles on Shannon and Max Crook on This Is My Story, the official Del Shannon website,  and the Internet Archive’s cached copy of Max Crook’s old website. Patreon This podcast is brought to you by the generosity of my backers on Patreon. Why not join them?   Transcript Today’s episode is an odd one to write, as just as I put the finishing touches to the script I discovered that Max Crook, the keyboard player at the centre of this story, died less than two weeks ago. The news wasn’t widely reported, and I only discovered this by double-checking a detail and discovering an obituary of him. Crook was one of the great early pioneers of electronic music, and a massive talent, and he’s a big part of the story I’m telling today, so before we go into the story proper I just wanted to take a moment to acknowledge his passing, and to regret that it hasn’t been more widely noted. One of the things we’ve not talked about much in this podcast so far is the technology of music. We’ve discussed it a bit — we’ve looked at how things like the change from 78s to 45s affected the music industry, at the transition from recording on discs to recording on tape, at the electrification of the guitar, and at Les Paul’s inventions. But in general, the music we’ve looked at has been made in a fairly straightforward manner — some people with some combination of guitars, bass, piano, drums, and saxophone, and maybe a few string players on the most recent recordings, get together in front of a microphone and sing and play those instruments. But today, we’re going to look at the start of synthesisers being used in rock and roll music. Today we’re going to look at “Runaway” by Del Shannon: [Excerpt: Del Shannon, “Runaway”] Synthesised sound has a far longer pedigree than you might expect. The use of electronics to create music goes back to the invention of the theremin and the ondes martenot in the 1920s, and by the 1930s, people had already started using polyphonic keyboard-based electronic instruments. The Novachord was produced by the Hammond organ company between 1938 and 1942, and was introduced at the World’s Fair in 1939, where Ferdinand Grofe, who we talked about a little in the episode on “Cathy’s Clown”, led a group consisting only of Novachord players in a public performance. The Novachord never achieved mass popularity because of World War II halting its production, but it was still used in a few recordings. One that’s of particular interest to those of us interested in early rock and roll is Slim Gaillard’s “Novachord Boogie”: [Excerpt: Slim Gaillard, “Novachord Boogie”] But also it was used on one of the most famous records of the late thirties. These days, when you hear “We’ll Meet Again” by Vera Lynn on documentaries about the second world war, this is the version you hear: [Excerpt: Vera Lynn, “We’ll Meet Again”] But the record that people actually listened to in World War II didn’t have any of that orchestration. It was Lynn accompanied by a single instrument, a Novachord played by Arthur Young, and is notably more interesting and less syrupy: [Excerpt: Vera Lynn with Arthur Young on Novachord, “We’ll Meet Again”] So even in the late thirties, synthesised sounds were making their way on to extremely popular recordings, but it wasn’t until after the war that electronic instruments started getting used in a major way. And the most popular of those instruments was a monophonic keyboard instrument called the clavioline, which was first produced in 1947. The clavioline was mostly used as a novelty element, but it appeared on several hit records. We’re going to devote a whole episode in a few months’ time to a record with the clavioline as lead instrument, but you can hear it on several fifties novelty records, like “Little Red Monkey” by Frank Chacksfield’s Tunesmiths, a UK top ten hit from 1953: [Excerpt: Frank Chacksfield’s Tunesmiths, “Little Red Monkey”] But while the clavioline itself was in use quite widely in the fifties, the first big rock and roll hit with an electronic synthesiser actually used a modified clavioline called a musitron, which was put together by an electronics amateur and keyboard player named Max Crook, from Ann Arbor, Michigan. Crook had built his musitron using a clavioline as a base, but adding parts from TVs, reel-to-reel recorders, and bits of whatever electronic junk he could salvage parts from. He’d started playing electronic instruments in his teens, and had built his own recording studio. Sadly, the early records Crook made are not easily available. The only place I’ve been able to track down copies of his early singles in a digital format is one grey-market CD, which I wasn’t able to obtain in time to include the tracks here and which only seems to be available from one shop in Cornwall. His first band, the White Bucks, released a single, “Get That Fly” backed with “Orny”, on Dot Records, but I can tell you from experience that if you search anywhere online for “White Bucks Orny” you will find… well, not that record, anyway. Even more interestingly, he apparently recorded a version of “Bumble Boogie”, the novelty instrumental that would later become a hit for B. Bumble and the Stingers, with Berry Gordy at some point in the late fifties. Sadly, that too is not generally available. But it wasn’t until he auditioned for Charlie Johnson and the Big Little Show Band that Max Crook met the people who were going to become his most important collaborators. The Big Little Show Band had started as Doug DeMott and The Moonlight Ramblers, a honky-tonk band that played at the Hi-Lo Club in Battle Creek, Michigan. Battle Creek is a company town, midway between Chicago and Detroit, which is most famous as being the headquarters of the Kellogg company, the cereal manufacturer and largest employer there. It’s not somewhere you’d expect great rock and roll to come from, being as it is a dull medium-sized town with little in the way of culture or nightlife. The Hi-Lo Club was a rough place, frequented by hard-working, hard-drinking people, and Doug DeMott had been a hard drinker himself — so hard a drinker, in fact, that he was soon sacked. The group’s rhythm guitarist, Charles Westover, had changed his name to Charlie Johnson and put together a new lineup of the group based around himself and the bass player, Loren Dugger. They got in a new drummer, Dick Parker, and then went through a couple of guitarists before deciding to hire a keyboard player instead. Once they auditioned Crook, with his musitron, which he could clip to the piano and thus provide chordal piano accompaniment while playing a lead melody on his musitron, they knew they had the right player for them. Crook had a friend, a black DJ named Ollie McLaughlin, who had music industry connections, and had been involved in the White Bucks recordings. Crook and Johnson started writing songs and recording demos for McLaughlin, who got Johnson a session with Irving Micahnik and Harry Balk, two record producers who were working with Johnny and the Hurricanes, an instrumental group who’d had a big hit with “Red River Rock” a year or so previously: [Excerpt: Johnny and the Hurricanes, “Red River Rock”] Johnson recorded two songs in New York, without his normal musicians backing him. However, Micahnik and Balk thought that the tracks were too dirgey, and Johnson was singing flat — and listening to them it’s not hard to see why they thought that: [Excerpt: Del Shannon, “The Search”] They told him to go back and come up with some more material that was less dirgey. Two things did come out of the association straight away, though. The first was that Charles Johnson changed his name again, combining a forename he chose to be reminiscent of the Cadillac Coup deVille with a surname he took from an aspiring wrestler he knew, Mark Shannon, to become Del Shannon. The second was that Johnny and the Hurricanes recorded one of Max Crook’s instrumentals, “Mr Lonely”, as a B-side, and you can hear in the Hammond organ part the kind of part that Crook would have been playing on his Musitron: [Excerpt: Johnny and the Hurricanes, “Mr Lonely”] Shannon and Crook recorded a tape of many other songs they were working on for McLaughlin to play to Micahnik and Balk, but they weren’t interested — until they heard a fragment of a song that Shannon and Crook had recorded, and which they’d then mostly taped over. That song, “Runaway”, was the one they wanted. “Runaway” had been an idea that had happened almost by accident. The band had been jamming on stage, and Crook had hit a chord change that Shannon thought sounded interesting — in later tellings of the story, this is always the Am-G chord change that opens the song, but I suspect the actual chord change that caught his ear was the one where they go to an E major chord rather than the expected G or E minor on the line “As our hearts were young”. That’s the only truly unusual chord change in the song. But whatever it was, Shannon liked the changes that Crook was playing — he and Crook would both later talk about how bored he was with the standard doo-wop progression that made up the majority of the songs they were playing at the time — and the band ended up jamming on the new chord sequence for fifteen or twenty minutes before the club owner told them to play something else. The next day, Shannon took his guitar to the carpet shop where he worked, and when there were no customers in, he would play the song to himself and write lyrics. He initially wrote two verses, but decided to scrap one. They performed the song, then titled “My Little Runaway”, that night, and it became a regular part of their set. The crucial element in the song, though, came during that first performance. Shannon said, just before they started, “Max, when I point to you, play something”. And so when Shannon got to the end of the chorus, he pointed, and Crook played this: [Excerpt: Del Shannon, “Runaway”] When they were told that Micahnik and Balk liked the fragment of song that they’d heard, Shannon and Crook recorded a full demo of the song and sent it on to them. The producers weren’t hugely impressed with the finished song, saying they thought it sounded like three songs trying to coexist, and they also didn’t like Shannon’s voice, but they *did* like Crook and the Musitron, and so they invited Crook and Shannon to come to New York to record. The two men drove seven hundred miles in a broken-down car, with their wives, to get from Michigan to New York. It was the middle of winter, the car had no heating, and Shannon smoked while Crook was allergic to tobacco smoke, so they had to keep the windows open. The session they were going to do was a split session — they were going to record two Del Shannon vocal tracks, and two instrumentals by Crook, who was recording under the name “Maximilian” without a surname (though the “Max” in his name was actually short for Maxfield). Crook was definitely the one they were interested in — he rearranged the way the microphones were arranged in the studio, to get the sound he wanted rather than the standard studio sound, and he also had a bag full of gadgets that the studio engineers were fascinated by, for altering the Musitron’s sound. The first single released as by “Maximilian” was “The Snake”, which featured Crook and Shannon’s wives on handclaps, along with an additional clapper who was found on the street and paid forty dollars to come in and clap along: [Excerpt: Maximilian, “The Snake”] After that, the two women got bored and wandered off down Broadway. They eventually found themselves in the audience for a TV game show, Beat the Clock, and Joann Crook ended up a contestant on the show — their husbands didn’t believe them, when they explained later where they’d been, until acquaintances mentioned having seen Joann on TV. Meanwhile, the two men were working on another Maximillian track, and on two Del Shannon tracks, one of which was “Runaway”. They couldn’t afford to stay overnight in New York, so they drove back to Michigan, but when the record company listened to “Runaway”, they discovered that Shannon had been singing flat due to nerves. Shannon had to go back to New York, this time by plane, to rerecord his vocals. According to Crook, even this wasn’t enough, and the engineers eventually had to varispeed his vocals to get them in key with the backing track. I’m not at all sure how this would have worked, as speeding up his vocals would have also meant that he was singing at a different tempo, but that’s what Crook said, and the vocal does have a slightly different quality to it. And Harry Balk backed Crook up, saying “We finally got Del on key, and it sounded great, but it didn’t sound like Del. We mixed it anyhow, and it came out wonderful. When I brought Ollie and Del into my office to hear it, Del had a bit of a fit. He said, ‘Harry, that doesn’t even sound like me!’ I just remember saying, ‘Yeah but Del, nobody knows what the hell you sound like!” Like most great records, “Runaway” was the sum of many parts. Shannon later broke down all the elements that went into the song, saying: “I learned falsetto from The Ink Spots’ ‘We Three,'”: [Excerpt: The Ink Spots, “We Three (My Echo, My Shadow, and Me)”] “I eventually got hooked on Jimmy Jones’ ‘Handy Man’ in ’59 and would sing that at the Hi-Lo Club.”: [Excerpt: Jimmy Jones, “Handy Man”] “I always had the idea of ‘running away’ somewhere in the back of my mind. ‘I wa-wa-wa-wa-wonder, why…’ I borrowed from Dion & The Belmonts’ ‘I Wonder Why.'” [Excerpt: Dion and the Belmonts, “I Wonder Why”] “The beats you hear in there, ‘…I wonder, bam-bam-bam, I wa-wa…’ I stole from Bobby Darin’s ‘Dream Lover.'” [Excerpt: Bobby Darin, “Dream Lover”] Listening to the song, you can definitely hear all those elements that Shannon identifies in there, but what emerges is something fresh and original, unlike anything else out at the time: [Excerpt: Del Shannon, “Runaway”] “Runaway” went to number one in almost every country that had a chart at the time, and top five in most of the rest. In America, the song it knocked off the top was “Blue Moon” by the Marcels, one of those songs with the doo-wop progression that Shannon had been so bored with. At its peak, it was selling eighty thousand copies a day, and Billboard put it at number three hundred and sixty four on the all-time charts in 2018. It was a massive success, and a game-changer in the music industry. Maximilian’s single, on the other hand, only made the top forty in Argentina. Clearly, Del Shannon was the artist who was going to be worth following, but they did release a few more singles by Maximilian, things like “The Twisting Ghost”: [Excerpt: Maximilian, “The Twisting Ghost”] That made the Canadian top forty, but Maximilian never became a star in his own right. Shannon, on the other hand, recorded a string of hits, though none were as successful as “Runaway”. The most successful was the follow-up, “Hats off to Larry”, which was very much “Runaway part 2”: [Excerpt: Del Shannon, “Hats off to Larry”] But every single he released after that was slightly less successful than the one before. He soon stopped working with Crook, who remained at the Hi-Lo Club with the rest of the band while Shannon toured the country, and without Crook’s Musitron playing his records were far less interesting than his earliest singles, though he did have the distinction of being one of the few singers of this era to write the bulk of his own material. He managed to further sabotage his career by suing Micahnik and Balk, and by 1963 he was largely washed up, though he did do one more thing that would make him at least a footnote in music history for something other than “Runaway”. He was more popular in the UK than in the US, and he even appeared in the film “It’s Trad Dad!”, a cheap cash-in on the trad jazz craze, starring Helen Shapiro and Craig Douglas as teenagers who try to persuade the stuffy adults who hate the young people’s music that the Dukes of Dixieland, Mr. Acker Bilk and the Temperance Seven are not dangerous obscene noises threatening the morals of the nation’s youth. That film also featured Gene Vincent and Chubby Checker along with a lot of British trumpet players, and was the first feature film made by Richard Lester, who we’ll be hearing more about in this story. So Shannon spent a fair amount of time in the UK, and in 1963 he noticed a song by a new British group that was rising up the UK charts and covered it. His version of “From Me to You” only made number seventy-seven on the US charts, but it was still the first version of a Lennon/McCartney song to make the Hot One Hundred: [Excerpt: Del Shannon, “From Me to You”] He made some interesting records in the rest of the sixties, and had the occasional fluke hit, but the music he was making, a unique blend of hard garage rock and soft white doo-wop, was increasingly out of step with the rest of the industry. In the mid and late sixties, his biggest successes came with songwriting and productions for other artists. He wrote “I Go to Pieces” which became a hit for Peter & Gordon: [Excerpt: Peter and Gordon, “I Go to Pieces”] Produced the band Smith in their cover version of “Baby It’s You”, which made the top five: [Excerpt: Smith, “Baby It’s You”] And produced Brian Hyland’s million-selling version of a Curtis Mayfield song that I’m not going to play, because its title used a racial slur against Romani people which most non-Romani people didn’t then regard as a slur, but which is a great record if you can get past that. That Hyland record featured Crook, reunited briefly with Shannon. But over the seventies Shannon seemed increasingly lost, and while he continued to make records, including some good ones made in the UK with production by Dave Edmunds and Jeff Lynne, he was increasingly unwell with alcoholism. He finally got sober in 1978, and managed to have a fluke hit in 1981 with a cover version of Phil Phillips’ “Sea of Love”, produced by Tom Petty and with Petty’s band the Heartbreakers backing him: [Excerpt: Del Shannon, “Sea of Love”] He also came to people’s attention when a rerecorded version of “Runaway” with new lyrics was used as the theme for the TV show Crime Story. In 1989, Del Shannon was working on a comeback album, with Jeff Lynne producing and members of Tom Petty and the Heartbreakers as backing musicians. The same people had previously worked on Roy Orbison’s last album, which had been his biggest success in decades, and Lynne was gaining a reputation for resuscitating the careers of older musicians. Both Lynne and Petty were fans of Shannon and had worked with him previously, and it seemed likely that he might be able to have a hit with some of the material he was working on. Certainly “Walk Away”, which Shannon co-wrote with Lynne and Petty, sounds like the kind of thing that was getting radio play around that time: [Excerpt: Del Shannon, “Walk Away”] There were even rumours that Lynne and Petty were thinking of inviting Shannon to join the Travelling Wilburys to replace Roy Orbison, though that seems unlikely to me. Unfortunately, by the time the album came out, Shannon was dead. He’d been suffering from depression for decades, and he died of suicide in early 1990, aged fifty-five. His widow later sued the manufacturers of the new wonder drug, Prozac, which he’d been prescribed a couple of weeks earlier, claiming that it caused his death. Max Crook, meanwhile, had become a firefighter and burglar alarm installer, while also pursuing a low-key career in music, mostly making religious music. When Shannon was posthumously inducted into the Rock and Roll Hall of Fame, Crook volunteered to perform at the ceremony, playing his original Musitron, but his offer was ignored. In later years he would regularly show up at annual celebrations of Shannon, and talk about the music they made together, and play for their fans. He died on July the first this year, aged eighty-three.

Episode ninety of A History of Rock Music in Five Hundred Songs looks at "Runaway" by Del Shannon, and at the early use of synthesised sound in rock music. Click the full post to read liner notes, links to more information, and a transcript of the episode.   Patreon backers also have a ten-minute bonus episode available, on "Blue Moon" by the Marcels. Tilt Araiza has assisted invaluably by doing a first-pass edit, and will hopefully be doing so from now on. Check out Tilt's irregular podcasts at http://www.podnose.com/jaffa-cakes-for-proust and http://sitcomclub.com/ ----more---- A note Almost every version of “Runaway” currently available is in stereo, and the stereo version of the song has a slightly different vocal take to the original mono version. Unfortunately, there appear to be multiple “original mono versions” too. To check that what I'm using here, a mono track available as a bonus on a reissue of the album Runaway With Del Shannon, is actually the hit single version, I downloaded two vinyl rips of the single and one vinyl rip of a mono hits compilation from the sixties that had been uploaded to YouTube. Unfortunately no two copies of the song I could find online would play in synch – they all appear to be mastered at slightly different speeds, possibly due to the varispeeding I talk about in the episode. I've gone with the version I did because it's a clean-sounding mono version, but it may not be exactly what people heard in 1961. Resources As always, I've created a Mixcloud streaming playlist with full versions of all the songs in the episode. This one is in two parts because of the number of songs by Del Shannon in the mix. Part one, part two. Only one biography of Del Shannon has ever been written, and that's out of print and (to judge from the Amazon reviews) not very well written, so I've relied again on other sources. Those include the liner notes to this CD, a good selection of Shannon's work (with the proviso that "Runaway" is in stereo -- see above; the articles on Shannon and Max Crook on This Is My Story, the official Del Shannon website,  and the Internet Archive's cached copy of Max Crook's old website. Patreon This podcast is brought to you by the generosity of my backers on Patreon. Why not join them?   Transcript Today's episode is an odd one to write, as just as I put the finishing touches to the script I discovered that Max Crook, the keyboard player at the centre of this story, died less than two weeks ago. The news wasn't widely reported, and I only discovered this by double-checking a detail and discovering an obituary of him. Crook was one of the great early pioneers of electronic music, and a massive talent, and he's a big part of the story I'm telling today, so before we go into the story proper I just wanted to take a moment to acknowledge his passing, and to regret that it hasn't been more widely noted. One of the things we've not talked about much in this podcast so far is the technology of music. We've discussed it a bit -- we've looked at how things like the change from 78s to 45s affected the music industry, at the transition from recording on discs to recording on tape, at the electrification of the guitar, and at Les Paul's inventions. But in general, the music we've looked at has been made in a fairly straightforward manner -- some people with some combination of guitars, bass, piano, drums, and saxophone, and maybe a few string players on the most recent recordings, get together in front of a microphone and sing and play those instruments. But today, we're going to look at the start of synthesisers being used in rock and roll music. Today we're going to look at "Runaway" by Del Shannon: [Excerpt: Del Shannon, "Runaway"] Synthesised sound has a far longer pedigree than you might expect. The use of electronics to create music goes back to the invention of the theremin and the ondes martenot in the 1920s, and by the 1930s, people had already started using polyphonic keyboard-based electronic instruments. The Novachord was produced by the Hammond organ company between 1938 and 1942, and was introduced at the World's Fair in 1939, where Ferdinand Grofe, who we talked about a little in the episode on "Cathy's Clown", led a group consisting only of Novachord players in a public performance. The Novachord never achieved mass popularity because of World War II halting its production, but it was still used in a few recordings. One that's of particular interest to those of us interested in early rock and roll is Slim Gaillard's "Novachord Boogie": [Excerpt: Slim Gaillard, "Novachord Boogie"] But also it was used on one of the most famous records of the late thirties. These days, when you hear "We'll Meet Again" by Vera Lynn on documentaries about the second world war, this is the version you hear: [Excerpt: Vera Lynn, "We'll Meet Again"] But the record that people actually listened to in World War II didn't have any of that orchestration. It was Lynn accompanied by a single instrument, a Novachord played by Arthur Young, and is notably more interesting and less syrupy: [Excerpt: Vera Lynn with Arthur Young on Novachord, "We'll Meet Again"] So even in the late thirties, synthesised sounds were making their way on to extremely popular recordings, but it wasn't until after the war that electronic instruments started getting used in a major way. And the most popular of those instruments was a monophonic keyboard instrument called the clavioline, which was first produced in 1947. The clavioline was mostly used as a novelty element, but it appeared on several hit records. We're going to devote a whole episode in a few months' time to a record with the clavioline as lead instrument, but you can hear it on several fifties novelty records, like "Little Red Monkey" by Frank Chacksfield's Tunesmiths, a UK top ten hit from 1953: [Excerpt: Frank Chacksfield's Tunesmiths, "Little Red Monkey"] But while the clavioline itself was in use quite widely in the fifties, the first big rock and roll hit with an electronic synthesiser actually used a modified clavioline called a musitron, which was put together by an electronics amateur and keyboard player named Max Crook, from Ann Arbor, Michigan. Crook had built his musitron using a clavioline as a base, but adding parts from TVs, reel-to-reel recorders, and bits of whatever electronic junk he could salvage parts from. He'd started playing electronic instruments in his teens, and had built his own recording studio. Sadly, the early records Crook made are not easily available. The only place I've been able to track down copies of his early singles in a digital format is one grey-market CD, which I wasn't able to obtain in time to include the tracks here and which only seems to be available from one shop in Cornwall. His first band, the White Bucks, released a single, "Get That Fly" backed with "Orny", on Dot Records, but I can tell you from experience that if you search anywhere online for "White Bucks Orny" you will find... well, not that record, anyway. Even more interestingly, he apparently recorded a version of "Bumble Boogie", the novelty instrumental that would later become a hit for B. Bumble and the Stingers, with Berry Gordy at some point in the late fifties. Sadly, that too is not generally available. But it wasn't until he auditioned for Charlie Johnson and the Big Little Show Band that Max Crook met the people who were going to become his most important collaborators. The Big Little Show Band had started as Doug DeMott and The Moonlight Ramblers, a honky-tonk band that played at the Hi-Lo Club in Battle Creek, Michigan. Battle Creek is a company town, midway between Chicago and Detroit, which is most famous as being the headquarters of the Kellogg company, the cereal manufacturer and largest employer there. It's not somewhere you'd expect great rock and roll to come from, being as it is a dull medium-sized town with little in the way of culture or nightlife. The Hi-Lo Club was a rough place, frequented by hard-working, hard-drinking people, and Doug DeMott had been a hard drinker himself -- so hard a drinker, in fact, that he was soon sacked. The group's rhythm guitarist, Charles Westover, had changed his name to Charlie Johnson and put together a new lineup of the group based around himself and the bass player, Loren Dugger. They got in a new drummer, Dick Parker, and then went through a couple of guitarists before deciding to hire a keyboard player instead. Once they auditioned Crook, with his musitron, which he could clip to the piano and thus provide chordal piano accompaniment while playing a lead melody on his musitron, they knew they had the right player for them. Crook had a friend, a black DJ named Ollie McLaughlin, who had music industry connections, and had been involved in the White Bucks recordings. Crook and Johnson started writing songs and recording demos for McLaughlin, who got Johnson a session with Irving Micahnik and Harry Balk, two record producers who were working with Johnny and the Hurricanes, an instrumental group who'd had a big hit with "Red River Rock" a year or so previously: [Excerpt: Johnny and the Hurricanes, "Red River Rock"] Johnson recorded two songs in New York, without his normal musicians backing him. However, Micahnik and Balk thought that the tracks were too dirgey, and Johnson was singing flat -- and listening to them it's not hard to see why they thought that: [Excerpt: Del Shannon, "The Search"] They told him to go back and come up with some more material that was less dirgey. Two things did come out of the association straight away, though. The first was that Charles Johnson changed his name again, combining a forename he chose to be reminiscent of the Cadillac Coup deVille with a surname he took from an aspiring wrestler he knew, Mark Shannon, to become Del Shannon. The second was that Johnny and the Hurricanes recorded one of Max Crook's instrumentals, "Mr Lonely", as a B-side, and you can hear in the Hammond organ part the kind of part that Crook would have been playing on his Musitron: [Excerpt: Johnny and the Hurricanes, "Mr Lonely"] Shannon and Crook recorded a tape of many other songs they were working on for McLaughlin to play to Micahnik and Balk, but they weren't interested -- until they heard a fragment of a song that Shannon and Crook had recorded, and which they'd then mostly taped over. That song, "Runaway", was the one they wanted. "Runaway" had been an idea that had happened almost by accident. The band had been jamming on stage, and Crook had hit a chord change that Shannon thought sounded interesting -- in later tellings of the story, this is always the Am-G chord change that opens the song, but I suspect the actual chord change that caught his ear was the one where they go to an E major chord rather than the expected G or E minor on the line “As our hearts were young”. That's the only truly unusual chord change in the song. But whatever it was, Shannon liked the changes that Crook was playing -- he and Crook would both later talk about how bored he was with the standard doo-wop progression that made up the majority of the songs they were playing at the time -- and the band ended up jamming on the new chord sequence for fifteen or twenty minutes before the club owner told them to play something else. The next day, Shannon took his guitar to the carpet shop where he worked, and when there were no customers in, he would play the song to himself and write lyrics. He initially wrote two verses, but decided to scrap one. They performed the song, then titled "My Little Runaway", that night, and it became a regular part of their set. The crucial element in the song, though, came during that first performance. Shannon said, just before they started, "Max, when I point to you, play something". And so when Shannon got to the end of the chorus, he pointed, and Crook played this: [Excerpt: Del Shannon, "Runaway"] When they were told that Micahnik and Balk liked the fragment of song that they'd heard, Shannon and Crook recorded a full demo of the song and sent it on to them. The producers weren't hugely impressed with the finished song, saying they thought it sounded like three songs trying to coexist, and they also didn't like Shannon's voice, but they *did* like Crook and the Musitron, and so they invited Crook and Shannon to come to New York to record. The two men drove seven hundred miles in a broken-down car, with their wives, to get from Michigan to New York. It was the middle of winter, the car had no heating, and Shannon smoked while Crook was allergic to tobacco smoke, so they had to keep the windows open. The session they were going to do was a split session -- they were going to record two Del Shannon vocal tracks, and two instrumentals by Crook, who was recording under the name "Maximilian" without a surname (though the "Max" in his name was actually short for Maxfield). Crook was definitely the one they were interested in -- he rearranged the way the microphones were arranged in the studio, to get the sound he wanted rather than the standard studio sound, and he also had a bag full of gadgets that the studio engineers were fascinated by, for altering the Musitron's sound. The first single released as by "Maximilian" was "The Snake", which featured Crook and Shannon's wives on handclaps, along with an additional clapper who was found on the street and paid forty dollars to come in and clap along: [Excerpt: Maximilian, "The Snake"] After that, the two women got bored and wandered off down Broadway. They eventually found themselves in the audience for a TV game show, Beat the Clock, and Joann Crook ended up a contestant on the show -- their husbands didn't believe them, when they explained later where they'd been, until acquaintances mentioned having seen Joann on TV. Meanwhile, the two men were working on another Maximillian track, and on two Del Shannon tracks, one of which was "Runaway". They couldn't afford to stay overnight in New York, so they drove back to Michigan, but when the record company listened to "Runaway", they discovered that Shannon had been singing flat due to nerves. Shannon had to go back to New York, this time by plane, to rerecord his vocals. According to Crook, even this wasn't enough, and the engineers eventually had to varispeed his vocals to get them in key with the backing track. I'm not at all sure how this would have worked, as speeding up his vocals would have also meant that he was singing at a different tempo, but that's what Crook said, and the vocal does have a slightly different quality to it. And Harry Balk backed Crook up, saying "We finally got Del on key, and it sounded great, but it didn't sound like Del. We mixed it anyhow, and it came out wonderful. When I brought Ollie and Del into my office to hear it, Del had a bit of a fit. He said, 'Harry, that doesn't even sound like me!' I just remember saying, 'Yeah but Del, nobody knows what the hell you sound like!" Like most great records, "Runaway" was the sum of many parts. Shannon later broke down all the elements that went into the song, saying: "I learned falsetto from The Ink Spots' 'We Three,'": [Excerpt: The Ink Spots, "We Three (My Echo, My Shadow, and Me)"] "I eventually got hooked on Jimmy Jones' 'Handy Man' in '59 and would sing that at the Hi-Lo Club.": [Excerpt: Jimmy Jones, "Handy Man"] "I always had the idea of 'running away' somewhere in the back of my mind. 'I wa-wa-wa-wa-wonder, why...' I borrowed from Dion & The Belmonts' 'I Wonder Why.'" [Excerpt: Dion and the Belmonts, "I Wonder Why"] "The beats you hear in there, '...I wonder, bam-bam-bam, I wa-wa...' I stole from Bobby Darin's 'Dream Lover.'" [Excerpt: Bobby Darin, "Dream Lover"] Listening to the song, you can definitely hear all those elements that Shannon identifies in there, but what emerges is something fresh and original, unlike anything else out at the time: [Excerpt: Del Shannon, "Runaway"] "Runaway" went to number one in almost every country that had a chart at the time, and top five in most of the rest. In America, the song it knocked off the top was "Blue Moon" by the Marcels, one of those songs with the doo-wop progression that Shannon had been so bored with. At its peak, it was selling eighty thousand copies a day, and Billboard put it at number three hundred and sixty four on the all-time charts in 2018. It was a massive success, and a game-changer in the music industry. Maximilian's single, on the other hand, only made the top forty in Argentina. Clearly, Del Shannon was the artist who was going to be worth following, but they did release a few more singles by Maximilian, things like "The Twisting Ghost": [Excerpt: Maximilian, "The Twisting Ghost"] That made the Canadian top forty, but Maximilian never became a star in his own right. Shannon, on the other hand, recorded a string of hits, though none were as successful as "Runaway". The most successful was the follow-up, "Hats off to Larry", which was very much "Runaway part 2": [Excerpt: Del Shannon, "Hats off to Larry"] But every single he released after that was slightly less successful than the one before. He soon stopped working with Crook, who remained at the Hi-Lo Club with the rest of the band while Shannon toured the country, and without Crook's Musitron playing his records were far less interesting than his earliest singles, though he did have the distinction of being one of the few singers of this era to write the bulk of his own material. He managed to further sabotage his career by suing Micahnik and Balk, and by 1963 he was largely washed up, though he did do one more thing that would make him at least a footnote in music history for something other than "Runaway". He was more popular in the UK than in the US, and he even appeared in the film "It's Trad Dad!", a cheap cash-in on the trad jazz craze, starring Helen Shapiro and Craig Douglas as teenagers who try to persuade the stuffy adults who hate the young people's music that the Dukes of Dixieland, Mr. Acker Bilk and the Temperance Seven are not dangerous obscene noises threatening the morals of the nation's youth. That film also featured Gene Vincent and Chubby Checker along with a lot of British trumpet players, and was the first feature film made by Richard Lester, who we'll be hearing more about in this story. So Shannon spent a fair amount of time in the UK, and in 1963 he noticed a song by a new British group that was rising up the UK charts and covered it. His version of "From Me to You" only made number seventy-seven on the US charts, but it was still the first version of a Lennon/McCartney song to make the Hot One Hundred: [Excerpt: Del Shannon, "From Me to You"] He made some interesting records in the rest of the sixties, and had the occasional fluke hit, but the music he was making, a unique blend of hard garage rock and soft white doo-wop, was increasingly out of step with the rest of the industry. In the mid and late sixties, his biggest successes came with songwriting and productions for other artists. He wrote "I Go to Pieces" which became a hit for Peter & Gordon: [Excerpt: Peter and Gordon, "I Go to Pieces"] Produced the band Smith in their cover version of "Baby It's You", which made the top five: [Excerpt: Smith, "Baby It's You"] And produced Brian Hyland's million-selling version of a Curtis Mayfield song that I'm not going to play, because its title used a racial slur against Romani people which most non-Romani people didn't then regard as a slur, but which is a great record if you can get past that. That Hyland record featured Crook, reunited briefly with Shannon. But over the seventies Shannon seemed increasingly lost, and while he continued to make records, including some good ones made in the UK with production by Dave Edmunds and Jeff Lynne, he was increasingly unwell with alcoholism. He finally got sober in 1978, and managed to have a fluke hit in 1981 with a cover version of Phil Phillips' "Sea of Love", produced by Tom Petty and with Petty's band the Heartbreakers backing him: [Excerpt: Del Shannon, "Sea of Love"] He also came to people's attention when a rerecorded version of "Runaway" with new lyrics was used as the theme for the TV show Crime Story. In 1989, Del Shannon was working on a comeback album, with Jeff Lynne producing and members of Tom Petty and the Heartbreakers as backing musicians. The same people had previously worked on Roy Orbison's last album, which had been his biggest success in decades, and Lynne was gaining a reputation for resuscitating the careers of older musicians. Both Lynne and Petty were fans of Shannon and had worked with him previously, and it seemed likely that he might be able to have a hit with some of the material he was working on. Certainly "Walk Away", which Shannon co-wrote with Lynne and Petty, sounds like the kind of thing that was getting radio play around that time: [Excerpt: Del Shannon, "Walk Away"] There were even rumours that Lynne and Petty were thinking of inviting Shannon to join the Travelling Wilburys to replace Roy Orbison, though that seems unlikely to me. Unfortunately, by the time the album came out, Shannon was dead. He'd been suffering from depression for decades, and he died of suicide in early 1990, aged fifty-five. His widow later sued the manufacturers of the new wonder drug, Prozac, which he'd been prescribed a couple of weeks earlier, claiming that it caused his death. Max Crook, meanwhile, had become a firefighter and burglar alarm installer, while also pursuing a low-key career in music, mostly making religious music. When Shannon was posthumously inducted into the Rock and Roll Hall of Fame, Crook volunteered to perform at the ceremony, playing his original Musitron, but his offer was ignored. In later years he would regularly show up at annual celebrations of Shannon, and talk about the music they made together, and play for their fans. He died on July the first this year, aged eighty-three.

Sponsored by Datadog: pythonbytes.fm/datadog Michael #1: PSF / JetBrains Survey via Jose Nario Let’s talk results: 84% of people who use Python do so as their primary language [unchanged] Other languages: JavaScript (down), Bash (down), HTML (down), C++ (down) Web vs Data Science languages: More C++ / Java / R / C# on Data Science side More SQL / JavaScript / HTML Why do you mainly use Python? 58% work and personal What do you use Python for? Average answers was 3.9 Data analysis [59% / 59% — now vs. last year] Web Development [51% / 55%] ML [40% / 39%] DevOps [39% / 43%] What do you use Python for the most? Web [28% / 29%] Data analysis [18% / 17%] Machine Learning [13% / 11%] Python 3 vs Python 2: 90% Python 3, 10% Python 2 Widest disparity of versions (pro 3) is in data science. Web Frameworks: Flask [48%] Django [44%] Data Science NumPy 63% Pandas 55% Matplotlib 46% Testing pytest 49% unittest 30% none 34% Cloud AWS 55% Google 33% DigitalOcean 22% Heroku 20% Azure 19% How do you run code in the cloud (in the production environment) Containers 47% VMs 46% PAAS 25% Editors PyCharm 33% VS Code 24% Vim 9% tool use version control 90% write tests 80% code linting 80% use type hints 65% code coverage 52% Brian #2: Hypermodern Python Claudio Jolowicz, @cjolowicz An opinionated and fun tour of Python development practices. Chapter 1: Setup Setup a project with pyenv and Poetry, src layout, virtual environments, dependency management, click for CLI, using requests for a REST API. Chapter 2: Testing Unit testing with pytest, using coverage.py, nox for automation, pytest-mock. Plus refactoring, handling exceptions, fakes, end-to-end testing opinions. Chapter 3: Linting Flake8, Black, import-order, bugbear, bandit, Safety. Plus more on managing dependencies, and using pre-commit for git hooks. Chapter 4: Typing mypy and pytype, adding annotations, data validation with Desert & Marshmallow, Typeguard, flake8-annotations, adding checks to test suite Chapter 5: Documentation docstrings, linting docstrings, docstrings in nox sessions and test suites, darglint, xdoctest, Sphinx, reStructuredText, and autodoc Chapter 6: CI/CD CI with GithHub Actions, reporting coverage with Codecov, uploading to PyPI, Release Drafter for release documentation, single-sourcing the package version, using TestPyPI, docs on RTD The series is worth it even for just the artwork. Lots of fun tools to try, lots to learn. Michael #3: Open AI Jukebox via Dan Bader Listen to the songs under “Curated samples.” A neural net that generates music, including rudimentary singing, as raw audio in a variety of genres and artist styles. Code is available on github. Dataset: To train this model, we crawled the web to curate a new dataset of 1.2 million songs (600,000 of which are in English), paired with the corresponding lyrics and metadata from LyricWiki. The top-level transformer is trained on the task of predicting compressed audio tokens. We can provide additional information, such as the artist and genre for each song. Two advantages: first, it reduces the entropy of the audio prediction, so the model is able to achieve better quality in any particular style; second, at generation time, we are able to steer the model to generate in a style of our choosing. Brian #4: The Curious Case of Python's Context Manager Redowan Delowar, @rednafi A quick tour of context managers that goes deeper than most introducitons. Writing custom context managers with __init__, __enter__, __exit__. Using the decorator contextlib.contextmanager Then it gets even more fun Context managers as decorators Nesting contexts within one with statement. Combining context managers into new ones Examples Context managers for SQLAlchemy sessions Context managers for exception handling Persistent parameters across http requests Michael #5: nbstripout via Clément Robert In the latest episode, you praised NBDev for having a git hook that strips out notebook outputs. strip output from Jupyter and IPython notebooks Opens a notebook, strips its output, and writes the outputless version to the original file. Useful mainly as a git filter or pre-commit hook for users who don’t want to track output in VCS. This does mostly the same thing as the Clear All Output command in the notebook UI. Has a nice youtube tutorial right in the pypi listing Just do nbstripout --``install in a git repo! Brian #6: Write ups for The 2020 Python Language Summit Guido talked about this in episode 179 But these write-ups are excellent and really interesting. Should All Strings Become f-strings?, Eric V. Smith Replacing CPython’s Parser with a PEG-based parser, Pablo Galindo, Lysandros Nikolaou, Guido van Rossum A Formal Specification for the (C)Python Virtual Machine, Mark Shannon HPy: a Future-Proof Way of Extending Python?, Antonio Cuni CPython Documentation: The Next 5 Years, Carol Willing, Ned Batchelder Lightning talks (pre-selected) What do you need from pip, PyPI, and packaging?, Sumana Harihareswara A Retrospective on My "Multi-Core Python" Project, Eric Snow The Path Forward for Typing, Guido van Rossum Property-Based Testing for Python Builtins and the Standard Library, Zac Hatfield-Dodds Core Workflow Updates, Mariatta Wijaya CPython on Mobile Platforms, Russell Keith-Magee Wanted to bring this up because Python is a living language and it’s important to pay attention and get involved, or at least pay attention to where Python might be going. Also, another way to get involved is to become a member of the PSF board of directors What’s a PSF board of directors member do? video There are some open seats, Nominations are open until May 31 Extras: Michael: Updated search engine for better result ranking Windel Bouwman wrote a nice little script for speedscope https://github.com/windelbouwman/pyspeedscope (follow up from Austin profiler) Jokes: “Due to social distancing, I wonder how many projects are migrating to UDP and away from TLS to avoid all the handshakes?” - From Sviatoslav Sydorenko “A chef and a vagrant walk into a bar. Within a few seconds, it was identical to the last bar they went to.” - From Benjamin Jones, crediting @lufcraft Understanding both of these jokes is left as an exercise for the reader.

Mark and his wife Shannon are the World’s Leading Authority on the “Business of Speaking,” helping their clients land some of the most coveted stages and media including The View, Tony Robinns, CNN, Brendon Burchard, Good Morning America, and TED Talks worldwide. They specifically help Speakers, Experts, and Politicians create a movement and monetize their message. And they’re known for getting RESULTS... their Signature “Speak Your Path to Cash” System has helped their Tribe generate close to $20 million dollars! Prior to launching Big Impact Inc, Mark produced some of the biggest brands in the world including Porsche, Harley Davidson, AFLAC, and Marriott. He has over 20 years of experience studying and teaching “A Course in Miracles” and is passionate to show audiences how to bring more Spirituality into their Business, where miracles happen every day. Together, Mark & Shannon have created the “Big Impact Tribe” of Experts, Speakers, and Politicians who are changing the world... one speech at a time. You can learn more about Mark at:  www.MyBigImpact.com ***** Mark has been so generous to contribute a free gift to our “Leading with Light” Cosmic Treasure Box.   You can get your  FREE “Speaker Success Blueprint” today at MyBigImpact.com/Sky . “Leading with Light”, a divinely inspired podcast, is a wellspring for transformational leaders of today to fill up and align, to gather and be inspired, to create their visions in the world, leading with their light!  Join Your Hostess, Sky A’Hearn, Visionary Light Leader Extraordinaire, in the spirit of Deepak Chopra, Abraham-Hicks, Eckhart Tolle, Vianna Stibal, and an alternative to Bruce Lipton, Don Miguel Ruiz, Dr. Joe Dispenza, & Gregg Braden in leading with your light!    One person in alignment, is stronger than millions out of alignment! When we lead with our light, our true essence, our pure alignment, each moment of each day we inevitably step into leadership, change lives and make this world a better place.   Join Sky as she speaks with transformational leaders of today finding out what inspires them to lead with their light, helps bring them into alignment and makes their dreams come true!    Sign up for your “Ignite Your Limitless Money Magic!” Exploration Session with Sky! Today. And don’t forget to subscribe to "Leading with Light" so that you don't miss a single episode and join us in the "Leading with Light" Facebook Group, where "Sparkly Divine Lights Come to Play". While you're at it, won't you take a moment to write a short review and rate our show? It would be greatly appreciated! If you are a transformational leader and you would like to be interviewed by Sky, reach out at sky@skyislimitless.com. To learn more about our previous guests, listen to past episodes, and get to know your host, go to iTunes or to http://www.skyislimitless.com/  and follow us on Facebook      Twitter Instagram Pinterest Linkedin

Mark and his wife Shannon are the World’s Leading Authority on the “Business of Speaking,” helping their clients land some of the most coveted stages and media including The View, Tony Robinns, CNN, Brendon Burchard, Good Morning America, and TED Talks worldwide. They specifically help Speakers, Experts, and Politicians create a movement and monetize their message. And they’re known for getting RESULTS... their Signature “Speak Your Path to Cash” System has helped their Tribe generate close to $20 million dollars! Prior to launching Big Impact Inc, Mark produced some of the biggest brands in the world including Porsche, Harley Davidson, AFLAC, and Marriott. He has over 20 years of experience studying and teaching “A Course in Miracles” and is passionate to show audiences how to bring more Spirituality into their Business, where miracles happen every day. Together, Mark & Shannon have created the “Big Impact Tribe” of Experts, Speakers, and Politicians who are changing the world... one speech at a time. WEBSITE: You can learn more about Mark at:  www.MyBigImpact.com ***** Mark has been so generous to contribute a free gift to our “Leading with Light” Cosmic Treasure Box.   You can get your  FREE “Speaker Success Blueprint” today at MyBigImpact.com/Sky    “Leading with Light”, a divinely inspired podcast, is a wellspring for transformational leaders of today to fill up and align, to gather and be inspired, to create their visions in the world, leading with their light!  Join Your Hostess, Sky A’Hearn, Visionary Light Leader Extraordinaire, in the spirit of Deepak Chopra, Abraham-Hicks, Eckhart Tolle, Vianna Stibal, and an alternative to Bruce Lipton, Don Miguel Ruiz, Dr. Joe Dispenza, & Gregg Braden in leading with your light!    One person in alignment, is stronger than millions out of alignment! When we lead with our light, our true essence, our pure alignment, each moment of each day we inevitably step into leadership, change lives and make this world a better place.   Join Sky as she speaks with transformational leaders of today finding out what inspires them to lead with their light, helps bring them into alignment and makes their dreams come true!    Sign up for your “Ignite Your Limitless Money Magic!” Exploration Session with Sky! Today. And don’t forget to subscribe to "Leading with Light" so that you don't miss a single episode and join us in the "Leading with Light" Facebook Group, where "Sparkly Divine Lights Come to Play". While you're at it, won't you take a moment to write a short review and rate our show? It would be greatly appreciated! If you are a transformational leader and you would like to be interviewed by Sky, reach out at sky@skyislimitless.com. To learn more about our previous guests, listen to past episodes, and get to know your host, go to iTunes or to http://www.skyislimitless.com/  and follow us on Facebook      Twitter Instagram Pinterest Linkedin

“The goal is always going to be changing to something better” “You can make time if you really want to do something” “Do your own thing, you're the artist” --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/tpkpodcast/support

Today on Wealthy Wellthy Wise I interview Shannon and Mark Grainger. Mark & Shannon are the World’s Leading Authority on the “Business of Speaking,” helping their clients land some of the most coveted stages. They specifically help Speakers, Experts, and Politicians create a movement and monetize their message. They‘re famous for creating “Signature Talk Marketing” to help Speakers, Experts, and Coaches stop spinning their wheels with technology and get paid what they’re worth through the power of speaking. Together they successfully own and run My Big Impact and are what I’ve dubbed the “Couplepreneurs”. In this episode Shannon, Mark, and I talk about spirituality and money, and how to reconcile the two. We discuss spirituality quite a bit in this conversation and really dig into the meaning and power of words. Mark and Shannon have such a wide array of knowledge we discuss examples of topics ranging from handling household finances as a couple to gaining the confidence necessary to have a profitable business. Mark and Shannon emphasize public speaking, and why it is still the most powerful connection and message. If you’re a public speaker or anyone looking to get your voice heard be sure to listen to this conversation.   For show notes and more info: http://wealthywellthy.life/134 

The intertangled history of tile trends and Crossville is a long, fascinating journey. Mark Shannon, EVP of Sales, and Tim Curran, owner and CEO of of the Curran Group discuss tile in the interior design world.  --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/interiorsandsources/support

Transform Your Business Through Public Speaking!An Interview with Mark & Shannon In Episode 47 of the Market Your Business Like A Pro podcast with host Ken Countess, Ken interviews Mark & Shannon. From their bio - Mark & Shannon are the world’s leading authority on the “Business of Speaking,” helping their clients land some of the most coveted stages and media including The View, Tony Robbins, CNN, Brendon Burchard, Good Morning America and TEDTalks worldwide. They specifically help Speakers, Experts and Politicians create a movement and monetize their message. And they’re known for getting RESULTS… their Signature “Speak Your Path To Cash” System has helped their Tribe generate over $16 million dollars! They’re famous for creating “Signature Talk Marketing” to help Speakers, Experts and Coaches stop spinning their wheels with technology and get paid what they’re worth through the power of speaking. Prior to launching Big Impact Inc, Mark produced some of the biggest brands in the world including Porsche, Harley Davidson, AFLAC and Marriott. He has over 20 years’ experience studying and teaching “A Course in Miracles” and is passionate to show audiences how to bring more Spirituality into their Business, where miracles happen every day. Shannon successfully produced live events that generated over $500,000 in a weekend and established “The Golden Standard” of the speaking & seminar industry. She's shared the stage with “Chicken Soup for the Soul” Author Mark Victor Hansen, “Queen of Sales Conversion” Lisa Sasevich and Loral Langemeier who was featured in the movie “The Secret.” Together, Mark & Shannon have created the “Big Impact Tribe” of Experts, Speakers and Politicians who are changing the world... one speech at a time. They live in Austin, TX with their 2 huskies Mojo & Tootsie.  They enjoy ROCKIN out to live music at the Moody Theater, hikes in nature with the pooches and Bulletproof Coffee on Sunday mornings. Their website is http://markandshannonlive.com/

It's the third episode of the MLSMultiplex Podcast and your host Mark Shannon(@markshannon64) and David Hughes(@Davehughes64) are back!It was a great weekend of MLS Soccer.  Who would have thought Bastian Schweinsteiger would have scored 17-minutes into his debut?  How about those Columbus Crew?  They sit first in the Eastern Conference on 10 points and look unstoppable.  Erick "Cubo" Torres is on a roll and leads the league in goals scored this season.  It's another action packed weekend in MLS for week six action.#plexthis

 The Boys are back with another episode of the MLSMultiplex podcast.On this episode Mark Shannon(@markshannon64) and Dave Hughes(@Davehuges64) get into all the major stories from around the MLS.  They'll talk about Bastian Schweinsteiger again and Chicago Fire contributor Jaymes Grider(@FireEngine97) calls in to talk about the press conference and his expectations for Schweinsteiger.  They'll also get into the injuries to Sebastian Lletget, and Josef Martinez and what that means for their respective teams.  

The MLSMultiplex podcast is finally here!!!Mark Shannon and Dave Hughes give you the low down on everything going on around the MLS.  Chicago Fire Jaymes Grider (fireengie97) joins the episode to talk to us a little about the Chicago Fire and more.  They'll recap the previous weekends game and give you a preview of what lies ahead.  While also bringing you all the stats, and stories you need to hear from the MLS. 

Its out super awesome Crossover episode with our #1 Bitch Lauren's podcast, Death Rattle!Don't be alarmed by the different into, we just made Jack and Lauren do all our footwork this round. Creepy Kitch and Death Rattle (aka Death Kitchen) join forces on the second episode of Strip Nude for Your Podcast. First, the gang discusses Mario Bava’s The Whip and the Body (Italy 1963), starring Christopher Lee, Daliah Lavi, and an instrument of violence.  Next, Lauren and Jack’s friendship with Stac and Cins is put to the test when the gang sets sail to discuss Joe D’Amato and George Eastman’s P0rn0 Holocaust (Italy 1981) starring Eastman, Mark Shannon (aka Captain Warty Balls), Lucia Ramirez, Annj Goren, and some other people who probably contracted Mr. Shannon’s warts.  Will Stac find her own Christopher Lee staging casting calls for a dinner theater production of The Whip and the Body?  Will Cins fly to DC to beat Lauren and Jack for asking her to watch D’Amato’s island adventure?  Find out on Death Kitchen!!!

Kirsten, Alex, Mark Shannon, and Matt Ries talk about the Water-Energy Nexus.

Kirsten, Alex, Keith Casto, and Mark Shannon, and Matt Ries talk about water.