Should a bare Link[T] annotation mean required, or optional?

[simontaurus]

Today a link annotation with no default means required at construction, matching what "no default" means everywhere else in Python (_descriptor.py#L190-L197):

father: Link["Person"]                            # required
father: Link["Person"] = OoldField()              # optional
father: Link["Person"] = OoldField(required=True) # required, explicit

The consequence is that the terse form is the one you almost never want for a link. Dropping OoldField() in examples/wiki_data.py breaks the ancestry walk:

ValueError: father is required but not set
  interface.resolve -> model_cls.from_jsonld -> import_jsonld -> model_cls(**jsonld_dict)

It fails five generations up, while resolving an ancestor whose Wikidata record has no P22 - not on the object you asked for. Resolution constructs target objects, so construction-requiredness propagates into every read, and a self-referential link can never be satisfied by a real dataset.

Link[T] is a promise about reading (it raises rather than returning a None the type denies, which is what makes person.father.father guard-free). Requiredness is about supplying. Two axes, and OoldField() currently exists to opt out of the second.

Options:

1. keep it - consistent with Python, at the cost of = OoldField() on nearly every link
2. invert it - a bare Link[T] is optional, OoldField(required=True) opts in. Reads better for links, diverges from Python

father: Link["Person"]                            # optional
father: Link["Person"] = OoldField()              # optional
father: Link["Person"] = OoldField(required=True) # required, explicit

3. something else
   @raederan @LukasOro @MatPoppFHG - which reads better to you in generated code?

[simontaurus]

Preliminary decission: Option 2

[MatPoppFHG]

Documentation of our discussion this morning:

for me, the expected code would look like:

father: Link["Person"]                                      # required
father: Optional[Link["Person"]] = None                     # optional
father: Optional[Link["Person"]] = Field(default=Link(....)) # optional

Difficulty: what if, in some_func(my_person.father.father.father), one .father cannot be resolved?
(Basic assumption: Real datasets are always incomplete.)

• An if / else guard is necessary for every element of the chain.

• Also conceivable: a = oold_resolve(my_person.father.father.father)

  • This does not work because the chain itself causes the problem: accessing .father on a potentially None value.
  • The type checker will still complain.
  • However, it is fundamentally correct that the type checker warns.
  • This is a problem of static typing + real datasets in general, not of oo-ld Python.
  • The Python program can still be executed.

• Can the exception from the . operator be overridden?

  • Yes, but the type checker does not know about it.

  • The type checker complains, but my_person.father.father.father can nevertheless be executed safely without an error if an intermediate step is None.

    • This corresponds to:

try:
    a = my_person.father.father.father
except AttributeError:
    a = None

Alternative Idea:

a = oold_resolve(my_person, chain = [Person.father, Person.father, Person.father]) 

• removes the advantage of the nice-looking and easy-to-write . syntax