Stephen J. Turnbull wrote:
> Worse, running the same program again with the *same* set can change
> which element is first, I believe.

Yes, this is correct. For example, if you had a minimal Python file named "some_set.py" with only the following:

```
s = set('abcdefg')
```

and then run something like this "import some_set; print(list(some_set.s))" the order of the elements will be randomized each time. Within each individual interpreter, the order will not change though (including if you del and then import some_set again):

```
[aeros:~]$ python -c "import some_set; print(list(some_set.s)); print(list(some_set.s))"
['f', 'a', 'c', 'g', 'b', 'd', 'e']
['f', 'a', 'c', 'g', 'b', 'd', 'e']
[aeros:~]$ python -c "import some_set; print(list(some_set.s)); print(list(some_set.s))"
['a', 'd', 'f', 'b', 'e', 'g', 'c']
['a', 'd', 'f', 'b', 'e', 'g', 'c']
[aeros:~]$ python -c "import some_set; print(list(some_set.s)); del some_set; import some_set; print(list(some_set.s))"
['f', 'b', 'g', 'e', 'c', 'a', 'd']
['f', 'b', 'g', 'e', 'c', 'a', 'd']
[aeros:~]$ python -c "import some_set; print(list(some_set.s)); del some_set; import some_set; print(list(some_set.s))"                  
['c', 'e', 'a', 'f', 'g', 'b', 'd']
['c', 'e', 'a', 'f', 'g', 'b', 'd']
```

IIUC, the "ordering seed" for all sets is randomly determined when the interpreter is first created, and remains the same throughout its lifespan. I'm not 100% certain that it's interpreter dependent, but it seems like it would be.

Personally, I don't think this makes `first()` any worse off though. I think it should be expected that attempting to extract the "first" element from an unordered container would not consistently return same one.

On Wed, Dec 11, 2019 at 8:25 PM Stephen J. Turnbull <turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:
Chris Angelico writes:

 > And ordered vs unordered is also a big difference. Should first()
 > raise an error with sets because there's no real concept of "the first
 > element"?

Probably not.  I would prefer that it not be implemented at all, but
if it is implemented, its behavior should respect the intuition of the
majority of those who want it, which seems to me to be "a variant of
next() that doesn't raise and returns None by default on an empty
iterable."

 > With a list, first(x) will remain the same value even if you add
 > more to the end of the list, but unrelated mutations to a set might
 > change which element is "first".

Worse, running the same program again with the *same* set can change
which element is first, I believe.  Also, the elements of the set
might have a natural (pre)order, which first() won't respect.  I'm not
sure if this last is a real problem, given that sequences have the
same issue (the sequence's order differs from the natural order).
However, to me the fact that a set's iteration order is implicit while
a sequence's is explicit suggests it might in some contexts.

 > Does that mean that first() and next() are undefined for sets?

first() is undefined.  next() is defined by reference to iterating
over the set (that's why I don't have a problem with iterating over a
set).

 > No. We just accept that there are these differences.

Well, if first() is implemented, we'll have to accept it.  It's not
clear to me that we should.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-leave@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7722U6NFSGKEFVFZM6SCXB246AAS6ETN/
Code of Conduct: http://python.org/psf/codeofconduct/