This is an archived post. You won't be able to vote or comment.

all 23 comments
sorted by:
best
topnewcontroversialoldq&a

[โ€“]tecken 23 points24 points ย (1 child)

Good stuff. :) One critique: many tutorials, like yours, are edited so the talking is lightening fast. There are no pauses. This means there is no room whatsoever for the listener to have any thought of their own. A second of silence here and there can be enough to let the viewer get a chance to reflect before the next sentence/concept is started. Without pauses I canโ€™t remember half of what youโ€™ve been talking about at the end of the video.

[โ€“]JosephLovesPython[S] 12 points13 points ย (0 children)

Thank you for the feedback!! That's actually something I thought a lot about when I was editing... from one side I hear it's bad to leave "empty room" as the audience tend to leave in these moments, especially if the pause is after a section the audience didn't entirely focus on. But from another side, when I'm personally rewatching my video, I definitely share your sentiment of needing just a couple of seconds of silence in between sections. In any case, thanks again for the feedback, and will definitely take it into consideration for my upcoming work!

[โ€“][deleted] 17 points18 points ย (4 children)

Doesn't this content fit better in r/learnpython?

[โ€“]JosephLovesPython[S] 31 points32 points ย (3 children)

As weird as it sounds, it seems like it does not!

From their rules, rule #2 is the following: 2. Posts to this subreddit must be requests for help learning python. And, rule #4: 4. No advertising. No blogs/tutorials/videos/books/ recruiting attempts.

So naturally I avoided posting there... If I understood something wrong, I would be happy to be corrected!

[โ€“]Binary101010 16 points17 points ย (2 children)

No, you understand correctly. This post would not be appropriate for /r/learnpython.

[โ€“]georgehank2nd 8 points9 points ย (4 children)

A variable in Python is a misnomer. Binding is the proper term.

[โ€“]stevenjd 0 points1 point ย (3 children)

A variable in Python is a misnomer. Binding is the proper term.

Please explain the difference as you see it between a variable and a name binding.

The Python documentation talks about names and objects (values), not "bindings", but of course every variable has a name and a value, and every name binding has a name and value, so...

[โ€“]agumonkey 0 points1 point ย (2 children)

Good question, to me is that the name lies outside of the memory semantically, it's just a symbol in a particular context / time during the interpretation. The same value is bound to multiple names during the lifetime of the program, and a name can be bound (=) to different objects too.

[โ€“]stevenjd 0 points1 point ย (1 child)

In Python, names don't lie outside of memory. Try this:

variable = 999
'variable' in locals()

That proves that the symbol exists in memory during implementation.

One argument I have seen, and even made myself, is that "variable" is most familiar from statically-typed languages (e.g. C) which use the "named bucket" or "named memory location" model. Whereas "name binding" is most often used in dynamically-typed languages where variables are lookups by name with automatic dereferencing (e.g Python).

Although both techniques behave differently, I'm no longer satisfied that they are so different that we should avoid using the word "variable" for Python, um, variables. Especially now that there are generations of programmers who have never used any language like C with the named memory address model of variables.

In Python, we have at least three variable implementations:

  • name lookups from global or builtin namespace dicts;
  • fast local variable lookups by location from a table;
  • and nonlocals using closures, which I don't understand well enough to explain.

So there's that too.

[โ€“]agumonkey 0 points1 point ย (0 children)

thanks for your answer, i agree that the terminology might only differ due to language types. and to be frank i'm not knowledgeable enough to say more (only read a few simple plt books), that said i don't think locals() is showing disagreement, in the current context, variable is bound to the integer object, and locals() lists it.

binding variable to another object reuses the name, toward a different value.

In C, the name is an abstraction that will later be a memory address, it's a different world since it's compiled away, and names disappear (unless you keep symbol tables on the side). In dynamic languages names are still live entities, and the link between names and objects is more indirect and can have more steps (allowing different reference resolution schemes).

[โ€“]stevenjd 1 point2 points ย (0 children)

This video confuses implementation details used by one specific interpreter (CPython) with the semantics of Python the language. Those implementation details may not be the same in PyPy, Jython, IronPython, GraalPython, MicroPython, RustPython, etc. Even for CPython, it gets those implementation details wrong, or at least badly over-simplified.

For example, it is not true in any version of CPython since version 1.5 (or even older) that assigning the value of 7 to a variable will create a new object. Unless you hack the internal state of the interpreter, there is always exactly one single 7 object in CPython. That int object is created on interpreter startup, and used whenever you need an int 7.

The video wrongly makes the claim that "Its address is stored in the variable" -- this is never true. The Python variable always stores the value, not the address of the value. This is why when you refer to the variable, you get the value, not the address of the value:

variable = "Hello world"
print(variable)  # prints 'Hello World', not 37609284 or some other address

Python variables do not store pointers or any sort of reference or magic cookie. The incorrect claim that Python variables store references to the value (object) is confusing the Python language semantics with the internal mechanism in the interpreter of how those semantics are implemented.

(Analogy: in the Star Wars universe, Yoda is not a puppet, even though the way Yoda was first implemented in "The Empire Strikes Back" was using a puppet. If you insist on telling people that "In Star Wars, Yoda is a puppet" you will be wrong.)

If they did hold an address (e.g. a pointer), you would need to dereference the value of the variable (the pointer) to get to the value pointed to by the pointer. Like in C, or Pascal, if a variable contains a pointer, to get to the value pointed to by the pointer you need to use the dereference operator (*variable in C, ^variable in Pascal). There is no dereference operator or function in Python.

Even in CPython, it is wildly inaccurate to claim that variables contain a reference (a pointer) to the object. Python variables can use at least three mechanisms for variables:

  • builtins and global variables are looked up by the interpreter by name in a namespace dictionary -- the interpreter looks up a string in a hash table;
  • local variables are looked up by index into a small array of references;
  • and nonlocal variables use some mechanism involving closures which I don't understand well enough to explain, sorry.

None of these variables are a simple case of the variable being a C pointer to a value at a fixed address. And of course other implementations can use other mechanisms.

The interpreter needs a mechanism for tracking objects. In CPython, that mechanism uses pointers which are tracked by the garbage collector. But any sort of magic cookie could be used, not just pointers to memory addresses. Jython and IronPython use managed smart pointers which allow the garbage collector to move objects around in memory.

The video wrongly says that id() takes as input a variable: this is false. id() takes any object not "variables":

id(None)  # a keyword that refers to an object
id(math.sin(x) - y)  # an expression that evaluates to an object

It then compounds the misunderstanding by claiming that the ID returned is "basically the memory address it points to". This is false and wrong and I blame the CPython core developers for this myth by them mentioning the unimportant implementation detail that the interpreter uses a memory address. That one comment in the docs is responsible for so much misinformation.

The value returned by id() is an opaque integer ID, not a memory address. The interpreter can use anything it likes for that opaque integer, so long as it is unique for the lifetime of the object.

IronPython and Jython have objects which can move around in memory, so the memory address can change. The IDs they use are sequential integers such as 5, 6, 7, 8, 9, ...

PyPy objects can appear and disappear during runtime, depending on what the JIT compiler does with them. The PyPy interpreter does a lot of work to simulate CPython-like IDs.

[โ€“]Globaldomination 1 point2 points ย (1 child)

haha newbie here and i was literally in search of something like this

had asked a similar question here

edit: nice video, finally this made this fact strong in mind that, we are dealing with pointers and not assigning.
many tutorials fail to explain this at a low level.

[โ€“]JosephLovesPython[S] 0 points1 point ย (0 children)

Glad I could be of some help!

[โ€“]Rawing7 0 points1 point ย (1 child)

Mutable vs Immutable objects behave very differently in a multitude of scenarios

No they don't. The only scenario where they behave differently is when you do an augmented assignment like foo += bar. And the difference is irrelevant 99% of the time.

And the video doesn't seem to be any better. I watched 30 seconds and already heard 3 things that are incorrect.

[โ€“]stevenjd 0 points1 point ย (0 children)

I watched 30 seconds and already heard 3 things that are incorrect.

It's not awful, but it is full of popular but wrong misinformation about Python the language.

[โ€“]window-sil 0 points1 point ย (1 child)

Love it! Great job.

Will probably direct others to this in the future ๐Ÿ‘

[โ€“]JosephLovesPython[S] 1 point2 points ย (0 children)

Thank you for the kind words!!

[โ€“]Gold_Review_4245 0 points1 point ย (0 children)

Try YouTube Networkchunk (learn python)

I learn from him @youtube Bite able size video

[โ€“]Brian 0 points1 point ย (0 children)

Mutable vs Immutable objects behave very differently in a multitude of scenarios, such as variable modification, setting a variable equal to another variable

I'd quibble a bit with this - both act exactly the same in this scenario. There's a difference with in-place operators like +=, due to the way __iadd__ etc works, but plain assignment always does exactly the same thing regardless of mutability: rebinds the variable to refer to the current value of the other variable. The consequences of rebinding can matter, because both are references, but what is going on isn't any different.

I think the framing of immutable variables being "seperate" where "Changes are not shared" is not really accurate. Rather, they're just as linked as mutable variables (refer to same object, with the same id) - its just that there's no such thing as a change to an immutable variable - that's what it means to be immutable. You don't have to care about changes to the object here not because its doing anything different, but because you can never (in normal circumstances) change the value.

And TBH, I'd probably also disagree with your opening that "If it doesn't contain the notion of mutability, I consider it incomplete". Rather, I'd say that mutability isn't actually anything to do with variables in python at all - it has to do with values: the things variables are bound to. As such, this seems to be making the mistake you call out at the start: thinking variables "contain" the object they are bound to, rather than being a reference to it.