Indicate if an iterable is ordered or not

Iterables are not necessarily ordered (e.g. dict vs. OrderedDict). Sequences are but Sets aren't. I'm not aware of any good way currently to know if an arbitrary iterable is ordered. Without an explicit indicator of ordered-ness, you must know in advance for each specific type. One possible solution is an __isordered__ attribute (on the class), set to a boolean. The absence of the attribute would imply False. Such an attribute would be added to existing types: * collections.abc.Iterable (default: False) * list (True) * tuple (True) * set (False) * dict (False) * collections.OrderedDict (True) * ... Thoughts? -eric

What do you want to do with this knowledge? On Tue, Sep 24, 2013 at 9:15 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
Iterables are not necessarily ordered (e.g. dict vs. OrderedDict). Sequences are but Sets aren't. I'm not aware of any good way currently to know if an arbitrary iterable is ordered. Without an explicit indicator of ordered-ness, you must know in advance for each specific type.
One possible solution is an __isordered__ attribute (on the class), set to a boolean. The absence of the attribute would imply False.
Such an attribute would be added to existing types:
* collections.abc.Iterable (default: False) * list (True) * tuple (True) * set (False) * dict (False) * collections.OrderedDict (True) * ...
Thoughts?
-eric _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido)

On Tue, Sep 24, 2013 at 10:22 AM, Guido van Rossum <guido@python.org> wrote:
What do you want to do with this knowledge?
At this point, nothing. :) I realized while writing the message that my use case was not helped by knowing whether or not the iterable is ordered. I sent the message anyway because it does seem like there's a gap--just not one that perhaps anyone cares about. <wink> -eric

On Tue, Sep 24, 2013 at 4:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Tue, Sep 24, 2013 at 10:22 AM, Guido van Rossum <guido@python.org> wrote:
What do you want to do with this knowledge?
At this point, nothing. :) I realized while writing the message that my use case was not helped by knowing whether or not the iterable is ordered. I sent the message anyway because it does seem like there's a gap--just not one that perhaps anyone cares about. <wink>
-eric
-- --Guido van Rossum (python.org/~guido)

On Tue, Sep 24, 2013 at 4:01 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Sep 24, 2013 at 4:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Tue, Sep 24, 2013 at 10:22 AM, Guido van Rossum <guido@python.org> wrote:
What do you want to do with this knowledge?
At this point, nothing. :) I realized while writing the message that my use case was not helped by knowing whether or not the iterable is ordered. I sent the message anyway because it does seem like there's a gap--just not one that perhaps anyone cares about. <wink>
To the contrary, I say there is no gap and there is nothing to gain by adding the proposed API. [Sorry for the blank reply earlier.] -- --Guido van Rossum (python.org/~guido)

I suppose you could support some subset of slice/index operations, with some serious limitations… On Sep 24, 2013, at 4:01 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Sep 24, 2013 at 4:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Tue, Sep 24, 2013 at 10:22 AM, Guido van Rossum <guido@python.org> wrote:
What do you want to do with this knowledge?
At this point, nothing. :) I realized while writing the message that my use case was not helped by knowing whether or not the iterable is ordered. I sent the message anyway because it does seem like there's a gap--just not one that perhaps anyone cares about. <wink>
-eric
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

On 25 Sep 2013 02:24, "Guido van Rossum" <guido@python.org> wrote:
What do you want to do with this knowledge?
My reaction is the same as Guido's. There's already an implicit expectation that iterables will be *consistent* in the absence of mutation (i.e. arbitrarily ordered rather than unordered), but I don't see how "ordered based on container internal details" is meaningfully different from "ordered by some external criterion". Cheers, Nick.
On Tue, Sep 24, 2013 at 9:15 AM, Eric Snow <ericsnowcurrently@gmail.com>
wrote:
Iterables are not necessarily ordered (e.g. dict vs. OrderedDict). Sequences are but Sets aren't. I'm not aware of any good way currently to know if an arbitrary iterable is ordered. Without an explicit indicator of ordered-ness, you must know in advance for each specific type.
One possible solution is an __isordered__ attribute (on the class), set to a boolean. The absence of the attribute would imply False.
Such an attribute would be added to existing types:
* collections.abc.Iterable (default: False) * list (True) * tuple (True) * set (False) * dict (False) * collections.OrderedDict (True) * ...
Thoughts?
-eric _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas

