[libre-riscv-dev] [Bug 64] data handling / io control / data routing API needed

[bugzilla-daemon at libre-riscv.org]

http://bugs.libre-riscv.org/show_bug.cgi?id=64

--- Comment #20 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #8)

> >   the limitation of *all* data using *forcibly* being required
> >   to go through the "Data" class instance is also a burden that
> >   will result in significant user demands for "additional features"
> >   on the Data paradigm, to add support for unanticipated
> >   requirements.
> We can override __subclasshook__ like in collections.abc.Hashable:
> https://github.com/python/cpython/blob/
> 1b5f9c9653f348b0aa8b7ca39f8a9361150f7dfc/Lib/_collections_abc.py#L84
> 
> This makes any class that implements the 2 abstract functions to be a
> subclass of Data automatically (except that Data's methods won't be visible
> unless actually deriving from Data).

 https://stackoverflow.com/questions/40764347/python-subclasscheck-subclasshook

 this looks alarmingly complex.  i have learned the hard way that complex
 code that solves particularly difficult python problems using advanced
 features of python is REJECTED BY THE USERS.

 technically it is correct... yet because the features deployed are so
 hard to understand they simply do not trust it, as it requires extraordinary
 skill and intelligence to debug if it goes wrong.

 i can honestly say that detested it when this was quoted to me.

 crucially: if the data API is "an arbitrary nested generator that
 eventually yields derivatives of Value", i believe it would not
 be necessary to even use subclasscheck/hook.

 does the generator approach make sense?

-- 
You are receiving this mail because:
You are on the CC list for the bug.