Python Namespaces
Vložit
- čas přidán 28. 08. 2024
- In this tutorial I look at how Python organizes it objects in Namespaces. In other words we are looking under the hood of Python to see the systems that helps avoid name conflicts.
Support my channel on Patreon: www.patreon.co...
I appreciate the time you must spend in making your videos, I'm making my way through all of them. I love your teaching style of continuous reinforcement; tell them, tell them what you told them, and tell them again...and when you next see them, tell them yet again. Best way to teach in my opinion; for me, certainly the best way to learn. Thanks again.
your contribution to teaching python is excellent
Thank you for your positive comments it is appreciated.
Best wishes Phil
Thank you so much sir
I hope your next video explains how to find and look at namespaces.
Yeap that is the next one to be uploaded sometime this week.
Regards
Phil
Much appreciated. Very clear. However no clear explanation on different namespaces
Thank you for your positive comments. I take note of your reference to not having examples of namespaces. You are correct I have not emphasised this in this video. However, I have referenced this and numerous other aspects of namespaces in other videos within the same playlist. I can recommend that you view the namespace videos at the following link:
www.pythonbytesize.com/12-python-namespaces.html
Best wishes Phil
hello dear John - overwhelming tutorial - very helpful. One question though can you put togehter the most important infos into a cheatsheet - a Summarizing Cheat Sheet to download would be fantastic.
above all - keep up the great work. It rocks!
Can you tell me which tool you used to make the presentation?
Details at the following link:
www.pythonbytesize.com/educators.html
Regards Phil
So 'name' would have done or 'nameobject', so where / what is the 'space' name/value pairs yep ok name/object pairs great what is NAMESPACE and where is it why does it even have to be mentioned, it's obvious that ANY programming language has to have a unique name to refer to anything, I would guess that even a beginner would totally see that if they say x = 7 and then x = 8 that they now can't access the 7, so surely that is 'implied' with ANY language that you have to use unique variable/object etc etc names to keep thing isolated, so what is the deal with what/where/how this is used / needed / needed , when writing a python program where do you type namespace if you declare a var z = 9, than z is stored ( i guess like you say in virtual dictionary somewhere ) and the programmer moves on, so why do those people creating this cryptic language bother to expose the total confusion that this brings when you don't actually use it, or do you, if how/where/when/why as every var you create HAS to be a different name that goes without saying, but as a the boffin language writers always seem to do do, if you make something complicated then why not, it makes us look like we are really thinking really deeply, why make it obvious if you don't need to, I think that defines python from what I am seeing so far in my quest to get some existing code ported. And from what I see looking out there there I feel an awful lot of folk that 'think' the have 'got it' but when put on the spot they may fumble, just like me.
So in summery What Where is namespace I get name but I dot get space but your nameobject may have been the better implementation of it.
I'll give another example of this idiotic invention, 'self' totally useless and could have been left out as that is also 'implied' from what is calling the called object knows who's calling and python i am reliably informed passes the caller automatically so WHY OH WHY do you need to use 'self' in this so called beginners easy to learn modern language, please don't think I am being in any way critical of yourself, thank you for trying to explain something that the writers of the language should have never have mad so damned cryptic to begin with. Many thks, and would most grateful to be put straight in the understanding of this weird language.
I can sense your frustration with this topic and it is understandable. I have taught object orientated programming for many years and a significant number of students express the same frustrations with the aspects you have outlined. My first language was machine code, then C followed by many other programming languages. It took me some months to get my head around object-oriented programming, but I persisted and I now code everything using the object-oriented paradigm. Although I teach more than one paradigm.
Let’s take x = 7. It is reasonable and acceptable to think of this as x storing the value 7 and you can code without concern as to what is under the bonnet of the programming language. Indeed, when coding an algorithm, I would recommend you went with this concept.
But it is not the case that x stores 7. x is an identifier that ‘holds the address of the location’ of the integer object (i.e. 7). That is x indicates where in memory you will find the value 7 (i.e. the object, the instance of the integer class). At first sight this seems like an unnecessary complication. Two things: firstly, once you get used to it, it is not that complicated. Secondly it is what happens with the language.
Every variable holds the address of the object it has been assigned. For example: my_string = “I am a string” the variable identifier (my_string) holds the address of the string object (“I am a string”).
Turning to the word self. Ask this question what would happen if you did not use self? Remember a class is a template on which objects are based. So a program can have many objects based on the same class. Every object has access to the methods and attributes of this class. Each object in effect has their own copy of what has been defined in the class. How can an object know which attributes and methods belong to it? The answer is the address of each object is stored in the variable identifier (in the same way as it was stored in x). Each object in affect has their own ‘self’ which holds this address. If self was not there an object identifier would not know where the object was. It is told where it is when the object is created.
This approach may seem unnecessary but I would persist because appreciating the object-oriented nature of the language will help when you get compile errors that do not seem to make any sense. Knowing a variable is an identifier holding an address of where the object is stored will certainly help with solving compile errors. It also greatly helps when considering parameter passing to functions/methods. Values are not passed but addresses are.
Hope this helps best wishes
Phil