Dependency Injection (DI) is a software development approach. For Java developers, the Spring framework is a popular DI framework and it became a de-facto standard during enterprise business applications development. In this post, we discuss Python-based DI libraries.
Python Dependency Injection Libraries
Below is the list of Python-based DI frameworks/libraries.
| Module/Library Name | Last Released | Last Code Commit |
| pinject | Nov 27, 2018 | May 25, 2019 |
| dependency-injector | Aug 17, 2019 | |
| serum | Sep 7, 2018 | |
| injector | Jun 15, 2019 | |
| injectable | Feb 24, 2018 | |
| dependencies | Jul 21, 2018 |
My few cents on above libraries/modules
1. User forums of above libraries/modules are not active and some of the basic user’s questions are not yet answered
2. While some frameworks are active this year (like inejector, dependencies), I think, still code commits are not as frequent as expected for a Python developer (i.e. 1. frequent new feature additions, 2. catching up with Python or dependent library updates, 3. issue resolutions or support to developers in resolving their issues or answering to their questions and so on)
My Bias towards starting hands-on with these modules
1. Me coming from a strong Java Spring framework, I am biased with starting my hands-on with the “injectable” framework because it has @autowired with lazy attributes.
2. The only observation I made after studying the example code snippets in this framework website is, this “injectable” framework does things automatically and does not have a “container or application context” concept, unlike Java Spring Framework.
3. Having such a “container” runtime object even in Python dependency injection frameworks provides flexibility for the developers to add or remove Python class objects programmatically or runtime.
4. Problem with automatic behavior, without any “container” runtime object, is, developers will have a hard time debugging the code.
Next Action
Anyways I have decided to do hands-on of all the above dependency injection frameworks and will start with “injectable” framework.
About My Hands-On “Reference Application” and Point of Views
Python is used extensively for Data Science applications and I strongly feel Data Scientists should develop their model development Python code in the Object-Oriented Programming (OOP) approach (Python classes) and use Dependency Injection frameworks during OOP.
Below is a simple DataScience “reference application” expected to be developed in Python and in OOP way by using various DataScience libraries like scikit-learn, Tensorflow, Keras and others.
In this Python-based “reference application”, I expect Pandas, Numpy, Matploblib libraries should be freely used (i.e. no dependency injection) otherwise the “reference application” code becomes over-engineered.
I feel Pandas, Numpy, Matplotlib libraries should become soon native packages/modules in Python and developers should not put any effort into importing them into the codebase once these 3 libraries become natively available (i.e. developers should use them directly just like Python “print” functions (without import statements).
Reference Data Science Application Requirement Definition and Structure
Since objective of all the exercises in the context of this post (and its follow-up posts) is to assess the “dependency injection” frameworks usage during Data Science work, I defined a simple requirement i.e. “Performing Natural Language Processing (NLP) on a corpus of textual healthcare documents that are freely available in the internet”
Object-Oriented Programming Structure for the above “reference application”
(in the below structure, folder/package names are assumed to be Python modules or component names in the context of Java developer 🙂 )
(ioc means -> Inversion of Control)
(dao means -> Data Access Object)
(ds_pipeline means -> data science pipeline)
1. finance_text_analysis_app/MainApplication.py (similar to Main.java class in Java)
2. ioc/Container.py (similar to ApplicationContext.java in Spring framework class)
3. dao/DataLoader.py (similar to DAO design pattern in OOP)
4. dao/DataPersistor.py (similar to Broker design pattern in OOP)
5. ds_pipeline/FinDataModelerService.py (similar to service classes in Java applications)
6. ds_pipeline/pandas/SourceTextDataService.py (expects above DataLoader.py to be injected to read the data files from the disk)
7. ds_pipeline/tensorflow/SourceTextDataService.py (expects above DataLoader.py to be injected to read the data files from the disk)
7. ds_pipeline/keras/SourceTextDataService.py (same comments as above)
8. ds_pipeline/scikit-learn/SourceTextDataService.py (same comments as above)
and so on
(This is a Work In Progress post and an additional structure for the above points will be added soon)