Why is IoC DI not common in Python

Question

In Java IoC   DI is a very common practice which is extensively used in web applications  nearly all available frameworks and Java EE  On the other hand  there are also lots of big Python web applications  but beside of Zope  which I ve heard should be really horrible to code  IoC doesn t seem to be very common in the Python world   Please name some examples if you think that I m wrong    There are of course several clones of popular Java IoC frameworks available for Python  springpython for example  But none of them seems to get used practically  At least  I ve never stumpled upon a Django or sqlalchemy  lt insert your favorite wsgi toolkit here gt  based web application which uses something like that   In my opinion IoC has reasonable advantages and would make it easy to replace the django-default-user-model for example  but extensive usage of interface classes and IoC in Python looks a bit odd and not   pythonic    But maybe someone has a better explanation  why IoC isn t widely used in Python

User · Answer

I think due to the dynamic nature of python people don't often see the need for another dynamic framework. When a class inherits from the new-style 'object' you can create a new variable dynamically (https://wiki.python.org/moin/NewClassVsClassicClass).

i.e. In plain python:

#application.py
class Application(object):
    def __init__(self):
        pass

#main.py
Application.postgres_connection = PostgresConnection()

#other.py
postgres_connection = Application.postgres_connection
db_data = postgres_connection.fetchone()

However have a look at https://github.com/noodleflake/pyioc this might be what you are looking for.

i.e. In pyioc

from libs.service_locator import ServiceLocator

#main.py
ServiceLocator.register(PostgresConnection)

#other.py
postgres_connection = ServiceLocator.resolve(PostgresConnection)
db_data = postgres_connection.fetchone()

User · Answer

In my opinion  things like dependency injection are symptoms of a rigid and over-complex framework  When the main body of code becomes much too weighty to change easily  you find yourself having to pick small parts of it  define interfaces for them  and then allowing people to change behaviour via the objects that plug into those interfaces  That s all well and good  but it s better to avoid that sort of complexity in the first place   It s also the symptom of a statically-typed language  When the only tool you have to express abstraction is inheritance  then that s pretty much what you use everywhere  Having said that  C   is pretty similar but never picked up the fascination with Builders and Interfaces everywhere that Java developers did  It is easy to get over-exuberant with the dream of being flexible and extensible at the cost of writing far too much generic code with little real benefit  I think it s a cultural thing   Typically I think Python people are used to picking the right tool for the job  which is a coherent and simple whole  rather than the One True Tool  With A Thousand Possible Plugins  that can do anything but offers a bewildering array of possible configuration permutations  There are still interchangeable parts where necessary  but with no need for the big formalism of defining fixed interfaces  due to the flexibility of duck-typing and the relative simplicity of the language

User · Answer

Django makes great use of inversion of control   For instance  the database server is selected by the configuration file  then the framework provides appropriate database wrapper instances to database clients   The difference is that Python has first-class types   Data types  including classes  are themselves objects   If you want something to use a particular class  simply name the class   For example   if config dbms name     postgresql       import psycopg     self database interface   psycopg elif config dbms name     mysql             Later code can then create a database interface by writing   my db connection   self database interface     Do stuff with database    Instead of the boilerplate factory functions that Java and C   need  Python does it with one or two lines of ordinary code   This is the strength of functional versus imperative programming

User · Answer

IoC DI is a design concept  but unfortunately it s often taken as a concept that applies to certain languages  or typing systems   I d love to see dependency injection containers become far more popular in Python  There s Spring  but that s a super-framework and seems to be a direct port of the Java concepts without much consideration for  The Python Way    Given Annotations in Python 3  I decided to have a crack at a full featured  but simple  dependency injection container  https   github com zsims dic   It s based on some concepts from a  NET dependency injection container  which IMO is fantastic if you re ever playing in that space   but mutated with Python concepts

User · Answer

It seens that people really dont get what Dependency injection and inversion of control means anymore   The practice of using inversion of control is to have classes or function that depends of another classes or functions  but instead of creating the instances whithin the class of function code it is better to receive it as a parameter  so loose coupling can be archieved  That has many benefits as more testability and to archieve the liskov substitution principle   You see  by working with interfaces and injections  your code gets more maintanable  since you can change the behavior easily  because you won t have to rewrite a single line of code  maybe a line or two on the DI configuration  of your class to change it s behavior  since the classes that implements the interface your class is waiting for can vary independently as long as they follow the interface  One of the best strategies to keep code decoupled and easy to maintain is to follow at least the single responsability  substitution and dependency inversion principles   Whats a DI library good for if you can instantiate a object yourself inside a package and import it to inject it yourself  The chosen answer is right  since java has no procedural sections  code outside of classes   all that goes into boring configuration xml s  hence the need of a class to instantiate and inject dependencies on a lazy load fashion so you don t blow away your performance  while on python you just code the injections on the  procedural   code outside classes  sections of your code

User · Answer

Unlike the strong typed nature in Java   Python s duck typing behavior makes it so easy to pass objects around     Java developers are focusing on the constructing the class strcuture and relation between objects  while keeping things flexible   IoC is extremely important for achieving this   Python developers are focusing on getting the work done   They just wire up classes when they need it   They don t even have to worry about the type of the class   As long as it can quack  it s a duck   This nature leaves no room for IoC

User · Answer

My 2cents is that in most Python applications you don t need it and  even if you needed it  chances are that many Java haters  and incompetent fiddlers who believe to be developers  consider it as something bad  just because it s popular in Java   An IoC system is actually useful when you have complex networks of objects  where each object may be a dependency for several others and  in turn  be itself a dependant on other objects  In such a case you ll want to define all these objects once and have a mechanism to put them together automatically  based on as many implicit rules as possible  If you also have configuration to be defined in a simple way by the application user administrator  that s an additional reason to desire an IoC system that can read its components from something like a simple XML file  which would be the configuration    The typical Python application is much simpler  just a bunch of scripts  without such a complex architecture  Personally I m aware of what an IoC actually is  contrary to those who wrote certain answers here  and I ve never felt the need for it in my limited Python experience  also I don t use Spring everywhere  not when the advantages it gives don t justify its development overhead    That said  there are Python situations where the IoC approach is actually useful and  in fact  I read here that Django uses it   The same reasoning above could be applied to Aspect Oriented Programming in the Java world  with the difference that the number of cases where AOP is really worthwhile is even more limited

User · Answer

IoC and DI are super common in mature Python code  You just don t need a framework to implement DI thanks to duck typing   The best example is how you set up a Django application using settings py      settings py CACHES          default              BACKEND    django redis cache RedisCache            LOCATION   REDIS URL     1               local              BACKEND    django core cache backends locmem LocMemCache            LOCATION    snowflake             Django Rest Framework utilizes DI heavily    class FooView APIView         The  injected  dependencies      permission classes    IsAuthenticated        throttle classes    ScopedRateThrottle        parser classes    parsers FormParser  parsers JSONParser  parsers MultiPartParser      renderer classes    renderers JSONRenderer        def get self  request   args    kwargs           pass      def post self  request   args    kwargs           pass   Let me remind  source        Dependency Injection  is a 25-dollar term for a 5-cent concept        Dependency injection means giving an object its instance variables

User · Answer

I back  J  rg W Mittag  answer   The Python implementation of DI IoC is so lightweight that it completely vanishes    To back up this statement  take a look at the famous Martin Fowler s example ported from Java to Python  Python Design Patterns Inversion of Control  As you can see from the above link  a  Container  in Python can be written in 8 lines of code   class Container      def   init   self  system data           for component name  component class  component args in system data              if type component class     types ClassType                  args    self   dict   arg  for arg in component args                  self   dict   component name    component class  args              else                  self   dict   component name    component class

User · Answer

