[blurb] f-string simulation does not work with closures.

[JulienPalard]

In the throw function, the raise BlurbError(f("Error in {filename}:{line_number}:\n{s}")) can't find the filename variable leading to:

Traceback (most recent call last):
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 1691, in <module>
    main()
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 1651, in main
    sys.exit(fn(*filtered_args, **kwargs))
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 954, in add
    blurb.load(tmp_path)
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 553, in load
    self.parse(text, metadata=metadata, filename=filename)
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 543, in parse
    finish_entry()
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 495, in finish_entry
    throw("Blurb 'body' text must not be empty!")
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 486, in throw
    raise BlurbError(f("Error in {filename}:{line_number}:\n{s}"))
  File "/home/mdk/clones/core-workflow/blurb/blurb.py", line 138, in f
    return s.format_map(d)
KeyError: 'filename'

To reproduce it: invoke blurb, empty the buffer, and close the editor.

I don't think we should try to fix def f, maybe simple add nonlocal filename and nonlocal file_number so they become visible in the function locals.

[Mariatta]

GitMate.io thinks possibly related issues are #154 (blurb refuse to work without setting EDITOR env), #149 (pip install does not work for cherry_picker), python/devguide#324 (Building docs without make doesn't seem to work), python/blurb#2 (blurb does not support command line options in EDITOR/GIT_EDITOR), and #159 (Make blurb working in Python 3.5.).

[jaraco]

I ran into this issue also when implementing a similar function and I ended up creating namespace_format to format a string from the locals and globals. But maybe blurb should just use future-fstrings or just drop support for Python 3.5 (which is EOL anyway).

[JulienPalard]

Dropping Python 3.5 support looks the right way to me too.

[Mariatta]

I'm in favor of dropping 3.5 support. (#283)