Merge branch 'f/qa_improvements'

Closes #12.

* f/qa_improvements: (28 commits)
  [QA} Use f-strings where it is more readable
  [QA} Don’t evaluate log string unconditionally
  [Tr] Ignore modern Python bytecode directory
  [QA] Use modern Unicode quote characters
  [Tr] Fix formatting of NMEA symbols
  [Tr] Fix quoting of HTML output’s updated string
  [QA] Prefer '' for string quotes
  [QA] Use HTTPS for python.org links
  [Tr] Sync travis config across projects
  [Tr] Remove unnecessary metadata
  [Tr] Remove leftover Python 2 coverage workarounds
  [QA] Use HTTPS for github links in DOAP
  [QA] Update references for click dep
  [QA] Pretty print YAML files
  [QA] Remove leftover Python 2 imports
  Drop Python 3.5 support
  [QA] Don’t uppercase function-scoped variables
  [QA] Don’t use static strings with getattr
  [QA] Prefer generators over list comprehensions
  [QA] Don’t assert against True
  ...

.editorconfig

@@ -12,3 +12,6 @@ indent_size = 4
 
 [*.rst]
 max_line_length = 79
+
+[*.yml]
+indent_size = 2

.github/CONTRIBUTING.rst

@@ -8,8 +8,8 @@ want to convince me that your style is better.
 
 * `PEP 8`_, the style guide, should be followed where possible.
 * `PEP 257`_, the docstring style guide, should be followed at all times
-* While support for Python versions prior to v3.5 may be added in the future if
-  such a need were to arise, you are encouraged to use v3.5 features now.
+* While support for Python versions prior to v3.6 may be added in the future if
+  such a need were to arise, you are encouraged to use v3.6 features now.
 * All new classes and functions should be accompanied by new tests, and Sphinx_
   ``autodoc``-compatible descriptions.
 

.gitignore

@@ -1,9 +1,9 @@
 build/
 dist/
+__pycache__/
 upoints.egg-info/
 
 *.html
-*.py[co]
 .coverage
 .git_version
 .noseids

.travis.yml

@@ -1,16 +1,16 @@
 dist: xenial
-sudo: false
 language: python
 matrix:
-    fast_finish: true
+  fast_finish: true
 python:
-  - 3.5
-  - 3.6
-  - 3.7
-  - 3.8
+  - "3.6"
+  - "3.7"
+  - "3.8"
+sudo: required
+
 install:
-  - pip install -r extra/requirements.txt
   - pip install -r extra/requirements-test.txt
+  - pip install .
   - pip install coveralls
 script:
   - pytest -v tests

CONTRIBUTING.rst

@@ -16,6 +16,6 @@ want to convince me that your style is better.
 
 New examples for the ``doc`` directory are as appreciated as code changes.
 
-.. _PEP 8: http://www.python.org/dev/peps/pep-0008/
-.. _PEP 257: http://www.python.org/dev/peps/pep-0257/
+.. _PEP 8: https://www.python.org/dev/peps/pep-0008/
+.. _PEP 257: https://www.python.org/dev/peps/pep-0257/
 .. _Sphinx: http://sphinx.pocoo.org/

NEWS.rst

@@ -23,7 +23,7 @@ User-visible changes
 * Added support for route data in GPX files
 
 .. _pip: https://pypi.org/project/pip/
-.. _pep-3101: http://www.python.org/dev/peps/pep-3101/
+.. _pep-3101: https://www.python.org/dev/peps/pep-3101/
 .. _aaargh: https://pypi.org/project/aaargh/
 .. _expecter: https://pypi.org/project/expecter/
 .. _nose2: https://pypi.org/project/nose2/
@@ -32,20 +32,20 @@ User-visible changes
 -------------------
 
 * This is likely to be the *final* non-bugfix release before v1.0.0 is cut, if
-  you don't like how something works now is the time to speak up!
+  you don’t like how something works now is the time to speak up!
 * This package has been renamed ``upoints`` from ``earth_distance`` to better
-  reflect its usage, and as a bonus it is more compliant with PEP-8_'s naming
+  reflect its usage, and as a bonus it is more compliant with PEP-8_’s naming
   guidelines
 * Added support for a generic ``Point`` object container type
 * Support for reading OpenCellID_ exports
-* Can now use lxml_ for XML processing on systems where ``cElementTree`` isn't
+* Can now use lxml_ for XML processing on systems where ``cElementTree`` isn’t
   available
-* Python "egg" packages can now be built if setuptools_ is installed
+* Python “egg” packages can now be built if setuptools_ is installed
 
 .. _OpenCellID: http://opencellid.org/
 .. _lxml: http://codespeak.net/lxml/
 .. _setuptools: http://peak.telecommunity.com/DevCenter/setuptools