On Tue, Sep 24, 2013 at 5:01 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
There's already an implicit expectation that iterables will be *consistent* in the absence of mutation (i.e. arbitrarily ordered rather than unordered), but I don't see how "ordered based on container internal details" is meaningfully different from "ordered by some external criterion".
"container internal details" is a good way to put it. "ordered" is a little too vague, isn't it. :) -eric

On 9/24/2013 12:15 PM, Eric Snow wrote:
Iterables are not necessarily ordered (e.g. dict vs. OrderedDict). Sequences are but Sets aren't. I'm not aware of any good way currently to know if an arbitrary iterable is ordered. Without an explicit indicator of ordered-ness, you must know in advance for each specific type.
One possible solution is an __isordered__ attribute (on the class), set to a boolean. The absence of the attribute would imply False.
Such an attribute would be added to existing types:
* collections.abc.Iterable (default: False) * list (True) * tuple (True) * set (False) * dict (False) * collections.OrderedDict (True) * ...
Thoughts?
The iterator protocol is intentionally simple. It only requires an __iter__ method or a __next__ method with a standard __iter__ method. This makes iterables -- and generator functions that produce iterators -- easy to write. A generator instance may and may not produce items in an intented order, so a class attribute is not possible. The same is generally true of transform iterators, like map and filter instances, and most itertools classes. It is also not true that lists (and tuples) always have a significant order. list(set) has the artificial order of set iteration. Both are reiterable with the same order. Why would you call one True and the other False? In general, list(iterable) has as much order as the iterable. The __isordered__ attribute would have to be an instance attribute, properly propagated. How would you do that with generator functions? or generator expression? Anyone is free to privately extend the protocol for special purposes and restrict their universe to object that follow. Builtins can be extended, wrapped, or mapped, or their internal iterator classes mapped, to make them conform. The following helps with the last idea.
for cls in list, tuple, set, frozenset, dict: type(iter(cls()))
<class 'list_iterator'> <class 'tuple_iterator'> <class 'set_iterator'> <class 'set_iterator'> <class 'dict_keyiterator'> -- Terry Jan Reedy

FYI, at this point I not longer have a use case for this feature, and I'm not in favor of this idea without one. On Tue, Sep 24, 2013 at 3:16 PM, Terry Reedy <tjreedy@udel.edu> wrote:
The iterator protocol is intentionally simple. It only requires an __iter__ method or a __next__ method with a standard __iter__ method. This makes iterables -- and generator functions that produce iterators -- easy to write.
This is not a proposal for an addition to the iterator protocol. It is about indicating (without iterating) that the iteration order of instances of a particular class will be consistent.
A generator instance may and may not produce items in an intented order, so a class attribute is not possible. The same is generally true of transform iterators, like map and filter instances, and most itertools classes. It is also not true that lists (and tuples) always have a significant order. list(set) has the artificial order of set iteration. Both are reiterable with the same order. Why would you call one True and the other False? In general, list(iterable) has as much order as the iterable.
However, once values are added to the list, that order is consistent. -eric

Iterables are not necessarily ordered (e.g. dict vs. OrderedDict). Sequences are but Sets aren't. I'm not aware of any good way currently to know if an arbitrary iterable is ordered. Without an explicit indicator of ordered-ness, you must know in advance for each specific type.
One possible solution is an __isordered__ attribute (on the class), set to a boolean. The absence of the attribute would imply False.
Isn't the traditional way to do this via "inheritance"? Then you call issubclass(list, OrderedContainer), etc. But, then, no Python hasn't completely ordered its data structures yet. Mark
participants (6)
-
Eric Snow
-
Guido van Rossum
-
Mark Janssen
-
Nick Coghlan
-
Shane Green
-
Terry Reedy