Need a range with only one call number

[tdilauro]

I need to be able to support a range that contains a single call number, but I get the following traceback. Is there an implementation issue that would make such a range unsafe?

Traceback (most recent call last):
  File "/Users/timmo/.PyEnvs/python-NadIChSC/lib/python3.7/site-packages/pycallnumber/set.py", line 166, in __init__
    self._validate(start, end)
  File "/Users/timmo/.PyEnvs/python-NadIChSC/lib/python3.7/site-packages/pycallnumber/set.py", line 187, in _validate
    raise BadRange('The range\'s ``start`` argument must be less than '
pycallnumber.exceptions.BadRange: The range's ``start`` argument must be less than its ``end`` argument.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/timmo/Library/Application Support/JetBrains/Toolbox/apps/PyCharm-P/ch-0/182.4505.26/PyCharm.app/Contents/helpers/pydev/pydevd.py", line 1664, in <module>
    main()
  File "/Users/timmo/Library/Application Support/JetBrains/Toolbox/apps/PyCharm-P/ch-0/182.4505.26/PyCharm.app/Contents/helpers/pydev/pydevd.py", line 1658, in main
    globals = debugger.run(setup['file'], None, None, is_module)
  File "/Users/timmo/Library/Application Support/JetBrains/Toolbox/apps/PyCharm-P/ch-0/182.4505.26/PyCharm.app/Contents/helpers/pydev/pydevd.py", line 1068, in run
    pydev_imports.execfile(file, globals, locals)  # execute the script
  File "/Users/timmo/Library/Application Support/JetBrains/Toolbox/apps/PyCharm-P/ch-0/182.4505.26/PyCharm.app/Contents/helpers/pydev/_pydev_imps/_pydev_execfile.py", line 18, in execfile
    exec(compile(contents+"\n", file, 'exec'), glob, loc)
  File "/Users/Shared/src/git/gis/msel-collections/python/lookup.py", line 40, in <module>
    main()
  File "/Users/Shared/src/git/gis/msel-collections/python/lookup.py", line 18, in main
    lookup_table = sorted(lookup_rows, key=itemgetter(range))
  File "/Users/Shared/src/git/gis/msel-collections/python/lookup.py", line 28, in lookup_table_generator
    row['range'] = pycn.cnrange(start, end)
  File "/Users/timmo/.PyEnvs/python-NadIChSC/lib/python3.7/site-packages/pycallnumber/factories.py", line 81, in cnrange
    return rangesettype((start, end))
  File "/Users/timmo/.PyEnvs/python-NadIChSC/lib/python3.7/site-packages/pycallnumber/set.py", line 339, in __init__
    ranges.append(Range(*rg))
  File "/Users/timmo/.PyEnvs/python-NadIChSC/lib/python3.7/site-packages/pycallnumber/set.py", line 169, in __init__
    ''.format(start, end, e))
pycallnumber.exceptions.BadRange: The range AC5. S635 1972  QUARTO to AC5. S635 1972  QUARTO did not validate: The range's ``start`` argument must be less than its ``end`` argument.

Process finished with exit code 1

[jthomale]

Hi Tim,

In this circumstance, the error is raised to let you know you're creating an empty range. Pycallnumber ranges' bounds work the same way Python's built-in range function and list slices do, where the lower bound is part of the range but the upper bound is outside of it. With range, using the same lower bound and upper bound creates an empty list. E.g.:

>>> range(0, 1)
[0]
>>> range(0, 0)
[]

Since this isn't necessarily that intuitive for call number ranges, I thought doing that check and raising the error would be preferable to allowing empty ranges to be created accidentally.

The best way to do a range just containing that one call number is, e.g.:

>>> import pycallnumber as pycn
>>> r = pycn.cnrange('AC5.S635 1972 QUARTO', 'AC5.S635 1972 QUARTO A')
>>> pycn.callnumber('AC5.S635 1972 QUARTO') in r
True
>>> pycn.callnumber('AC5.S635 1972 QUARTOA') in r
False
>>> pycn.callnumber('AC5.S635 1972 QUARTO A') in r
False
>>> pycn.callnumber('AC5.S635 1972 QUARTO MORE TEXT') in r
False
>>> pycn.callnumber('AC5.S635 1972 QUARTP') in r
False

etc.

Would that work for you?

[tdilauro]

Thanks for the quick response, Jason.

First, yes! I definitely appreciate you throwing that exception. It would be exceedingly difficult to track that issue down, if you didn't.

W.r.t. to work-around, it would be really nice to be able to control whether the bounds are treated as open or closed. I'll have to give a little more thought to how to handle this. I'll come back and update this issue once I've had a chance to do that.

Thanks again.

[jthomale]

Absolutely! If you have (or find) a preferred way that that would work, it would be a useful feature to have.

To give you a little more context, the reason I implemented ranges using only exclusive upper bounds is because of issues I ran into when working on one of the projects that eventually led to pycallnumber. This project involved doing set-like operations (particularly unions and intersections) on LC call number ranges. And, because (most?) call number ranges can have an infinite number of call numbers between each increment, using an exclusive upper bound was the most elegant way to avoid the problem where you have to try to concretely define the upper bound on an infinite range.

For instance, on the LC website you have LC class ranges that are defined like this:

TA165
TA166 to TA167
TA168
etc.

... which I think are supposed to be contiguous ranges. And the way a lot of systems handle this is to implement closed ranges, like this:

TA165 to TA165.9999
TA166 to TA167.9999
TA168 to TA168.9999

... where there's a validation rule somewhere stipulating that you can have a maximum of four decimal places — which tells you these ranges are contiguous. But making that determination relies on that validation rule. Otherwise, the set between TA165 and TA166 is infinite (TA165.999999+), and, if you try to join the first with the second, you have a gap (TA165.99991 and up). But you can reflect the full, infinite ranges accurately without having any validation rules using exclusive upper bounds:

TA165 to TA166
TA166 to TA167
TA167 to TA168

With pycallnumber, which is meant to be a generalized implementation of library call numbers, this greatly simplifies things because we don't have to worry about having validation rules for each callnumber type telling it where those boundaries lie.

That said, if having the ability to define fully-inclusive ranges would be useful, then I support that; I just have trouble thinking of an implementation that would be simple and would work well with the existing one. It may be that the RangeSet features wouldn't work at all with inclusive ranges. (Which maybe would imply that we'd need a new class, parallel to Range.) I don't know—every time I think about it, what seems like a simple feature on the surface quickly turns ugly.

... I hope that explanation makes some sense (and I'm not way over-explaining). Thank you for spending some time thinking about this!