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 <
[email protected]> 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 -- [email protected]
> To unsubscribe send an email to [email protected]
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/[email protected]/message/7722U6NFSGKEFVFZM6SCXB246AAS6ETN/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/XHCEOUSKMYHAFJC7UF2NMPXFGZ3JT7FW/
Code of Conduct: http://python.org/psf/codeofconduct/