Actually  it is quite easy to write sufficiently clean and compact code with DI  I wonder  will it be stay pythonic then  but anyway       for example I actually perefer this way of coding   def polite name str       return  dear     name str  def rude name str       return name str      you  moron   def greet name str  call polite       print  Hello      call name str              gt  gt greet  Peter   Hello  dear Peter   gt  gt greet  Jack   rude  Hello  Jack  you  moron    Yes  this can be viewed as just a simple form of parameterizing functions classes  but it does its work  So  maybe Python s default-included batteries are enough here too   P S  I have also posted a larger example of this naive approach at Dynamically evaluating simple boolean logic in Python

User · Answer

I agree with  Jorg in the point that DI IoC is possible  easier and even more beautiful in Python  What s missing is the frameworks supporting it  but there are a few exceptions  To point a couple of examples that come to my mind    Django comments let you wire your own Comment class with your custom logic and forms   More Info  Django let you use a custom Profile object to attach to your User model  This is not completely IoC but is a good approach  Personally I d like to replace the hole User model as the comments framework does   More Info

User · Answer

Part of it is the way the module system works in Python   You can get a sort of  singleton  for free  just by importing it from a module   Define an actual instance of an object in a module  and then any client code can import it and actually get a working  fully constructed   populated object   This is in contrast to Java  where you don t import actual instances of objects   This means you are always having to instantiate them yourself   or use some sort of IoC DI style approach    You can mitigate the hassle of having to instantiate everything yourself by having static factory methods  or actual factory classes   but then you still incur the resource overhead of actually creating new ones each time

User · Answer

I don t actually think that DI IoC are that uncommon in Python  What is uncommon  however  are DI IoC frameworks containers  Think about it  what does a DI container do  It allows you to  wire together independent components into a complete application         at runtime   We have names for  quot wiring together quot  and  quot at runtime quot    scripting dynamic  So  a DI container is nothing but an interpreter for a dynamic scripting language  Actually  let me rephrase that  a typical Java  NET DI container is nothing but a crappy interpreter for a really bad dynamic scripting language with butt-ugly  sometimes XML-based  syntax  When you program in Python  why would you want to use an ugly  bad scripting language when you have a beautiful  brilliant scripting language at your disposal  Actually  that s a more general question  when you program in pretty much any language  why would you want to use an ugly  bad scripting language when you have Jython and IronPython at your disposal  So  to recap  the practice of DI IoC is just as important in Python as it is in Java  for exactly the same reasons  The implementation of DI IoC however  is built into the language and often so lightweight that it completely vanishes   Here s a brief aside for an analogy  in assembly  a subroutine call is a pretty major deal - you have to save your local variables and registers to memory  save your return address somewhere  change the instruction pointer to the subroutine you are calling  arrange for it to somehow jump back into your subroutine when it is finished  put the arguments somewhere where the callee can find them  and so on  IOW  in assembly   quot subroutine call quot  is a Design Pattern  and before there were languages like Fortran which had subroutine calls built in  people were building their own  quot subroutine frameworks quot   Would you say that subroutine calls are  quot uncommon quot  in Python  just because you don t use subroutine frameworks   BTW  for an example of what it looks like to take DI to its logical conclusion  take a look at Gilad Bracha s Newspeak Programming Language and his writings on the subject   Constructors Considered Harmful Lethal Injection A Ban on Imports  continued

User · Answer

pytest fixtures all based on DI  source

User · Answer

Haven t used Python in several years  but I would say that it has more to do with it being a dynamically typed language than anything else  For a simple example  in Java  if I wanted to test that something wrote to standard out appropriately I could use DI and pass in any PrintStream to capture the text being written and verify it  When I m working in Ruby  however  I can dynamically replace the  puts  method on STDOUT to do the verify  leaving DI completely out of the picture  If the only reason I m creating an abstraction is to test the class that s using it  think File system operations or the clock in Java  then DI IoC creates unnecessary complexity in the solution

[python] Why is IoC / DI not common in Python?

Examples related to python

Examples related to design-patterns

Examples related to dependency-injection

Examples related to inversion-of-control

Examples related to architecture