-.. _PEP-8: http://www.python.org/dev/peps/pep-0008/
+.. _PEP-8: https://www.python.org/dev/peps/pep-0008/
 
 0.10.0 - 2008-03-27
 -------------------

README.rst

@@ -11,7 +11,7 @@
 ``upoints`` is a collection of `GPL v3`_ licensed modules for working with
 points on Earth, or other near spherical objects.  It allows you to calculate
 the distance and bearings between points, mangle xearth_/xplanet_ data files,
-work with online UK trigpoint databases, NOAA_'s weather station database and
+work with online UK trigpoint databases, NOAA_’s weather station database and
 other such location databases.
 
 Previous versions of ``upoints`` were called ``earth_distance``, but the name
@@ -21,15 +21,15 @@ targeted at.
 Requirements
 ------------
 
-``upoints``'s only strict requirements beyond the Python_ standard library are
-aaargh_ and lxml_, and as such should run with Python 3.5 or newer.  If
+``upoints``’s only strict requirements beyond the Python_ standard library are
+click_ and lxml_, and as such should run with Python 3.6 or newer.  If
 ``upoints`` doesn't work with the version of Python you have installed, drop me
-a mail_ and I'll endeavour to fix it.
+a mail_ and I’ll endeavour to fix it.
 
 The module has been tested on many UNIX-like systems, including Linux and OS X,
 but it should work fine on other systems too.
 
-To run the tests you'll need pytest_.  Once you have pytest_ installed you can
+To run the tests you’ll need pytest_.  Once you have pytest_ installed you can
 run the tests with the following commands:
 
 .. code:: console
@@ -44,7 +44,7 @@ The simplest way to show how ``upoints`` works is by example, and here goes::
     >>> from upoints import point
     >>> Home = point.Point(52.015, -0.221)
     >>> Telford = point.Point(52.6333, -2.5000)
