When convert two sets with the same elements to lists, are the lists always going to be the same?

[Peng Yu]

On Fri, May 4, 2012 at 6:12 PM, Cameron Simpson <cs at zip.com.au> wrote:
> On 04May2012 15:08, Peng Yu <pengyu.ut at gmail.com> wrote:
> | On Fri, May 4, 2012 at 12:43 PM, Terry Reedy <tjreedy at udel.edu> wrote:
> | > On 5/4/2012 8:00 AM, Peng Yu wrote:
> | >> On Fri, May 4, 2012 at 6:21 AM, Chris Angelico<rosuav at gmail.com>  wrote:
> | >>> On Fri, May 4, 2012 at 8:14 PM, Peng Yu<pengyu.ut at gmail.com>  wrote:
> | >>>> Thanks. This is what I'm looking for. I think that this should be
> | >>>> added to the python document as a manifestation (but nonnormalized) of
> | >>>> what "A set object is an unordered collection of distinct hashable
> | >>>> objects" means.
> | >>>
> | >>> There are other things that can prove it to be unordered, too; the
> | >>> exact pattern and order of additions and deletions can affect the
> | >>> iteration order. The only thing you can be sure of is that you can't
> | >>> be sure of it.
> | >>
> | >> I agree. My point was just to suggest adding more explanations on the
> | >> details in the manual.
> | >
> | > I am not sure how much clearer we can be in the language manual. The word
> | > 'unordered' means just that. [...]
> |
> | You can just add the example that you posted to demonstrate what the
> | unordered means. A curious user might want to know under what
> | condition the "unorderness" can affect the results, because for
> | trivial examples (like the following), it does seem that there is some
> | orderness in a set.
>
> I'm with Terry here: anything else in the line you suggest would
> complicate things for the reader, and potentially mislead.
>
> Future implementation changes (and, indeed, _other_ implementations like
> Jython) can change any of this. So there _are_ no ``condition the
> "unorderness" can affect the results'': a set is unordered, and you
> could even _legitimately_ get different orders from the same set
> if you iterate over it twice. It is unlikely, but permissable.
>
> Any attempt to describe such conditions beyond "it might happen at any
> time" would be misleading.
>
> | set(['a', 'b', 'c'])
> | set(['c', 'b', 'a'])
>
> The language does not say these will get the same iteration order. It
> happens that the Python you're using, today, does that.
>
> You can't learn the language specification from watching behaviour;
> you learn the guarrenteed behaviour -- what you may rely on happening --
> from the specification, and you can test that an implementation obeys (or
> at any rate, does not disobey) the specification by watching behaviour.
>
> You seem to be trying to learn the spec from behaviour.

My point is if something is said in the document, it is better to be
substantiated by an example. I don't think that this has anything with
"learn the spec from behaviour."

-- 
Regards,
Peng