You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
for clarification of the types and methods a backend has to implement, it would be nice if pyNN's interface would be defined by python's Abstract Base Classes. The corresponding PEP 3119 constitutes the usage of ABCs (among others) as
In addition, the ABCs define a minimal set of methods that establish the characteristic behavior of the type. Code that discriminates objects based on their ABC type can trust that those methods will always be present.
– which describes the requirement of all pyNN backends to behave similarly very well.
I see several advantages from such an architecture:
When implementing a new backend, it's very clear what (minimally) needs to be implemented – without the need for looking at calling code
If a feature is not implemented in one of the backends, a descriptive error of the instantiated class being abstract will be thrown by the interpreter
The official pyNN-API would be well defined in-code and not rely on conventions (functionality that every backend implements)
I am aware that implementing this concept might require refactoring of substantial parts of the codebase. This issue should therefore be understood as a suggestion for a potential enhancement of pyNN; it's in no way to be seen as a bug report.
Best,
Yannik
The text was updated successfully, but these errors were encountered:
Many thanks for creating this issue, @ystradmann. This is indeed one of the tasks we have planned before releasing PyNN 1.0, it is good to have an issue for it.
Hi,
for clarification of the types and methods a backend has to implement, it would be nice if pyNN's interface would be defined by python's Abstract Base Classes. The corresponding PEP 3119 constitutes the usage of ABCs (among others) as
– which describes the requirement of all pyNN backends to behave similarly very well.
I see several advantages from such an architecture:
I am aware that implementing this concept might require refactoring of substantial parts of the codebase. This issue should therefore be understood as a suggestion for a potential enhancement of pyNN; it's in no way to be seen as a bug report.
Best,
Yannik
The text was updated successfully, but these errors were encountered: