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
I've been using envparse package for a very long time, but discovered "environs" just moments ago. Your package is obviously better in many cases, but I really miss one feature from the old one: the global default Env class instance that can be imported by from envparse import env. I think it's really convenient to use and makes the code just a little bit neater than env = Env() (which is probably used like this in 99.9% of times).
What do you think about this feature? It shoud be possible to make it absolutely zero-cost by using some proper module-level __getattr__ trickery. Also, it would be perfect to have another "exported" instance that's equivalent to env = Env() + env.read_env().
The text was updated successfully, but these errors were encountered:
I wouldn't be opposed to exporting a singleton env. I wouldn't make it automatically run env.read_env(), though. I don't believe that would be an expected import side effect.
I've been using envparse package for a very long time, but discovered "environs" just moments ago. Your package is obviously better in many cases, but I really miss one feature from the old one: the global default
Env
class instance that can be imported byfrom envparse import env
. I think it's really convenient to use and makes the code just a little bit neater thanenv = Env()
(which is probably used like this in 99.9% of times).What do you think about this feature? It shoud be possible to make it absolutely zero-cost by using some proper module-level
__getattr__
trickery. Also, it would be perfect to have another "exported" instance that's equivalent toenv = Env()
+env.read_env()
.The text was updated successfully, but these errors were encountered: