> Attempting to define value here would be at best a massive > distraction from the concepts the documentation is trying > to get across.
> There is one very simple definition of "value" which is entirely > accurate, but probably not helpful, and that is: An object's > value is whatever it is equal to. > Generally, Python objects have their values defined by an abstract > concept that is being represented. That confirms my intuition. Thank you for the responses. Sincerely, Iwo Herka pon., 19 lis 2018 o 20:46 Chris Angelico <ros...@gmail.com> napisał(a): > > On Tue, Nov 20, 2018 at 3:08 AM Iwo Herka <iwohe...@gmail.com> wrote: > > > > Hello everyone, > > > > I've been looking for something in the documentation > > (https://docs.python.org/3.8/reference/datamodel.html) recently > > and I've noticed something weird. Documentation states that every > > object has a value, but doesn’t provide any definition > > whatsoever of what the value is. Now, I'm sure that every reasonably > > fluent Python programmer has an intuitive > > understanding of the term, nonetheless, I would expect the > > documentation defines it somehow (not necessarily > > in a formal fashion), especially considering that "the value of an > > object" is used to explain other concepts, such as > > mutability: > > > > > The value of some objects can change. Objects whose value can change are > > > said to be mutable; objects whose > > value is unchangeable once they are created are called immutable. > > > > So, why is documentation silent on this? One reason I can think of is > > to avoid answering inconvenient questions. > > Sorta kinda, yeah. There is one very simple definition of "value" > which is entirely accurate, but probably not helpful, and that is: An > object's value is whatever it is equal to. That is to say, you can ask > two basic questions about an object: > > x is y # identity: are x and y the SAME object? > x == y # equality: do x and y have the same value? > > Value and equality are intrinsically linked, but unfortunately that > doesn't really explain what either one actually IS. As Rhodri says, > you can ask a philosopher about that, and will be stuck for weeks :) > > The concept of "immutable" vs "mutable" object, therefore, is that > some objects may compare equal now and unequal later. Since the same > object is able to change in "value" over time, it may become (un)equal > to something while still being the same object. Thus mutable objects > can't be used as dict keys, as their values could change, and dict > lookups have to match based on equality. (Imagine putting two keys > into a dict while they have different values, and then mutating one of > them to have the same value. Now try to look up that new value using a > third object. The Logic Police will arrest you before you can say > "hashability"!) > > Generally, Python objects have their values defined by an abstract > concept that is being represented. For instance, the integer 32 and > the float 32.0 have the same value, even though they're different > types; they both represent the abstract number equal to > two-to-the-fifth. But right here in that sentence, you can see how > hard it is to actually *define* that value. At best, all you can > really say is that the value is equal to the value of int("32") or > some other way of getting an object with that value. > > Yep, it's hard. But the cool thing is, it usually doesn't matter - you > can say "x has the value 32" without worrying about representations, > data types, etc. > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
