<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Variaveis-De-Ambiente on Python Brasil — Aprenda Python em Português</title>
    <link>https://python.dev.br/tags/variaveis-de-ambiente/</link>
    <description>Recent content in Variaveis-De-Ambiente on Python Brasil — Aprenda Python em Português</description>
    <generator>Hugo</generator>
    <language>pt-br</language>
    <lastBuildDate>Sun, 31 May 2026 04:18:28 +0000</lastBuildDate>
    <atom:link href="https://python.dev.br/tags/variaveis-de-ambiente/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pydantic Settings: Configuração Segura em Python</title>
      <link>https://python.dev.br/blog/pydantic-settings-configuracao-python/</link>
      <pubDate>Sun, 31 May 2026 00:00:00 +0000</pubDate>
      <guid>https://python.dev.br/blog/pydantic-settings-configuracao-python/</guid>
      <description>&lt;p&gt;Configuração parece um detalhe pequeno até o primeiro deploy falhar porque uma variável de ambiente estava com nome errado, uma URL de banco veio vazia ou um token real foi parar no repositório. Em projetos Python, esse problema aparece em APIs com FastAPI, jobs de dados, automações internas, bots, CLIs, pipelines e aplicações que precisam rodar de forma diferente no notebook, no Docker, no CI e em produção.&lt;/p&gt;&#xA;&lt;p&gt;O erro comum é espalhar &lt;code&gt;os.getenv()&lt;/code&gt; pelo código inteiro. No começo funciona. Depois cada módulo passa a ler uma variável diferente, os valores não são validados, o padrão local vira comportamento implícito e ninguém sabe quais configurações são obrigatórias. Quando a aplicação cresce, configuração deixa de ser conveniência e vira contrato.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
