Message164404
>> None of those are specific to arithmetic progressions (i.e., range-like lists / sets), as far as I can tell.
Does this (the data-type involved) really matter?
>> I could see more use for general list-intersection functionality.
The way to implement generic functionality is to define a protocol and override inherited behavior when necessary. Generic intersection (when semantics can be agreed upon) can computed using the iterator protocol, but __and__ of the range class should be overridden to provide O(1) behavior.
So, perhaps a proposal for implementing __and__ for lists as well ?
>> I'm still -1 on this; it seems too specialised a need to belong in the core language.
While I do see several arguments against the inclusion of __and__:
. it would require the inclusion of union and difference operations
. vague definition of intersection with regard to ranges. Do you treat range like a linear equation, so only consider intersections at the same index. Also the issue regarding ordering.
. re issue1766304, it may be pointless providing an O(1) __and__ for range if it can only work for ints(??)
I don't think that complexity or specialisation should matter. A range is already a specialised data type (do any other languages have a range class - separate from slices?) Python's data model provides __and__. Conceptually, why not bring range to its full potential using facilities that python already provides.
By the way, I don't have anything at stake in this - just arguing for argument's sake - so you can close this if you feel strongly enough about not implementing it. |
|
Date |
User |
Action |
Args |
2012-06-30 17:30:45 | Yclept.Nemo | set | recipients:
+ Yclept.Nemo, mark.dickinson, serhiy.storchaka |
2012-06-30 17:30:45 | Yclept.Nemo | set | messageid: <1341077445.38.0.763643231695.issue15224@psf.upfronthosting.co.za> |
2012-06-30 17:30:44 | Yclept.Nemo | link | issue15224 messages |
2012-06-30 17:30:44 | Yclept.Nemo | create | |
|