16.05.19 04:23, Victor Stinner пише:
The first implementation of my API used sys.unraisablehook(exc_type,
exc_value, exc_tb, obj). The problem is that Serhiy Storchaka asked me
to add a new error message field which breaks the API: the API is not
future-proof.
I modified my API to create an object to pack arguments. The new API
becomes sys.unraisablehook(unraisable) where unraisable has 4 fields:
exc_type, exc_value, exc_tb, obj. This API is now future-proof: adding
a new field will not break existing custom hooks!
I prefer the former design, when the hook takes 5 arguments: exc_type,
exc_value, exc_tb, obj and msg. Any additional human readable
information can be encoded in msg, and machine readable information can
be encoded in msg or obj. Currently we have no plans for adding more
details, and I do not think that we will need to do this in future.
Packing arguments into a single extendable object just complicates the
code and increases the chance of raising an exception or crashing.
Even obj and msg could be merged into a single object, and the hook
could check whether it is a string or callable. But passing them as
separate arguments is fine to me, I just think that no more complication
is necessary.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
