title: How should I handle inclusive ranges in Python?
body: <p>I am working in a domain in which ranges are conventionally described inclusively. I have human-readable descriptions such as <code>from A to B</code> , which represent ranges that include both end points - e.g. <code>from 2 to 4</code> means <code>2, 3, 4</code>.</p>
  
  <p>What is the best way to work with these ranges in Python code? The following code works to generate inclusive ranges of integers, but I also need to perform inclusive slice operations:</p>
  
  <pre><code>def inclusive_range(start, stop, step):
      return range(start, (stop + 1) if step &gt;= 0 else (stop - 1), step)
  </code></pre>
  
  <p>The only complete solution I see is to explicitly use <code>+ 1</code> (or <code>- 1</code>) every time I use <code>range</code> or slice notation (e.g. <code>range(A, B + 1)</code>, <code>l[A:B+1]</code>, <code>range(B, A - 1, -1)</code>). Is this repetition really the best way to work with inclusive ranges?</p>
  
  <p><strong>Edit:</strong> Thanks to L3viathan for answering. Writing an <code>inclusive_slice</code> function to complement <code>inclusive_range</code> is certainly an option, although I would probably write it as follows:</p>
  
  <pre><code>def inclusive_slice(start, stop, step):
      ...
      return slice(start, (stop + 1) if step &gt;= 0 else (stop - 1), step)
  </code></pre>
  
  <p><code>...</code> here represents code to handle negative indices, which are not straightforward when used with slices - note, for example, that L3viathan's function gives incorrect results if <code>slice_to == -1</code>.</p>
  
  <p>However, it seems that an <code>inclusive_slice</code> function would be awkward to use - is <code>l[inclusive_slice(A, B)]</code> really any better than <code>l[A:B+1]</code>?</p>
  
  <p>Is there any better way to handle inclusive ranges?</p>
  
  <p><strong>Edit 2:</strong> Thank you for the new answers. I agree with Francis and Corley that changing the meaning of slice operations, either globally or for certain classes, would lead to significant confusion. I am therefore now leaning towards writing an <code>inclusive_slice</code> function.</p>
  
  <p>To answer my own question from the previous edit, I have come to the conclusion that using such a function (e.g. <code>l[inclusive_slice(A, B)]</code>) would be better than manually adding/subtracting 1 (e.g. <code>l[A:B+1]</code>), since it would allow edge cases (such as <code>B == -1</code> and <code>B == None</code>) to be handled in a single place. Can we reduce the awkwardness in using the function?</p>
  
  <p><strong>Edit 3:</strong> I have been thinking about how to improve the usage syntax, which currently looks like <code>l[inclusive_slice(1, 5, 2)]</code>. In particular, it would be good if the creation of an inclusive slice resembled standard slice syntax. In order to allow this, instead of <code>inclusive_slice(start, stop, step)</code>, there could be a function <code>inclusive</code> that takes a slice as a parameter. The ideal usage syntax for <code>inclusive</code> would be line <code>1</code>:</p>
  
  <pre><code>l[inclusive(1:5:2)]          # 1
  l[inclusive(slice(1, 5, 2))] # 2
  l[inclusive(s_[1:5:2])]      # 3
  l[inclusive[1:5:2]]          # 4
  l[1:inclusive(5):2]          # 5
  </code></pre>
  
  <p>Unfortunately this is not permitted by Python, which only allows the use of <code>:</code> syntax within <code>[]</code>. <code>inclusive</code> would therefore have to be called using either syntax <code>2</code> or <code>3</code> (where <code>s_</code> acts like <a href="http://docs.scipy.org/doc/numpy/reference/generated/numpy.s_.html" rel="noreferrer">the version provided by numpy</a>).</p>
  
  <p>Other possibilities are to make <code>inclusive</code> into an object with <code>__getitem__</code>, permitting syntax <code>4</code>, or to apply <code>inclusive</code> only to the <code>stop</code> parameter of the slice, as in syntax <code>5</code>. Unfortunately I do not believe the latter can be made to work since <code>inclusive</code> requires knowledge of the <code>step</code> value.</p>
  
  <p>Of the workable syntaxes (the original <code>l[inclusive_slice(1, 5, 2)]</code>, plus <code>2</code>, <code>3</code> and <code>4</code>), which would be the best to use? Or is there another, better option?</p>
  
  <p><strong>Final Edit:</strong> Thank you all for the replies and comments, this has been very interesting. I have always been a fan of Python's "one way to do it" philosophy, but this issue has been caused by a conflict between Python's "one way" and the "one way" proscribed by the problem domain. I have definitely gained some appreciation for <a href="http://en.wikipedia.org/wiki/There%27s_more_than_one_way_to_do_it" rel="noreferrer">TIMTOWTDI</a> in language design.</p>
  
  <p>For giving the first and highest-voted answer, I award the bounty to L3viathan.</p>