Improve lib.py.

[knutnergaard]

No description provided.

[knutnergaard]

Several of the BaseLib methods document list of str items as the only acceptable type for dict values. Since at least fontshell allows value to be of any type, I've changed the docs to reflect Any.

[knutnergaard]

Remaining errors after ae7328f to be collected in #775:

lib.py:34: error: Signature of "_reprContents" incompatible with supertype "BaseObject"  [override]
lib.py:34: note:      Superclass:
lib.py:34: note:          @classmethod
lib.py:34: note:          def _reprContents(cls) -> List[str]
lib.py:34: note:      Subclass:
lib.py:34: note:          def _reprContents(self) -> List[str]
lib.py:75: error: "BaseGlyph" not callable  [operator]
lib.py:80: error: "BaseGlyph" not callable  [operator]
lib.py:83: error: Incompatible types in assignment (expression has type "Callable[[], Any]", variable has type "Optional[BaseGlyph]")  [assignment]
lib.py:83: error: Argument 1 to "reference" has incompatible type "BaseGlyph"; expected "Callable[[], Any]"  [arg-type]
lib.py:112: error: "BaseFont" not callable  [operator]
lib.py:118: error: "BaseFont" not callable  [operator]
lib.py:123: error: Incompatible types in assignment (expression has type "Callable[[], Any]", variable has type "Optional[BaseFont]")  [assignment]
lib.py:123: error: Argument 1 to "reference" has incompatible type "BaseFont"; expected "Callable[[], Any]"  [arg-type]

[benkiel]

@typesupply are you ok with relaxing the value to be any type?

[knutnergaard]

normalizeLibValue also allows any type except None, btw.

[typesupply]

The value limitations in methods like __setitem__ are incorrect. The lib is constrained by the property list requirements. Keys must be strings. Values can be any type that can be written into a property list value. I recall that normalizing values was incredibly hard because determining if something can be converted to property list from the Python representation requires a ton of code. Property lists have no concept of "nothing", so None is always rejected.

[typesupply]

From plistlib:

Values can be strings, integers, floats, booleans, tuples, lists, dictionaries (but only with string keys), bytes, bytearray or datetime.datetime objects.

Maybe we could just point to the plistlib doc instead of enumerating everything ourselves. Or we could do what the UFO spec does and point to Apple's DTD.

[knutnergaard]

For the sake of clarity and explicitness, I suggest extending normalizeLibValue to accommodate/reject the types specified in the plistlib docs, and annotate BaseLib to reflect these changes, e.g., with LibValueType or similarly appropriate alias. Unless I'm misunderstanding, I don't see why this would require tons more code. The isinstance in the normalizer just has to evaluate a list of several types instead of just None.

[typesupply]

My concern back then with using isinstance was that there are many situations where the incoming object isn't an instance of the standard Python types, but behaves like one. My concern was primarily focused on environments that use Apple's AppKit (notably RoboFont). The values there returned by controls aren't automatically converted from the AppKit types (NSInteger, NSString, etc.) to their Python equivalents. I was worried about plistlib choking on these. (My memory is hazy, but I seem to recall this happening sometimes. It looks like PyObjC now handles isinstance for at least strings. Dictionaries still fail, but they would fail in plistlib so that's not a concern.) My plan way back in the day was to do the conversions manually inside of normalizeLibValue but that was a huge amount of work and I let plistlib do the validation on UFO write.

I just looked at the plistlib code and it does something similar to what you suggest: a sequence of isinstance tests. We could make LibValueType all of the types that plistlib tests for and use that in normalizeLibValue as you suggest.

Thanks for pressing on this!

[benkiel]

Yes, I agree with Tal; changing the validator to test for the accepted types (and recursively for dictionaries) is the thing to do here. Thank you @knutnergaard for pushing on this!

[knutnergaard]

My pressure!

Since I'm already working on BasLib, I can take a crack at the normalization and annotation improvements.

[knutnergaard]

@benkiel @typesupply I ended up referencing a new common value type type-lib-value in the documentation, rather than listing all the possible types. The TypeError in the normalizer does list all the types, though.

[benkiel]

@knutnergaard thank you for this!