-    >>> print("%d kM, with an initial bearing of %d°"
+    >>> print('%d kM, with an initial bearing of %d°'
     ...       % (Home.distance(Telford), Home.bearing(Telford)))
     169 kM, with an initial bearing of 294°
 
@@ -67,7 +67,7 @@ I'd like to thank the following people who have contributed to ``upoints``.
 Patches
 '''''''
 
-* Cédric Dufour - ``edist.py``'s CSV import, and flight plan output
+* Cédric Dufour - ``edist.py``’s CSV import, and flight plan output
 * Thomas Traber - GPX support enhancements, Points filtering, and some cool
   usage scenarios
 
@@ -81,7 +81,7 @@ Ideas
 * Simon Woods
 
 If I've forgotten to include your name I wholeheartedly apologise.  Just drop me
-a mail_ and I'll update the list!
+a mail_ and I’ll update the list!
 
 API Stability
 -------------
@@ -106,7 +106,7 @@ be wrong.
 
 The ``upoints`` modules do not take flattening in to account, as in calculations
 based in most populated areas of the earth the errors introduced by ignoring the
-earth's flattening are quite small.  Future versions may change if the
+earth’s flattening are quite small.  Future versions may change if the
 limitation becomes an issue in real use.
 
 Although not really a limitation one should also be careful to use data sources
@@ -116,7 +116,7 @@ unusual to find data sources from the USA that specify longitudes west of
 Greenwich as positive for example.
 
 .. [#] A future release may include more standard output definitions, but there
-       is no intention to add "magic" data mangling.
+       is no intention to add “magic” data mangling.
 
 Bugs
 ----
@@ -130,15 +130,15 @@ reproduce the problem, or even better a patch!
 .. _GPL v3: http://www.gnu.org/licenses/
 .. _xearth: http://hewgill.com/xearth/original/
 .. _xplanet: http://xplanet.sourceforge.net/
-.. _Python: http://www.python.org/
+.. _Python: https://www.python.org/
 .. _geolocation and path cross: doc/geolocation_and_pathcross.html
 .. _xearth and path cross: doc/xearth_and_pathcross.html
 .. _Trigpointing and point.py: doc/trigpointing_and_point_py.html
 .. _Cities and cities.py: doc/python_cities.html
 .. _Pythons on a plane: doc/pythons_on_a_plane.html
 .. _NOAA: http://weather.noaa.gov/
 .. _mail: jnrowe@gmail.com
-.. _aaargh: https://pypi.org/project/aaargh/
+.. _click: https://pypi.org/project/click/
 .. _lxml: http://codespeak.net/lxml/
 .. _Sphinx: http://sphinx.pocoo.org/
 .. _pytest: https://pypi.org/project/pytest/

doc/conf.py

@@ -16,8 +16,6 @@
 # You should have received a copy of the GNU General Public License along with
 # upoints.  If not, see <http://www.gnu.org/licenses/>.
 
-from __future__ import print_function
-
 import os
 import sys
 from contextlib import suppress
@@ -69,6 +67,7 @@
 
 # Project information {{{
 project = 'upoints'
+
 author = 'James Rowe'
 copyright = f'2007-2020  {author}'
 
@@ -96,9 +95,8 @@
     ]
 
 with suppress(CalledProcessError):
-    proc = run(
-        ['git', 'log', '--pretty=format:%ad [%h]', '--date=short', '-n1'],
-        stdout=PIPE)
+    proc = run(['git', 'log', '--pretty=format:%ad [%h]', '--date=short',
+                '-n1'], stdout=PIPE)
     html_last_updated_fmt = proc.stdout.decode()
 
 html_baseurl = 'https://upoints.readthedocs.io/'
@@ -123,6 +121,12 @@
 coverage_write_headline = False
 # }}}
 
+# intersphinx extension settings
+intersphinx_mapping = {k: (v, os.getenv(f'SPHINX_{k.upper()}_OBJECTS'))
+                       for k, v in {
+                           'python': 'http://docs.python.org/',
+}.items()}
+
 # extlinks extension settings {{{
 extlinks = {
     'pypi': ('https://pypi.org/project/%s/', ''),

doc/edist.1.rst

@@ -19,11 +19,11 @@ DESCRIPTION
 -----------
 
 **edist** operates on one, or more, locations specified in various formats.  For
-example, a location string of "52.015;\-0.221" would be interpreted as
-52.015 degrees North by 0.221 degrees West, as would "52d0m54s N 000d13m15s W".
-Positive values can be specified with a "+" prefix, but it isn't required.
+example, a location string of “52.015;\-0.221” would be interpreted as
+52.015 degrees North by 0.221 degrees West, as would “52d0m54s N 000d13m15s W”.
+Positive values can be specified with a “+” prefix, but it isn't required.
 
-It is possible to use Maidenhead locators, such as "IO92" or "IO92va", for users
+It is possible to use Maidenhead locators, such as “IO92” or “IO92va”, for users
 who are accustomed to working with them.
 
 Users can maintain a local configuration file that lists locations with assigned

doc/geolocation_and_pathcross.rst

@@ -1,8 +1,8 @@
 Geolocation and path cross
 ==========================
 
-Spurred on by `Seemant's voyage`_ in to geoip_ for deciding on the location of
-users writing comments on his website I decided to have a look in to MaxMind's
+Spurred on by `Seemant’s voyage`_ in to geoip_ for deciding on the location of
+users writing comments on his website I decided to have a look in to MaxMind’s
 library with the intent of using it in a semi-private pathcross_-type
 application.  Unfortunately, it turns out it isn't all that simple but there is
 some fun to be had along the way.
@@ -34,8 +34,8 @@ a few interesting artefacts to be mulled over instead of doing Real Work™.
 How inaccurate?
 ---------------
 
-Using MaxMind's `Locate my IP`_ service, which presumably queries their largest
-and most current database to attract customers, I'm reported as being:
+Using MaxMind’s `Locate my IP`_ service, which presumably queries their largest
+and most current database to attract customers, I’m reported as being:
 
     =================== =========================
     Attribute           Data
@@ -57,8 +57,8 @@ that we really should be expecting any great accuracy with the data, because of
 the way IPs are assigned and used.
 
 Assuming that I would be happy with my location being reported as Telford, how
-inaccurate is the data?  In the context of path cross the question is "would
-I be likely to travel to Telford for a beer?"  Time to brush up on spherical
+inaccurate is the data?  In the context of path cross the question is “would
+I be likely to travel to Telford for a beer?”  Time to brush up on spherical
 trigonometry basics I guess.
 
 The data is reasonably correct in stating a location of N52.6333°; W2.5000° for
@@ -79,42 +79,42 @@ Too inaccurate?
     >>> from upoints import point
     >>> Home = point.Point(52.015, -0.221)
     >>> Telford = point.Point(52.6333, -2.5000)
-    >>> print("%i kM" % Home.distance(Telford))
+    >>> print('%i kM' % Home.distance(Telford))
     169 kM
 
 The script above tells us that the distance from my house to Telford is
 approximately 170 kM (just over 100 miles for those so inclined), given that
-result what is the answer to my question "would I be likely to travel to Telford
-for a beer?" Probably not.
+result what is the answer to my question “would I be likely to travel to Telford
+for a beer?” Probably not.
 
 The answer isn't that simple though.  Whereas I probably wouldn't travel
 170 kM for a beer with my good friend Danny(sorry Danny!), I would consider
 travelling 170 kM to meet up with Roger Beckinsale.  It isn't because Danny is
 bad company(quite the contrary), it is because I live eight kilometres from
-Danny's house and can pop round for a beer whenever the urge hits me.  Roger on
+Danny’s house and can pop round for a beer whenever the urge hits me.  Roger on
 the other hand lives on the Isle of Lewis, as far North West as the British
 Isles go, and I haven't seen him for a year or so.
 
 There is only one conclusion to draw from this:  Accuracy is in the eye of the
 beerholder(sorry!).  This conclusion has led me to implement some new features
 in our manual path cross tool, all based around the idea of relative proximity.
 
-The "average" location of a person is important when calculating whether your
-paths cross [3]_.  I'm not really interested in seeing when somebody who works
+The “average” location of a person is important when calculating whether your
+paths cross [3]_.  I’m not really interested in seeing when somebody who works
 at the same site as me is within twenty kilometres of me as it would clearly
-happen a lot, but I'd like to see when somebody visits from abroad or heads to
+happen a lot, but I’d like to see when somebody visits from abroad or heads to
 a show within perhaps thirty kilometres of my location.
 
 Your proximity alert
 --------------------
 
 I've hacked support for relative proximities in to our Haskell tool, but
 |modref| could be used as the basis to implement something similar in Python.
-Taking Seemant, who lives in Boston, Ma., as an example as it is his fault I'm
+Taking Seemant, who lives in Boston, Ma., as an example as it is his fault I’m
 playing with Python and geoip |modref| can tell us::
 
     >>> Seemant = point.Point(42, -71)
-    >>> print("%i kM" % Home.distance(Seemant))
+    >>> print('%i kM' % Home.distance(Seemant))
     5257 kM
 
 We now have to make a decision about the range for the proximity alert given
@@ -145,7 +145,7 @@ and email-only contact.
     72.51154203831521
 
 If we forget about the anomalies, and just take the square root as being correct
-I can populate the relationship for Seemant with a 73 kM limit.  I'm sure each
+I can populate the relationship for Seemant with a 73 kM limit.  I’m sure each
 person involved will have their own idea of what a reasonable limit would be, so
 that should be user defined.
 
@@ -166,14 +166,14 @@ Bonus
 -----
 
 Having already implemented the basic class and distance method, I figured I may
-as well add bearing calculation too.  It's only 4 lines of code, so why not?
+as well add bearing calculation too.  It’s only 4 lines of code, so why not?
 
 ::
 
-    >>> print("A heading of %i° will find the beers!" % Home.bearing(Telford))
+    >>> print('A heading of %i° will find the beers!' % Home.bearing(Telford))
     A heading of 294° will find the beers!
 
-.. [1] By "automatically updating" I mean simply a ping-and-forget service that
+.. [1] By “automatically updating” I mean simply a ping-and-forget service that
        listens for a user ID and location and updates the database.  My test
        code was a simple five line Python_ script, it literally reads
        a configuration file for the user ID and pings my server.
@@ -182,16 +182,16 @@ as well add bearing calculation too.  It's only 4 lines of code, so why not?
        zipcode correct as none of them apply here.
 
 .. [3] The implementation actually considers the mode, and not the average, in
-       calculating "home" locations.  It makes it less prone to errors when
-       people only report long distance changes, because the clustering isn't so
-       obvious.  If more people hosted a complete hCard_, we wouldn't even need
+       calculating “home” locations.  It makes it less prone to errors when
+       people only report long distance changes, because the clustering isn’t so
+       obvious.  If more people hosted a complete hCard_, we wouldn’t even need
        to calculate this.
 
-.. _Seemant's voyage: http://kulleen.org/seemant/blog/2007/apr/16/building-my-django-weblog-part3/
+.. _Seemant’s voyage: http://kulleen.org/seemant/blog/2007/apr/16/building-my-django-weblog-part3/
 .. _geoip: http://www.maxmind.com/geoip/api/c.shtml
 .. _pathcross: http://www.w3.org/wiki/PathCross
 .. _city: http://www.maxmind.com/app/city
-.. _Python: http://www.python.org/
+.. _Python: https://www.python.org/
 .. _Locate my IP: http://www.maxmind.com/app/locate_my_ip
 .. _UKFSN: http://www.ukfsn.org/
 .. _hCalendar: http://microformats.org/wiki/hcalendar

doc/index.rst

@@ -11,7 +11,7 @@
 |modref| is a collection of `GPL v3`_ licensed modules for working with points
 on Earth, or other near spherical objects.  It allows you to calculate the
 distance and bearings between points, mangle xearth_/xplanet_ data files, work
-with online UK trigpoint databases, NOAA_'s weather station database and other
+with online UK trigpoint databases, NOAA_’s weather station database and other
 such location databases.
 
 Previous versions of |modref| were called ``earth_distance``, but the name was