On Thu, Feb 21, 2013 at 5:50 AM, Yuval Greenfield wrote:

On Thu, Feb 21, 2013 at 3:35 PM, Wolfgang Maier < wolfgang.maier@biologie.uni-freiburg.de> wrote:

...

a = range(1,10) b = range(5,12) intersect = a & b # equivalent to intersect = range(5,10) merge = a | b # equivalent to merge = range(1,12)

...

...

already, so like there you could think of intersect = a & b as shorthand for intersect = a.intersection(b)

I think each operation you implement can have a lot of different bikeshed

this whole idea is reminiscent, of course, of what's implemented for sets details. Since these are all very simple to begin with, it's better to not burden the language and just let users implement whatever it is they need.

Ignoring performance issues, imagine instead a sorted set class that you could add ranges to (or remove them). Well, actually it's trivial to convert a range to a set; the interesting problem is performance. You could save the range parts unexpanded so you could add huge ranges and you could also support infinite ranges (itertools.count). I suggest this because once you consider doing the first set of operations, like r1 & r2, it's quite natural for someone to want some_non_unlucky_integers = range(100) - [13] The idea of a sorted set class is, of course, not original. See for example http://stutzbachenterprises.com/blist/sortedset.html. If SortedSet isn't in the stdlib, I can't imagine this enhancement being either. --- Bruce Latest blog post: Alice's Puzzle Page http://www.vroospeak.com

Nick Coghlan writes:

-1 from me as well. We don't even implement concatenation and repetition for ranges in order to keep them simple - we have to caveat the range docs to point out they don't *quite* implement the full sequence API due to this restriction.

However, I will note that starting in Python 3.3, range objects expose their "start", "stop" and "step" attributes. That makes it much easier for third party software to manipulate them arithmetically.

Cheers, Nick.

Any plans to make range a valid base class to build upon in future releases? Best, Wolfgang

On Fri, Feb 22, 2013 at 1:43 PM, Antoine Pitrou wrote:

On Fri, 22 Feb 2013 17:40:29 +0000 (UTC) Wolfgang Maier wrote:

...

Nick Coghlan writes:

...

-1 from me as well. We don't even implement concatenation and repetition for ranges in order to keep them simple - we have to caveat the range docs to point out they don't *quite* implement the full sequence API due to this restriction.

However, I will note that starting in Python 3.3, range objects expose their "start", "stop" and "step" attributes. That makes it much easier for third party software to manipulate them arithmetically.

Cheers, Nick.

Any plans to make range a valid base class to build upon in future releases?

I suppose it wouldn't very difficult to make range subclassable. You can try writing a patch if you want: http://docs.python.org/devguide/

Regards

I would be very happy to see a similar data structure available (on pypi). I was writing an HTTP-backed file object that used partial GET requests to just fetch the parts of the file that were actually read; it would have benefited from an efficient set-of-ranges (start+stop but not step) implementation.

On Sat, Feb 23, 2013 at 7:21 PM, Terry Reedy wrote:

On 2/22/2013 1:43 PM, Antoine Pitrou wrote:

...

On Fri, 22 Feb 2013 17:40:29 +0000 (UTC) Wolfgang Maier

...

...

Any plans to make range a valid base class to build upon in future releases?

I suppose it wouldn't very difficult to make range subclassable. You can try writing a patch if you want: http://docs.python.org/devguide/

I was just about to suggest that making range subclassable would be an alternative to extending the current class. As far as I know, there is no principled reason why not, unlike Nonetype and bool.

I wasn't even aware you *couldn't* subclass it (I'd never tried). As far as I am aware, that's just a quirk inherited from the old xrange implementation rather than a deliberate design decision. On the other hand, I suspect for many cases involving more advanced range variants, containment would be a better option than inheritance, particular if you want to implement a type that can't be reliably described through a (start, stop, step) triple. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 2/26/2013 11:46 PM, Raymond Hettinger wrote:

On Feb 23, 2013, at 3:11 AM, Nick Coghlan mailto:ncoghlan@gmail.com> wrote:

...

I suspect for many cases involving more advanced range variants, containment would be a better option than inheritance, particular if you want to implement a type that can't be reliably described through a (start, stop, step) triple.

I concur. Subclassing range() is just asking for trouble.

The four builtins that cannot be subclassed are bool, memoryview, range, slice. This is documented for bool; I propose to do so for the others in http://bugs.python.org/issue17279. Would it be correct to say (now) that all 4 are intentional omissions? and not merely oversights? -- Terry Jan Reedy