issubclass(collections.OrderedDict, collections.Sequence)
Hi guys, I was just going to test whether a mapping is dict-like or an OrderedDict-like object by doing this: isinstance(x, collections.Sequence) But then I checked and saw that this is False: issubclass(collections.OrderedDict, collections.Sequence) is False Why isn't an OrderedDict a Sequence?
On Sun, Oct 5, 2014 at 11:40 AM, Ram Rachum <ram@rachum.com> wrote:
Check the interface of Sequence. It requires indexing behavior that OrdedDict doesn't have -- a[i] is a key lookup in the underlying dict, not an indexed lookup in the ordered list of elements. I don't think it would be wise to attempt to add that behavior either (given that the keys may well be integers). -- --Guido van Rossum (python.org/~guido)
Can I ask you to mathematically define the property you are looking for here? In some other languages "Ordered" refers to being sorted or sortable, but the use of this word in OrderedDict does not refer to that at all. I tried coming up with a definition, but I got stuck with the rather vague "insertion order is preserved". Unfortunately, for the other collection types that (presumably) would qualify for this predicate, like list and tuple, the "insertion" operation is spelled differently than for OrderedDict -- OrderedDict's rule seems to be "new elements inserted with __setitem__ are appended to the end of the underlying sequence", while for list you'd have to write something about the insert() and append() methods (plus other operations like slice assignment and extend() that can be reduced to these), and for tuple you'd have to refer to the constructor. I don't think that definition is sufficiently crisp and reusable to warrant defining a collection ABC for it. But perhaps you can come up with a better specification for your proposed collections.Ordered ABC? On Sun, Oct 5, 2014 at 1:56 PM, Ram Rachum <ram@rachum.com> wrote:
-- --Guido van Rossum (python.org/~guido)
I think the definition of ordered here would be that the container's iteration order carries any meaning (compare: dicts and sets' having iteration order is an incidental effect of one thing having to be iterated out first, and one shouldn't depend on that order; lists and ordereddicts' having iteration order is deliberate). I don't think there's a mathematical definition possible - it's just a question of whether whoever wrote the class left the iteration order documented or unspecified. edk
OK, so collections.Ordered would be a subclass of Iterable that adds no new methods but makes a promise about the author's intent. But what kind of use could a program make of this? The only things I can think of would have to be combined with some other specific container type that isn't always ordered (Sequence is ordered, Set and Mapping aren't). I can think of plenty of situations where it would be useful to say "use an OrderedDict, otherwise X will happen", but I can't think of a case where I could say "use any container type you like as long as it is Ordered". What was your use case? Do you have one? Or are you just interested in asking questions? On Sun, Oct 5, 2014 at 3:07 PM, Ram Rachum <ram@rachum.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Here are a couple: - I'm making a combinatorics package, and a combination space needs to have a __contains__ method that takes a combination and returns whether it's part of a set. Since a combination, unlike a permutation, has no order, I like to have my combinations be canonicalized in a sorted order. For example, in a combination space of 3 items on range(4), (0, 1, 3) would be a combination in that space, but (3, 1, 0) would not because it's not sorted. (It's a k-permutation but not a combination.) However, if the user does `{0, 1, 3} in comb_space` I still want to return True, regardless of whether the set iterator happens to give these items in order or not. - For the same package, I'm defining `Tally` and `OrderedTally` classes. (Simliar to `Counter` except without having an identity crisis between being a dict subclass and counter; mine are strictly counters.) In the tests I want to easily see whether the class I'm testing is the ordered one or not, so I'll know to run appropriate tests. (There are also `FrozenTally` and `FrozenOrderedTally` so it's not just one class.) I could set `is_ordered = True` on them or give them some base class, but I think a general `collections.Ordered` abstract base class would be the best solution. On Mon, Oct 6, 2014 at 2:15 AM, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 6, 2014 at 1:10 AM, Ram Rachum <ram@rachum.com> wrote:
So how are you writing this code today? In the following case, what's in the then or else branch? if not isinstance(x, collections.Ordered): <what???> else: <what???> Even if you could write this, how would you know that an ordered argument is in the *canonical* order? - For the same package, I'm defining `Tally` and `OrderedTally` classes.
Same question. -- --Guido van Rossum (python.org/~guido)
On Mon, Oct 6, 2014 at 8:35 PM, Guido van Rossum <guido@python.org> wrote:
That part isn't written yet (the package is still work-in-progress), but I'm not sure what the problem is. I'll have the code look at `x`. If it's marked as ordered, then I'd iterate on it. If it has the correct items (meaning the items of the sequence that this is a combination space of) and the items in x are in the same order as they are in the sequence, and it has the correct number of items, then we have a match. If we have `not isinstance(x, collections.Ordered)` then I do the same thing except I ignore the order of the items. What's the problem?
If you haven't written the code yet, how can you say there's something missing in Python that needs to be implemented, at significant time and cost, by the Python developers? You need to provide your best attempt at implementing this in Python as-is, and identify where the language's design or gaps in the standard libraries are creating a problem for you and others that's significant enough to warrant a change to Python's stdlib. Or, show how solving your problem would create a language that's better, more exciting, or more fun for the rest of us. Right now, your use-case seems really specific, and is likely something that you can solve just by exhaustively listing the types you want to consider "ordered" as a global tuple and using that tuple as your isinstance() check. So, `isinstance(foo, (collections.OrderedDict, tuple, list))` or whatever. Although, actually it sounds like you need to know more than whether an object has a defined order, but also whether it's in the order you expect, so really this calls for a dedicated checking function that does all the magic you want at once. On 07/10/14 08:00, Ram Rachum wrote:
-- Twitter: @onetruecathal, @formabiolabs Phone: +353876363185 Blog: http://indiebiotech.com miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
On 10/07/2014 12:00 AM, Ram Rachum wrote:
Use case not relevant enough for you?
No, your attitude stinks -- or maybe it's just your communication style. Phrases such as, "I don't see what the problem is" does not credit anybody else with intelligence, or we would also 'not see what the problem is", right? But we are not you, don't have your experience, aren't writing your software, and most of us will not see your issues unless you explain them thoroughly. "This would be cool" is not a thorough explanation, does not list use-cases, provides no list of pro's and con's, and provides no evidence that you have thoroughly thought through your proposal. At least, that's my take on the matter. -- ~Ethan~
I'm sorry that I offended. I didn't mean to imply anything about anyone's intelligence by saying "I don't see what the problem is", I was just saying I don't see what the problem is, and if I someone sees a problem I didn't, I'll be happy to have it pointed out to me so we can discuss it, and if the other person agrees that there isn't a problem, we can move on. I implemented classes for this in my project and I'll see whether it's useful (I'm already getting the feeling that a `DefinitelyUnordered` base class is more useful as it's easier to capture the unordered than the ordered.) If it proves useful, I'll write back and if there'll be interest to put something like this into Python, that'll be cool. On Tue, Oct 7, 2014 at 10:05 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
Thanks for giving me feedback. I'm trying to be easier to deal with. I looked back at the thread but couldn't see where I was asked a precise question and gave a vague answer. The closest thing to it was when you asked for the meaning of when something is ordered. Ed answered something and I said I meant exactly what he said, but maybe I should have been more explicit: I meant that it's guaranteed that `tuple(x) == tuple(x)`. If there are any more cases where I was vague, I'll be happy to be more specific. On Tue, Oct 7, 2014 at 10:54 PM, Guido van Rossum <guido@python.org> wrote:
You're right, I didn't think of that case. So the best definition I can come up with is: "The iteration order is defined and meaningful, and not random." Is this specific enough? I know it's something which isn't testable programmatically (same as `tuple(x) == tuple(x)` which is impractical to test.) On Tue, Oct 7, 2014 at 11:10 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Ah, perhaps I haven't explained clearly enough. I did not mean that the result of `isinstance(x, Ordered)` would be somehow determined by the canonical order in my combinatorics package (which would be absurd as my package is just my own thing and shouldn't affect a type in `collections`). I meant that my combinatorics package, when asked whether a certain iterable belongs in a combination space, would check its order only if the iterable type is `Ordered`. (i.e. it's communicating "my order is meaningful".) For example, someone could have a combination space "3 items taken from range(5)", which has members like (0, 1, 2) and (1, 3, 4), but not (4, 2, 1) because it's not in canoncial order. If someone were to check `(4, 2, 1) in comb_space` he should get `False`, but if he's checking `{1, 2, 4} in comb_space` he should get `True`, regardless of iteration order, because it's a `set` which isn't supposed to be ordered so it's assumed the user is not asking a question about order. On Tue, Oct 7, 2014 at 11:20 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Oct 07, 2014 at 11:27:50PM +0300, Ram Rachum wrote: [...]
If I have understood you correctly, you have a single function which does two different tests, an ordered test and an unordered test, with the decision of which to perform being implicitly decided by the input type. I think the Zen of Python has a few things to say about that sort of API: Explicit is better than implicit. In the face of ambiguity, refuse the temptation to guess. It sounds to me that you would be better served by two functions, one which checks order and one which does not. But if you insist on having a single function which decides which test to perform based on the type of the input argument, you are under no obligation to attempt to support every imaginable sequence type "correctly". You can offer a firm guarantee that your function will guess correctly if the type is a list, tuple, set or frozenset, and for everything else you offer a "best effort" guess as to whether the input sequence is ordered or not. -- Steven
On Tue, Oct 7, 2014, at 16:20, Guido van Rossum wrote:
No, that is the condition he is testing for. i.e. (pseudo-code, and probably not the order in which these tests would normally take place) if the elements of object A are a subset those of list B: if object A has a meaningful order: if the order of object A's elements is the same as that of list B: return True else: return False else: return True else: return False
Ram Rachum writes:
Yep, this is what I meant.
(And you'll answer in this precision in the future, of course. :)
On Tue, Oct 7, 2014 at 11:28 PM, <random832@fastmail.us> wrote:
But this requires a comparison of the two orders, and "ordering relation" is not a type available in the stdlib. So I don't see how you propose to do this comparison. This is why you need concrete examples, preferably with running code. OTOH, in the kind of context you're working with, I'd probably use a specific ordered type to contain the combinations (which might be a tree or other implicitly ordered type, not necessarily a Sequence) rather than generic lists etc., and define __eq__ on it. The need for collections.Ordered evaporates!
On Tue, Oct 7, 2014, at 21:09, Stephen J. Turnbull wrote:
But this requires a comparison of the two orders, and "ordering relation" is not a type available in the stdlib.
This has nothing to do with comparable types - the only comparison being done on the members themselves is equality. i.e. if the main sequence is [5, 1, 3, 2, 4], it's true for [5, 2, 4] but not [5, 4, 1]. Think of it as being the question of whether "51234" matches "5.*2.*4" (it does) or "5.*4.*1" (it does not). But if the argument is a set instead he wants it to be whether it's a subset rather than a subsequence.
On 8 Oct 2014 14:09, "Guido van Rossum" <guido@python.org> wrote:
have seen. Thank you! And now that I also understand it, I can note that this kind of thing *does* occasionally come up in testing polymorphic filtering operations. If the original container has a non-arbitrary ordering, the filtering operation should preserve it. If the container ordering is arbitrary (e.g. set, dict) then filtering may also change the relative ordering of the retained elements. That observation also gives a possible concrete semantic definition as to what "Ordered" might mean: adding or removing a new element never changes the relative ordering of the other elements in the container. Under that definition, set and dict aren't ordered, since the order of iteration can be affected by the current number of items in the container. As an example of the difference mattering in practice, "assertSameElements" is specifically designed to help deal with cases where you're comparing an unordered result to ordered reference data. Cheers, Nick.
On 8 October 2014 05:37, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If the order of the elements in the ordered container is the same - which is easy to test for. In the interest of being exactly clear, here's some code that does so (assuming I understand correctly). This probably should be cleaned up, but gets the job done: def subordered(subset, superset): si = iter(superset) for x in subset: for y in si: if x == y: break else: return False return True print(subordered([1, 4, 8, 9], range(10))) # True print(subordered([1, 4, 9, 8], range(10))) # False edk
Ed Kellett writes:
Well, sure, if it's computable you can write Python code to do it. My point is that isinstance.(collections.Ordered) isn't enough. You must do additional work (worst case O(N) for the largest possible N = #superset) or put additional information into the type. I just don't see much valued added in this ABC or whatever is being proposed for addition to the stdlib.
Ed Kellett writes:
No, I didn't miss that at all. I just have a different point that I think is far more important. I think you, random, and Ram are wasting a lot of your own time defending this idea in the terms you are using, and I'm trying to explain why I believe that. I'll happily stop, right here, since I've been entirely unsuccessful so far.
On 9 October 2014 07:04, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I don't actually believe I have defended this idea once. I don't care whether it is added to the stdlib - I just didn't want it to get shut down because of a miscommunication, rather than because people didn't think its uses were useful enough. edk
On Thu, Oct 9, 2014, at 07:46, Ed Kellett wrote:
Same here, personally I think his use case would be better served by two functions, or by a flag that's passed in by the caller. There's no particular reason to _not_ want to do the unordered subset comparison on a list.
On Tue, Oct 07, 2014 at 11:13:57PM +0300, Ram Rachum wrote:
"Meaningful" isn't specific. Meaningful to whom, in what way? Some people might say that the iteration order of a dict or set is "meaningful" because it reflects the order of entries in the underlying hash table. And "not random" is too specific, since there could be many things which have arbitrary but deterministic and non-random order. Like sets and dicts. -- Steven
On 10/07/2014 12:45 PM, Ram Rachum wrote:
Text communication is difficult, considering a large portion of human communication is via body language and intonation.
The big hurdles for getting anything new into Python are: - general applicability - additional expressive power - easing of hard-to-get-right tasks - etc. Claiming that something is so (such as Enum serial numbers) is not sufficient to make it so. You have to provide examples either from other languages or actual code that prove it, and hopefully be able to demonstrate that the need is greater than just your code base. -- ~Ethan~
On Tue, Oct 7, 2014 at 11:00 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On one hand I understand the reasoning of looking for concrete use cases, but on the other hand I think it has its drawbacks. There's lots of things, like for example tuple.count, which if I remember correctly was added in a pretty late version of Python (2.6 or something) and I needed it in a previous version and it annoyed me that it wasn't there. You don't need to wait for someone to say "Hey, I need `tuple.count`", if you have it on `list` then people are probably gonna need it on `tuple` at one point or another, so if it's a reasonable feature, I think it's good to provide it early to save all that time, because it's obvious there are going to be use cases. Another example is PEP 3155. Instead of waiting for people to get frustrated that they can't pass references to methods to `multiprocessing.Process` and then having to wait for Python 3.3 to do that, we could have preempted and implemented it before based on common sense (i.e. if I have a method object, it should have information on it telling where to find it.) Of course, this approach has its disadvantages as well, and we always need to be careful when adding anything to Python because it's a mostly unreversible process.
On 10/07/2014 01:10 PM, Ram Rachum wrote:
The trouble with obvious is it isn't. ;)
This why we have a public PEP process, to try and feedback from as many folk as possible. (see my previous point)
Of course, this approach has its disadvantages as well, and we always need to be careful when adding anything to Python because it's a mostly unreversible process.
Yup -- it's easier to add something once it's known to be needed, than to live with bloat because we added something and it turns out nobody uses it, or a better method was found and added, or ... -- ~Ethan~
On Oct 5, 2014, at 15:05, Ed Kellett <edk141@gmail.com> wrote:
So this also implies that your favorite sorted dict class would also be Ordered. And that all of the views of OrderedDict (and SortedDict and rbtree and so on) would also be Ordered. But I'm not sure what exactly you can do with that either... (Having the values view of an ordered or sorted dict be a Sequence, I can sort of imagine a use case for, but just an Ordered Container MappingView, I don't know.)
On Oct 5, 2014, at 11:40 AM, Ram Rachum <ram@rachum.com> wrote:
Why isn't an OrderedDict a Sequence?
Because wasn't designed that way (it doesn't have or need count(), index(), slicing, etc. Nor is it designed in a way that makes any of those operations efficient). If you want a list, it is simple to make one: s = list(od). Raymond
On Sun, Oct 5, 2014 at 11:40 AM, Ram Rachum <ram@rachum.com> wrote:
Check the interface of Sequence. It requires indexing behavior that OrdedDict doesn't have -- a[i] is a key lookup in the underlying dict, not an indexed lookup in the ordered list of elements. I don't think it would be wise to attempt to add that behavior either (given that the keys may well be integers). -- --Guido van Rossum (python.org/~guido)
Can I ask you to mathematically define the property you are looking for here? In some other languages "Ordered" refers to being sorted or sortable, but the use of this word in OrderedDict does not refer to that at all. I tried coming up with a definition, but I got stuck with the rather vague "insertion order is preserved". Unfortunately, for the other collection types that (presumably) would qualify for this predicate, like list and tuple, the "insertion" operation is spelled differently than for OrderedDict -- OrderedDict's rule seems to be "new elements inserted with __setitem__ are appended to the end of the underlying sequence", while for list you'd have to write something about the insert() and append() methods (plus other operations like slice assignment and extend() that can be reduced to these), and for tuple you'd have to refer to the constructor. I don't think that definition is sufficiently crisp and reusable to warrant defining a collection ABC for it. But perhaps you can come up with a better specification for your proposed collections.Ordered ABC? On Sun, Oct 5, 2014 at 1:56 PM, Ram Rachum <ram@rachum.com> wrote:
-- --Guido van Rossum (python.org/~guido)
I think the definition of ordered here would be that the container's iteration order carries any meaning (compare: dicts and sets' having iteration order is an incidental effect of one thing having to be iterated out first, and one shouldn't depend on that order; lists and ordereddicts' having iteration order is deliberate). I don't think there's a mathematical definition possible - it's just a question of whether whoever wrote the class left the iteration order documented or unspecified. edk
OK, so collections.Ordered would be a subclass of Iterable that adds no new methods but makes a promise about the author's intent. But what kind of use could a program make of this? The only things I can think of would have to be combined with some other specific container type that isn't always ordered (Sequence is ordered, Set and Mapping aren't). I can think of plenty of situations where it would be useful to say "use an OrderedDict, otherwise X will happen", but I can't think of a case where I could say "use any container type you like as long as it is Ordered". What was your use case? Do you have one? Or are you just interested in asking questions? On Sun, Oct 5, 2014 at 3:07 PM, Ram Rachum <ram@rachum.com> wrote:
-- --Guido van Rossum (python.org/~guido)
Here are a couple: - I'm making a combinatorics package, and a combination space needs to have a __contains__ method that takes a combination and returns whether it's part of a set. Since a combination, unlike a permutation, has no order, I like to have my combinations be canonicalized in a sorted order. For example, in a combination space of 3 items on range(4), (0, 1, 3) would be a combination in that space, but (3, 1, 0) would not because it's not sorted. (It's a k-permutation but not a combination.) However, if the user does `{0, 1, 3} in comb_space` I still want to return True, regardless of whether the set iterator happens to give these items in order or not. - For the same package, I'm defining `Tally` and `OrderedTally` classes. (Simliar to `Counter` except without having an identity crisis between being a dict subclass and counter; mine are strictly counters.) In the tests I want to easily see whether the class I'm testing is the ordered one or not, so I'll know to run appropriate tests. (There are also `FrozenTally` and `FrozenOrderedTally` so it's not just one class.) I could set `is_ordered = True` on them or give them some base class, but I think a general `collections.Ordered` abstract base class would be the best solution. On Mon, Oct 6, 2014 at 2:15 AM, Guido van Rossum <guido@python.org> wrote:
On Mon, Oct 6, 2014 at 1:10 AM, Ram Rachum <ram@rachum.com> wrote:
So how are you writing this code today? In the following case, what's in the then or else branch? if not isinstance(x, collections.Ordered): <what???> else: <what???> Even if you could write this, how would you know that an ordered argument is in the *canonical* order? - For the same package, I'm defining `Tally` and `OrderedTally` classes.
Same question. -- --Guido van Rossum (python.org/~guido)
On Mon, Oct 6, 2014 at 8:35 PM, Guido van Rossum <guido@python.org> wrote:
That part isn't written yet (the package is still work-in-progress), but I'm not sure what the problem is. I'll have the code look at `x`. If it's marked as ordered, then I'd iterate on it. If it has the correct items (meaning the items of the sequence that this is a combination space of) and the items in x are in the same order as they are in the sequence, and it has the correct number of items, then we have a match. If we have `not isinstance(x, collections.Ordered)` then I do the same thing except I ignore the order of the items. What's the problem?
If you haven't written the code yet, how can you say there's something missing in Python that needs to be implemented, at significant time and cost, by the Python developers? You need to provide your best attempt at implementing this in Python as-is, and identify where the language's design or gaps in the standard libraries are creating a problem for you and others that's significant enough to warrant a change to Python's stdlib. Or, show how solving your problem would create a language that's better, more exciting, or more fun for the rest of us. Right now, your use-case seems really specific, and is likely something that you can solve just by exhaustively listing the types you want to consider "ordered" as a global tuple and using that tuple as your isinstance() check. So, `isinstance(foo, (collections.OrderedDict, tuple, list))` or whatever. Although, actually it sounds like you need to know more than whether an object has a defined order, but also whether it's in the order you expect, so really this calls for a dedicated checking function that does all the magic you want at once. On 07/10/14 08:00, Ram Rachum wrote:
-- Twitter: @onetruecathal, @formabiolabs Phone: +353876363185 Blog: http://indiebiotech.com miniLock.io: JjmYYngs7akLZUjkvFkuYdsZ3PyPHSZRBKNm6qTYKZfAM
On 10/07/2014 12:00 AM, Ram Rachum wrote:
Use case not relevant enough for you?
No, your attitude stinks -- or maybe it's just your communication style. Phrases such as, "I don't see what the problem is" does not credit anybody else with intelligence, or we would also 'not see what the problem is", right? But we are not you, don't have your experience, aren't writing your software, and most of us will not see your issues unless you explain them thoroughly. "This would be cool" is not a thorough explanation, does not list use-cases, provides no list of pro's and con's, and provides no evidence that you have thoroughly thought through your proposal. At least, that's my take on the matter. -- ~Ethan~
I'm sorry that I offended. I didn't mean to imply anything about anyone's intelligence by saying "I don't see what the problem is", I was just saying I don't see what the problem is, and if I someone sees a problem I didn't, I'll be happy to have it pointed out to me so we can discuss it, and if the other person agrees that there isn't a problem, we can move on. I implemented classes for this in my project and I'll see whether it's useful (I'm already getting the feeling that a `DefinitelyUnordered` base class is more useful as it's easier to capture the unordered than the ordered.) If it proves useful, I'll write back and if there'll be interest to put something like this into Python, that'll be cool. On Tue, Oct 7, 2014 at 10:05 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
Thanks for giving me feedback. I'm trying to be easier to deal with. I looked back at the thread but couldn't see where I was asked a precise question and gave a vague answer. The closest thing to it was when you asked for the meaning of when something is ordered. Ed answered something and I said I meant exactly what he said, but maybe I should have been more explicit: I meant that it's guaranteed that `tuple(x) == tuple(x)`. If there are any more cases where I was vague, I'll be happy to be more specific. On Tue, Oct 7, 2014 at 10:54 PM, Guido van Rossum <guido@python.org> wrote:
You're right, I didn't think of that case. So the best definition I can come up with is: "The iteration order is defined and meaningful, and not random." Is this specific enough? I know it's something which isn't testable programmatically (same as `tuple(x) == tuple(x)` which is impractical to test.) On Tue, Oct 7, 2014 at 11:10 PM, Alexander Belopolsky < alexander.belopolsky@gmail.com> wrote:
Ah, perhaps I haven't explained clearly enough. I did not mean that the result of `isinstance(x, Ordered)` would be somehow determined by the canonical order in my combinatorics package (which would be absurd as my package is just my own thing and shouldn't affect a type in `collections`). I meant that my combinatorics package, when asked whether a certain iterable belongs in a combination space, would check its order only if the iterable type is `Ordered`. (i.e. it's communicating "my order is meaningful".) For example, someone could have a combination space "3 items taken from range(5)", which has members like (0, 1, 2) and (1, 3, 4), but not (4, 2, 1) because it's not in canoncial order. If someone were to check `(4, 2, 1) in comb_space` he should get `False`, but if he's checking `{1, 2, 4} in comb_space` he should get `True`, regardless of iteration order, because it's a `set` which isn't supposed to be ordered so it's assumed the user is not asking a question about order. On Tue, Oct 7, 2014 at 11:20 PM, Guido van Rossum <guido@python.org> wrote:
On Tue, Oct 07, 2014 at 11:27:50PM +0300, Ram Rachum wrote: [...]
If I have understood you correctly, you have a single function which does two different tests, an ordered test and an unordered test, with the decision of which to perform being implicitly decided by the input type. I think the Zen of Python has a few things to say about that sort of API: Explicit is better than implicit. In the face of ambiguity, refuse the temptation to guess. It sounds to me that you would be better served by two functions, one which checks order and one which does not. But if you insist on having a single function which decides which test to perform based on the type of the input argument, you are under no obligation to attempt to support every imaginable sequence type "correctly". You can offer a firm guarantee that your function will guess correctly if the type is a list, tuple, set or frozenset, and for everything else you offer a "best effort" guess as to whether the input sequence is ordered or not. -- Steven
On Tue, Oct 7, 2014, at 16:20, Guido van Rossum wrote:
No, that is the condition he is testing for. i.e. (pseudo-code, and probably not the order in which these tests would normally take place) if the elements of object A are a subset those of list B: if object A has a meaningful order: if the order of object A's elements is the same as that of list B: return True else: return False else: return True else: return False
Ram Rachum writes:
Yep, this is what I meant.
(And you'll answer in this precision in the future, of course. :)
On Tue, Oct 7, 2014 at 11:28 PM, <random832@fastmail.us> wrote:
But this requires a comparison of the two orders, and "ordering relation" is not a type available in the stdlib. So I don't see how you propose to do this comparison. This is why you need concrete examples, preferably with running code. OTOH, in the kind of context you're working with, I'd probably use a specific ordered type to contain the combinations (which might be a tree or other implicitly ordered type, not necessarily a Sequence) rather than generic lists etc., and define __eq__ on it. The need for collections.Ordered evaporates!
On Tue, Oct 7, 2014, at 21:09, Stephen J. Turnbull wrote:
But this requires a comparison of the two orders, and "ordering relation" is not a type available in the stdlib.
This has nothing to do with comparable types - the only comparison being done on the members themselves is equality. i.e. if the main sequence is [5, 1, 3, 2, 4], it's true for [5, 2, 4] but not [5, 4, 1]. Think of it as being the question of whether "51234" matches "5.*2.*4" (it does) or "5.*4.*1" (it does not). But if the argument is a set instead he wants it to be whether it's a subset rather than a subsequence.
On 8 Oct 2014 14:09, "Guido van Rossum" <guido@python.org> wrote:
have seen. Thank you! And now that I also understand it, I can note that this kind of thing *does* occasionally come up in testing polymorphic filtering operations. If the original container has a non-arbitrary ordering, the filtering operation should preserve it. If the container ordering is arbitrary (e.g. set, dict) then filtering may also change the relative ordering of the retained elements. That observation also gives a possible concrete semantic definition as to what "Ordered" might mean: adding or removing a new element never changes the relative ordering of the other elements in the container. Under that definition, set and dict aren't ordered, since the order of iteration can be affected by the current number of items in the container. As an example of the difference mattering in practice, "assertSameElements" is specifically designed to help deal with cases where you're comparing an unordered result to ordered reference data. Cheers, Nick.
On 8 October 2014 05:37, Stephen J. Turnbull <stephen@xemacs.org> wrote:
If the order of the elements in the ordered container is the same - which is easy to test for. In the interest of being exactly clear, here's some code that does so (assuming I understand correctly). This probably should be cleaned up, but gets the job done: def subordered(subset, superset): si = iter(superset) for x in subset: for y in si: if x == y: break else: return False return True print(subordered([1, 4, 8, 9], range(10))) # True print(subordered([1, 4, 9, 8], range(10))) # False edk
Ed Kellett writes:
Well, sure, if it's computable you can write Python code to do it. My point is that isinstance.(collections.Ordered) isn't enough. You must do additional work (worst case O(N) for the largest possible N = #superset) or put additional information into the type. I just don't see much valued added in this ABC or whatever is being proposed for addition to the stdlib.
Ed Kellett writes:
No, I didn't miss that at all. I just have a different point that I think is far more important. I think you, random, and Ram are wasting a lot of your own time defending this idea in the terms you are using, and I'm trying to explain why I believe that. I'll happily stop, right here, since I've been entirely unsuccessful so far.
On 9 October 2014 07:04, Stephen J. Turnbull <stephen@xemacs.org> wrote:
I don't actually believe I have defended this idea once. I don't care whether it is added to the stdlib - I just didn't want it to get shut down because of a miscommunication, rather than because people didn't think its uses were useful enough. edk
On Thu, Oct 9, 2014, at 07:46, Ed Kellett wrote:
Same here, personally I think his use case would be better served by two functions, or by a flag that's passed in by the caller. There's no particular reason to _not_ want to do the unordered subset comparison on a list.
On Tue, Oct 07, 2014 at 11:13:57PM +0300, Ram Rachum wrote:
"Meaningful" isn't specific. Meaningful to whom, in what way? Some people might say that the iteration order of a dict or set is "meaningful" because it reflects the order of entries in the underlying hash table. And "not random" is too specific, since there could be many things which have arbitrary but deterministic and non-random order. Like sets and dicts. -- Steven
On 10/07/2014 12:45 PM, Ram Rachum wrote:
Text communication is difficult, considering a large portion of human communication is via body language and intonation.
The big hurdles for getting anything new into Python are: - general applicability - additional expressive power - easing of hard-to-get-right tasks - etc. Claiming that something is so (such as Enum serial numbers) is not sufficient to make it so. You have to provide examples either from other languages or actual code that prove it, and hopefully be able to demonstrate that the need is greater than just your code base. -- ~Ethan~
On Tue, Oct 7, 2014 at 11:00 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On one hand I understand the reasoning of looking for concrete use cases, but on the other hand I think it has its drawbacks. There's lots of things, like for example tuple.count, which if I remember correctly was added in a pretty late version of Python (2.6 or something) and I needed it in a previous version and it annoyed me that it wasn't there. You don't need to wait for someone to say "Hey, I need `tuple.count`", if you have it on `list` then people are probably gonna need it on `tuple` at one point or another, so if it's a reasonable feature, I think it's good to provide it early to save all that time, because it's obvious there are going to be use cases. Another example is PEP 3155. Instead of waiting for people to get frustrated that they can't pass references to methods to `multiprocessing.Process` and then having to wait for Python 3.3 to do that, we could have preempted and implemented it before based on common sense (i.e. if I have a method object, it should have information on it telling where to find it.) Of course, this approach has its disadvantages as well, and we always need to be careful when adding anything to Python because it's a mostly unreversible process.
On 10/07/2014 01:10 PM, Ram Rachum wrote:
The trouble with obvious is it isn't. ;)
This why we have a public PEP process, to try and feedback from as many folk as possible. (see my previous point)
Of course, this approach has its disadvantages as well, and we always need to be careful when adding anything to Python because it's a mostly unreversible process.
Yup -- it's easier to add something once it's known to be needed, than to live with bloat because we added something and it turns out nobody uses it, or a better method was found and added, or ... -- ~Ethan~
On Oct 5, 2014, at 15:05, Ed Kellett <edk141@gmail.com> wrote:
So this also implies that your favorite sorted dict class would also be Ordered. And that all of the views of OrderedDict (and SortedDict and rbtree and so on) would also be Ordered. But I'm not sure what exactly you can do with that either... (Having the values view of an ordered or sorted dict be a Sequence, I can sort of imagine a use case for, but just an Ordered Container MappingView, I don't know.)
On Oct 5, 2014, at 11:40 AM, Ram Rachum <ram@rachum.com> wrote:
Why isn't an OrderedDict a Sequence?
Because wasn't designed that way (it doesn't have or need count(), index(), slicing, etc. Nor is it designed in a way that makes any of those operations efficient). If you want a list, it is simple to make one: s = list(od). Raymond
participants (13)
-
Alexander Belopolsky -
Andrew Barnert -
Cathal Garvey -
Ed Kellett -
Ethan Furman -
Guido van Rossum -
Nick Coghlan -
Ram Rachum -
random832＠fastmail.us -
Raymond Hettinger -
Serhiy Storchaka -
Stephen J. Turnbull -
Steven D'Aprano