In higher-level languages like Python we have the luxury of not worrying about managing memory ourselves- Python takes care of it for us. But what actually happens when we’re done with objects we’re no longer using? Will Python quietly get rid of it while we’re not looking? And how does it know what to delete?
I’ve been musing in my last few posts on the ways in which Python places objects at certain memory addresses, and if you assign a variable to that object you’re really just creating a pointer to a particular memory address where it finds that object…
Well… it might. And should you intern your strings? …maybe.
As a quick recap: interning is the process whereby Python will instantiate only one of an object, making it a singleton object that exists only once in your program, at one place in memory. It does this with the numbers -5 to 256 inclusive on initialisation, so that there is for example only one object at one place in memory in your entire program that represents the integer
Following on from my last post about objects being stored in memory addresses, one thing that blew my mind a little when I first discovered it is that not only are
None objects just like any other in Python, but they are singleton objects. That is to say that they exist only once and at one point in memory for the entire existence of your program. Every time your function returns
True, it’s returning the very same object that pops up every other time you see
True. You can’t initialise a second, different
True object anywhere else…
One thing I’ve found really helpful as I’ve got to know Python better is to understand the way it assigns objects to memory addresses. This is ultimately pretty simple, but in my opinion it’s the best way to understand variable assignment and the equality operators.
One of the earliest things you’re often told about Python is that everything is an object. Everything. Each and every string, number, list, dictionary, class, function, the boolean objects
False, and the
None object. …
Hi, been a while! At the suggestion of a colleague, I’m rebooting this blog again. Over the last year writing Python I’ve built a reasonable cache of notes of interesting things I’ve discovered and made a note of for future reference. In the coming weeks I’m going to be sharing some of these up here as they take my fancy. Feel free to get in touch with your thoughts or suggestions!
First up, just today I’d written what I thought was a snazzy little piece of validation in the
POST endpoint of one of our APIs, to check whether the…
Let’s face it, coding has undergone a bit of an image shift in the last decade or so, and it’s gotten decidedly sexy. It’s gone from just being ‘something in computers’ (as a coder’s aged relatives might airily describe them) to something that increasingly raises eyebrows in interest. We hear more and more that children should to be taught to code from an early age, or that it’s an essential life skill on a par with learning to drive. We even hear that programmers are ushering in an age of widespread automation, and with it, mass leisure or redundancy (a…