221–230 of 306 posts
Earlier quoted context omitted.
> I'd probably be happier if Python had (whether it was "is" or something else) a clean logical identity test operator. Isn't that what == is?
Somehow Python lets you distinguish “logically identical” things, though.
Earlier quoted context omitted.
Somehow Python lets you distinguish “logically identical” things, though.
If you're interested in properties other than logical identity, yes.
Earlier quoted context omitted.
> It violates the indiscernibility of identicals, which is one of the cornerstones of Western logic. Oh, please. Python isn't violating any principles of Western logic. It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. Python does this for some types but not for others. Yet computers manage to run Python just fine, Western logic notwithstandi…
> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value a…
As Rhett Butler said to Scarlett O'Hara, you gave a very good imitation.
> Different memory representations of the same value are okay. Branching on the difference is not.
Branching on a difference other than a difference in logical identity, if you are intending to test for logical identity, is obviously an error. The fix for that in Python is simple: if you want to test for logical identity, use the == operator.
Branching on a difference other than a difference in logical identity, if you're interested in a difference other than a difference in logical identity, is perfectly reasonable. Maybe you've never had occasion to do that in programs you write, but others might.
> I said that it should be a valid optimization
Consider my comment suitably modified. The rest of what I said still stands: there are tradeoffs involved, and reasonable people can differ on where the tradeoff ends up. You have one opinion; the Python developers have another. That doesn't mean the Python developers are violating Western logic.
> what I was claiming violates the indiscernibility of identicals is dragonwriter's explanation, not Python itself. A simple explanation that doesn't violate the indiscernibility of identicals is to admit that Python doesn't have compound values.
And to me this is a distinction without a difference. Nothing is stopping you from defining "compound values" so that a Python tuple isn't a compound value. But nothing is stopping the rest of us from not caring about your definition. Which, as you say, takes us back to square one.
What would be helpful is if you could give some reason why your definition of compound values is so important, other than talking about identity of indiscernibles and violating Western logic. What makes a language that allows compound values, by your definition, better than a language that doesn't? And if your only answer (other than preserving Western logic) is "better runtime efficiency" (less memory, faster operations), then it seems to me you would do much better to make that argument directly, instead of cloaking it with all this talk about "compound values". But maybe that's just me.
Earlier quoted context omitted.
If you're interested in properties other than logical identity, yes.
By definition identity checking is the finest-grained distinction you can make between things. If two things are identical, they can't possibly be different in any way. This is what philosophers call the “indiscernibility of identicals”, and, if it sounds like a tautology, it's because it is!
By your definition, perhaps. The rest of us don't always use the word "identity" with this meaning. And since you don't own the English language, you don't get to tell the rest of us how to use words.
> If two things are identical, they can't possibly be different in any way.
Then by your definition, two Python tuples (1, 2, 3) are not identical. Which says absolutely nothing about how I can write programs using them, or what concepts of "identity" the operators in those programs can implement.
> This is what philosophers call...
We're talking about programming here, not philosophy.
Earlier quoted context omitted.
> It's only violating your idiosyncratic insistence that there can only be one in-memory representation of any immutable value. I never said this! There can be multiple representations of the same value. For example, the same ordered set may be represented as two distinct red-black trees, balanced differently. Values are different from their memory representations. Different memory representations of the same value a…
> I never said this! As Rhett Butler said to Scarlett O'Hara, you gave a very good imitation. > Different memory representations of the same value are okay. Branching on the difference is not. Branching on a difference other than a difference in logical identity, if you are intending to test for logical identity, is obviously an error. The fix for that in Python is simple: if you want to test for logical identity, us…
It's unreasonable to have a finer-grained distinction than logical identity. If two things are the same, they are the same. If they are not, well, they are not. Again, tautologies!
> That doesn't mean the Python developers are violating Western logic.
I never said Python developers are violating Western logic. I said dragonwriter's explanation of how so-called “compound values” work in Python is inconsistent with Western logic. I have an explanation of how Python works that's consistent with it, but it requires rejecting the assumption that Python has compound values.
> Nothing is stopping you from defining "compound values" so that a Python tuple isn't a compound value.
The definition of compound value is simple: a value that you can tear apart into its constituent parts, then reassemble, getting the original value. You can't get the original tuple object by creating a new tuple object with the original tuple's components. The `is` operator will brush the difference on your face.
> What makes a language that allows compound values, by your definition, better than a language that doesn't?
The easiest way to reason about programs that's completely rigorous (i.e., not just testing on a couple sample inputs) is equational reasoning, which is basically showing that two syntactically different expressions evaluate to the same value. (For example, one expression might be an obviously correct but unacceptably inefficient program, and the other expression might be the program you actually intend to deliver.) In practice, realistic problem domain have to be modeled using compound entities (values or objects), so if you want to use equational reasoning, you need compound values.
Earlier quoted context omitted.
By definition identity checking is the finest-grained distinction you can make between things. If two things are identical, they can't possibly be different in any way. This is what philosophers call the “indiscernibility of identicals”, and, if it sounds like a tautology, it's because it is!
> By definition identity checking is the finest-grained distinction you can make between things By your definition, perhaps. The rest of us don't always use the word "identity" with this meaning. And since you don't own the English language, you don't get to tell the rest of us how to use words. > If two things are identical, they can't possibly be different in any way. Then by your definition, two Python tuples (1,…
I can write a program that treats all Python objects identically, by simply doing nothing. That doesn't make all Python objects actually identical.
> We're talking about programming here, not philosophy.
Programming is applied logic, which is a branch of philosophy.
> I know that it's now en vogue to sneer at OO
I don't sneer at it. OO has been the dominant coding religion for most of my career and I rage against the educators and propagandists who spend a decade smothering everyone with it. I curse them for all the time I wasted trying to build classes for my data only to realize that if I had used a simple dictionary or list my code would be shorter, simpler, more robust, and more flexible.
The logic in the article above is all premised on object-oriented religion. OO for OO's sake because OO. Using the power of dictionaries is bad, using the power of objects is good.
> It completely defeats object orientation.
You could just as easily say using objects defeats the point of having lists and dicts.
> It offers nothing of the abstraction powers of object orientation.
Most of the abstraction power of object orientation happens when you create the methods. If you aren't defining new classes, you write functions instead. You still have abstractions, what you don't have is the encapsulation of code with data.
> It doesn't say what it's doing.
Sure it does, and better yet since you are using the standard data types it will be said in a language that any other Python developer is likely understand immediately.
> The above code is filled with auxiliary logic that has nothing to do with what it actually tries to achieve.
The above code is filled with auxiliary logic because the author of it apparently didn't write any useful functions for operating on dictionaries.
I'm not sure that any of the auxiliary logic in that code has anything to do with the choice to use dictionaries. It's a standard data munging problem that comes from having data from different sources. You have the exact same problem with objects if you didn't write any useful methods for operating on them.
> but done right, it can be very powerful, especially in big and complex codebases.
And in my opinion, the right way to do Object-Orientation in Python is to not do it until you really know you need it: your code is heading towards big and complex and you need to lock it down and organize the data and methods into well-encapsulated classes. (Although maybe at that point you realize it's not a big deal and don't bother)
Designing around lists and dicts from the start is a much more flexible strategy than trying to get all the encapsulation exactly right on the first try. If you don't have lots of time to spend up front UML'ing an object heirarchy for your big, complex application, you're probably better off sketching and iterating with JSON in mind (and yaml if humans need to edit it). As your application takes shape, it will become apparent where it makes sense to lock down functions and data into objects.
This is especially true given that all of Python's standard types are inheritable classes.
Earlier quoted context omitted.
If you're interested in properties other than logical identity, yes.
By definition identity checking is the finest-grained distinction you can make between things. If two things are identical, they can't possibly be different in any way. This is what philosophers call the “indiscernibility of identicals”, and, if it sounds like a tautology, it's because it is!
Yes, but there are different identities. "is" implements storage identity checking between python objects (a term broader than the sense in which you use "objects", which includes both what you call "objects" and representations of values).
Logical identity checking between Python values (as well as object equivalence, but not identity, checking between Python "objects" in the sense you use the term) is done by "==".
For most python value representations, the relationship between storage identity of the representation and logical identity of the value is undefined.
Earlier quoted context omitted.
> By definition identity checking is the finest-grained distinction you can make between things By your definition, perhaps. The rest of us don't always use the word "identity" with this meaning. And since you don't own the English language, you don't get to tell the rest of us how to use words. > If two things are identical, they can't possibly be different in any way. Then by your definition, two Python tuples (1,…
> Which says absolutely nothing about how I can write programs using them, I can write a program that treats all Python objects identically, by simply doing nothing. That doesn't make all Python objects actually identical. > We're talking about programming here, not philosophy. Programming is applied logic, which is a branch of philosophy.
Yes, you can. Thank you for proving my point that Python programs don't have to use your definition of identity.
But that's a silly example. Here's an example that's not silly: in an earlier discussion you said dictionary keys have to be values--which would imply that dictionary key lookup must use your concept of "identity", so only two objects that are identical by your definition will behave as identical keys in a dictionary. But two distinct Python tuples (1, 2, 3), which are not identical by your definition, do behave as identical keys in a Python dictionary. In other words, Python dictionary key lookup does not use your concept of "identity".
To everyone else, this means your concept of identity is simply not relevant. To you, it appears to mean that Python is violating Western logic.
> Programming is applied logic, which is a branch of philosophy.
To you, perhaps. Not to me. And not, I suspect, to most of the other programmers in this discussion.
Earlier quoted context omitted.
By definition identity checking is the finest-grained distinction you can make between things. If two things are identical, they can't possibly be different in any way. This is what philosophers call the “indiscernibility of identicals”, and, if it sounds like a tautology, it's because it is!
> By definition identity checking is the finest-grained distinction you can make between things. Yes, but there are different identities. "is" implements storage identity checking between python objects (a term broader than the sense in which you use "objects", which includes both what you call "objects" and representations of values). Logical identity checking between Python values (as well as object equivalence, bu…
This is exactly what I'm saying is wrong: branching on the representations of values.
> For most python value representations, the relationship between storage identity of the representation and logical identity of the value is undefined.
If it's undefined, then how come I can query it?