4 ms·
I'd just call the function once by avoiding the global; construct your database access object at the start of your asynchronous main method and dependency injec
by alexchamberlain 6y ago
I'd just call the function once by avoiding the global; construct your database access object at the start of your asynchronous main method and dependency inject it to other tasks.
- orf 6y agoThis. Your code often becomes easier to read and test as well.
- np_tedious 6y agoCan you clarify what you mean by dependency injection in python? Did you mean a DI framework or something more informal? I've seen DI frameworks in python but not really used them. At a glance they don't strike me as pythonic. Rolling your own kind of inversion of control can result in unruly "config" or "context" objects that bring difficulties as well.
- oweiler 6y agoPass the fully constructed object as parameter. No need for a DI framework.
- idclip 6y agoI must say i havnt done any dependency injection in python. Did so in scala and JS though. So i assume he means initilize it once in program entry and Pass in the pointer to the object that needs it via including it the constructor or a function call. Do you think There’s a pythonic way of doing these things?
- fulafel 6y agoDI is just a convoluted synonym for passing in arguments.
- alexchamberlain 6y agoIndeed. If you want it to be cleaner, a discipline of constructor arguments for injection and __call__ arguments for semantic input is really all you need.
- danielscrubs 6y agoSo you’d block the thread and call it a day?
- dilatedmind 6y agoHis asyncpg example doesn't make much sense to me. What if there was a config change with a bad password? I would like to know this immediately on startup, else my rolling deploy is going to bring down all the previously well configured instances, and by the time we lazily try to connect to postgres it's too late. I'm not a big python user, but I do find it kind of surprising there isn't an awaitable and thread safe mutex in the stdlib.
- dtech 6y agoPython is highly opinionated towards single-threadeding, and the infamous GIL makes "true" multi-threading hard. Async and multi-threading has only recently gotten some love at all in the language and stdlib. I'd say single-threading is the right call for 99% of Python's use-cases and users. C extensions are available and widely used for core functionality that needs to be fast and/or parallel, e.g. large parts of numpy are in the c extension.