Questions about Python object's lifecycle

Hi,

prompted by Andrew's comment [1], I'm looking now in more 
detail on how the lifecycle of Python objects whose lifetime 
is bound to either lifetime of an objfile or an arch. The idea
is to provide somewhat unified lifecycle management instead of
duplicating the same code over and over.

While the the general idea is clear, there are few details
that puzzle me:

1) For example, the typy_deleter reads: 

---
struct typy_deleter
{
  void operator() (type_object *obj)
  {
    if (!gdb_python_initialized)
      return;

    /* This prevents another thread from freeing the objects we're
       operating on.  */
    gdbpy_enter enter_py;
    ...
    while (obj)
    ...
---

The stpy_deleter reads:

---
struct stpy_deleter
{
  void operator() (symtab_object *obj)
  {
    while (obj)
    ...
---

In what situation the typy_deleter is invoked and
gdb_python_initialized is not true? And why typy_deleter
is guarded but stpy_deleter not? Seems to me that this can 
happen only when one creates gdb.Type object and if that 
happens, Python must be initialized, no?

Doing "gdbpy_enter enter_py;" in typy_deleter makes sense
to me but shouldn't stpy_deleter have the same protection?

2) Looking symtab_to_symtab_object (type_to_type_object) 
seems to expect that passed struct symbol * (struct type *)
may be NULL. In what cases this can happen? OTOH, 
symbol_to_symbol_object expects that passed down struct symbol *
is never NULL. 

3) gdb.Symtab_and_line holds on gdb.Symtab in addition to 
struct symtab_and_line *. Is that only to make sure accessing
symtab property of gdb.Symtab_and_line always gives the
same (identical) Python object? Or is there other reason?
Similar for gdb.Value holding on gdb.Type.

4) Bit unrelated, but in what cases a struct symbol * is objfile-owned
but struct symbol::symtab() returns NULL?

Thanks!

Jan

[1]: https://inbox.sourceware.org/gdb-patches/[email protected]/