list comprehension problem

[alex23]

Terry Reedy <tjre... at udel.edu> wrote:
> alex23 wrote:
> > You're completely wrong. Immutability has nothing to do with identity,
> > which is what 'is' is testing for:
>
> What immutability has to do with identity is that 'two' immutable
> objects with the same value *may* actually be the same object,
> *depending on the particular version of a particular implementation*.

See, I prefer a little more certainty in my code. Isn't this why we
continually caution people against relying on implementation details?

> >>>> t1 is t2
> > False
> In this case, but it could have been True.

Yes, and if my aunt had a penis she'd be my uncle. But she doesn't. So
what's the point here? Under certain implementations, _some_ immutable
objects _may_ share identity, but you shouldn't rely on it? Are you
trying to advocate a use for this behaviour by highlighting it?

I'm honestly not getting your point here.

> > MRAB was refering to the singleton pattern[1], of which None is the
> > predominant example in Python. None is _always_ None, as it's always
> > the same object.
>
> And in 3.x, the same is true of True and False.

None of which refutes or lessens anything I wrote. What my post was
_countering_ was the claim that immutables should use identity checks,
mutables should use equality checks. That the implementation caches
_some_ objects for performance reasons certainly doesn't make that
claim any less wrong.

Again, what was the point of this other than "things differ on the
implementation level"? Isn't it better to talk about the level of the
language that you can _expect_ to be consistent?