{"@attributes":{"version":"2.0"},"channel":{"title":"DEV Community: Prayson Wilfred Daniel","description":"The latest articles on DEV Community by Prayson Wilfred Daniel (@proteusiq).","link":"https:\/\/dev.to\/proteusiq","image":{"url":"https:\/\/media2.dev.to\/dynamic\/image\/width=90,height=90,fit=cover,gravity=auto,format=auto\/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F123003%2F3f713759-b0fb-4baa-928c-1f2351eaf701.JPG","title":"DEV Community: Prayson Wilfred Daniel","link":"https:\/\/dev.to\/proteusiq"},"language":"en","item":[{"title":"TDD = Communicate + Connect + Craft","pubDate":"Sat, 15 Mar 2025 16:10:25 +0000","link":"https:\/\/dev.to\/proteusiq\/tdd-communicate-connect-craft-3ndn","guid":"https:\/\/dev.to\/proteusiq\/tdd-communicate-connect-craft-3ndn","description":"

\"meh\"<\/a><\/p>\n\n

\ud83e\udd8a Let us dispel a common misconception: the essence of Test-Driven Development(TDD) is not about the act of writing tests. <\/p>\n\n

True, when we emerge from the TDD process, we hold in our hands a suite of tests\u2014yet these are not the destination, but rather a byproduct of a far grander pursuit. <\/p>\n\n

The true aim of TDD is to serve as a compass, guiding us through the intricate journey of creation. It is the architectural blueprint guiding our path.<\/p>\n\n

TDD is a language of connection\u2014an invitation extended to fellow developers and stakeholders to step into the theater of our minds, to see the world as we envision it. <\/p>\n\n

It embodies a programming paradigm where the very design of our solutions emerges organically from the use cases we seek to address. <\/p>\n\n

Through this disciplined dance of code and intent, we craft not just software, but a shared understanding\u2014a harmony of purpose and execution.<\/p>\n\n

TDD is not a rule. It is a value. A value to help us find direction as a community. After all, coding is a community endeavour.<\/p>\n\n","category":"programming"},{"title":"python-dotenv will bite you. Watch out","pubDate":"Wed, 05 Mar 2025 21:22:48 +0000","link":"https:\/\/dev.to\/proteusiq\/python-dotenv-will-bite-you-watch-out-19od","guid":"https:\/\/dev.to\/proteusiq\/python-dotenv-will-bite-you-watch-out-19od","description":"

\n \n
\n \"proteusiq\"\n <\/div>\n <\/a>\n \n
\n

Why `load_dotenv()` Is an Anti-Pattern\u2014and How to Do Better<\/h2>\n

Prayson Wilfred Daniel \u30fb Mar 5<\/h3>\n
\n #python<\/span>\n #ai<\/span>\n #programming<\/span>\n <\/div>\n <\/div>\n <\/a>\n<\/div>\n\n\n","category":["python","ai","programming"]},{"title":"Why `load_dotenv()` Is an Anti-Pattern\u2014and How to Do Better","pubDate":"Wed, 05 Mar 2025 16:43:21 +0000","link":"https:\/\/dev.to\/proteusiq\/trending-anti-pattern-loading-environments-j55","guid":"https:\/\/dev.to\/proteusiq\/trending-anti-pattern-loading-environments-j55","description":"

\"No<\/a><\/p>\n\n

If you\u2019ve ever written from dotenv import load_dotenv; load_dotenv()<\/code> at the top of a Python script, you\u2019re not alone. It\u2019s a rite of passage for developers managing environment variables\u2014until it bites you. <\/p>\n\n

This little convenience from python-dotenv<\/code> promises to load your .env<\/code> file into os.environ<\/code> with minimal fuss, but beneath its simplicity lurks a mess of anti-patterns that clash with Python\u2019s core principles. <\/p>\n\n

It\u2019s implicit, fragile, and a maintenance nightmare. Let\u2019s tear it apart and build something better with Pydantic, python-decouple<\/code>, and good old os.getenv()<\/code>.<\/p>\n\n

\n \n \n The Sins of load_dotenv()<\/code>\n<\/h2>\n\n

\"Noob\"<\/a><\/p>\n\n

\n \n \n It\u2019s Un-Pythonic Magic\n<\/h3>\n\n

Python\u2019s Zen (PEP 20) chants \u201cexplicit is better than implicit,\u201d but load_dotenv()<\/code> is a sorcerer\u2019s trick. Call it, and it silently mutates os.environ<\/code>\u2014no meaningful return value, no clear signal of success. <\/p>\n\n

Did it find .env<\/code>?
\nDid it override existing vars? <\/p>\n\n

You\u2019re left guessing.<\/p>\n\n

With load_dotenv()<\/code>, you\u2019re stuck probing os.environ<\/code> to see what happened. That\u2019s not how Python rolls.<\/p>\n

\n \n \n No meaningful \"Return\", Just Side Effects\n<\/h3>\n\n

A good function gives you something back. load_dotenv()<\/code>? Meh! It returns boolean<\/code>. Is that useful? Nope. It alters global state like a rogue script kiddie. You call it, and your environment changes behind a curtain. <\/p>\n\n

Want to know what it loaded? Tough luck\u2014go fish in os.environ<\/code>. <\/p>\n\n

A Pythonic version might return a dict of loaded values, letting you<\/em> decide what to do next. Instead, it\u2019s a void that forces trust over transparency.<\/p>\n

\n \n \n It Breaks Single Responsibility\n<\/h3>\n\n

The Single Responsibility Principle says one function, one job. load_dotenv()<\/code> laughs at that. It locates .env<\/code>, parses it, decides override rules, and shoves everything into os.environ<\/code>\u2014all in one opaque blob. <\/p>\n\n

That\u2019s four responsibilities mashed together, making it brittle and hard to debug. A saner design would split those steps, but no, it\u2019s a monolith that does too much and hides too much.<\/p>\n

\n \n \n Fragile in Production\n<\/h3>\n\n

In dev, .env<\/code> files are cute. In production? They\u2019re a liability. Platforms like Docker or Heroku inject environment variables directly\u2014no file needed. load_dotenv()<\/code> ties you to a file-based workflow that falls apart outside your laptop. <\/p>\n\n

Worse, its order-dependence (call it too late, and imported modules miss the vars) turns your codebase into a timing puzzle. It\u2019s a dev crutch that doesn\u2019t scale.<\/p>\n

\n \n \n The Better Way: Three Pythonic Alternatives\n<\/h2>\n\n

\"Here<\/a><\/p>\n\n

Ditch the magic. Here are three solutions that respect Python\u2019s ethos, keep your code clean, and work from dev to prod.<\/p>\n

\n \n \n 1. Pydantic Settings: The Modern Powerhouse\n<\/h3>\n\n

Pydantic\u2019s BaseSettings<\/code> (or BaseModel<\/code> with settings config in 2.x) brings type safety and clarity to your config game.
\n<\/p>\n\n

\n
from<\/span> pydantic_settings<\/span> import<\/span> BaseSettings<\/span>\n\nclass<\/span> Settings<\/span>(<\/span>BaseSettings<\/span>):<\/span>\n    database_url<\/span>:<\/span> str<\/span>\n    api_key<\/span>:<\/span> str<\/span>\n\n    class<\/span> Config<\/span>:<\/span>\n        env_file<\/span> =<\/span> \"<\/span>.env<\/span>\"<\/span>  # Optional\n<\/span>\nsettings<\/span> =<\/span> Settings<\/span>()<\/span>\nprint<\/span>(<\/span>settings<\/span>.<\/span>database_url<\/span>)<\/span>\n<\/code><\/pre>\n\n<\/div>\n\n\n\n
Why It Rocks<\/strong>:<\/p>\n\n