Corrigir erro psutil no Windows com 2 versões do Python
Leitura: ~18 min | Feito com Master Rules Claude v9.3
- O erro não é do psutil: o pip instalou a biblioteca no Python 3.8, e o script rodou em outro Python (o 3.15), que nunca a recebeu.
- O log traz duas provas: o caminho completo no traceback e a sugestão "Did you mean", que o Python 3.8 não gera.
- Rode sempre com py -3.8 script.py, instale com py -3.8 -m pip e, de vez, crie um ambiente virtual por projeto.
Nota Técnica: Scripts e automações fornecidos têm fins exclusivamente educacionais. Teste sempre em ambiente controlado. @CanalQb não se responsabiliza por danos, perdas ou bloqueios decorrentes do uso indevido.
O pip jura que o psutil está instalado, e o Python jura que ele não existe.
Os dois estão dizendo a verdade, e é isso que torna o erro tão irritante. Analisamos aqui o log real de uma sessão de terminal no Windows, em que o mesmo comando falhou, funcionou e voltou a falhar sem que nada fosse desinstalado.
Ao final você vai saber ler as pistas que o próprio Python deixa no traceback e vai ter um processo que impede a repetição do problema. Há ainda um detalhe do log que contradiz uma das dicas mais repetidas sobre esse erro.
Quais são as soluções rápidas para o erro do psutil no Windows?
Quase sempre a causa é um desencontro entre o Python que instalou o pacote e o Python que executou o script. A correção rápida é forçar os dois a usarem o mesmo interpretador, chamando o pip como módulo e rodando o script com a mesma versão, em vez de digitar apenas o nome do arquivo.
- Script só funciona com py -3.8: o nome solto usa outro Python. Rode py -3.8 script.py. ver passo completo
- pip diz "Requirement already satisfied": o pip é de outra versão. Use py -3.8 -m pip install psutil. ver passo completo
- Aviso de user installation: não é erro, é instalação na pasta do usuário. ver passo completo
- Comando python não reconhecido: o Python não está no PATH. Use o launcher py. ver passo completo
- Pip não acha versão compatível: a versão do Python é nova demais ou a rede bloqueia o PyPI. ver passo completo
Por que o psutil aparece instalado e mesmo assim o script não o encontra?
Porque o pip e o script usaram interpretadores diferentes. O psutil foi instalado na pasta de bibliotecas do Python 3.8, mas o script, ao ser executado pelo nome do arquivo, rodou em outro Python, que não enxerga essa pasta. A biblioteca existe; o interpretador que falhou é que nunca olhou para ela.
Para entender isso, vale desmontar o que o log da sessão realmente mostra. O pip respondeu que o psutil já estava satisfeito, apontando para a pasta Python38\site-packages dentro de AppData\Roaming. Logo depois, o mesmo script falhou com ModuleNotFoundError. Se as duas frases são verdadeiras ao mesmo tempo, só existe uma explicação: o pip e o script não são o mesmo Python. Reinstalar o pacote, como foi tentado mais de uma vez com --force-reinstall, não poderia resolver, porque o pacote nunca esteve ausente.
Há ainda uma prova técnica de que reinstalar era inútil. O arquivo baixado no log se chama psutil-7.2.2-cp37-abi3-win_amd64.whl. A etiqueta abi3 indica um pacote compilado contra a interface estável do Python, e a documentação do próprio projeto informa suporte ao CPython 3.6 em diante. Em termos práticos, a mesma roda serve para o 3.8 e para versões bem mais novas. Ou seja: se o psutil tivesse sido instalado no Python certo, funcionaria em qualquer um dos dois.
O traceback também entrega duas pistas sobre quem executou o script, e são pistas que quase ninguém lê:
- Caminho completo do arquivo. Nas falhas, o Python escreveu o caminho inteiro, com a letra do drive e a pasta do usuário. Na execução que funcionou com py -3.8, o traceback do KeyboardInterrupt mostra apenas o nome relativo do arquivo e a linha 194. Desde o Python 3.9, o arquivo principal passa a ter caminho absoluto, então o formato completo sugere um interpretador mais novo que o 3.8.
- Sugestão "Did you mean: 'pkgutil'?". As sugestões de nomes parecidos só existem em versões mais recentes do Python. O 3.8 simplesmente imprime a mensagem seca. Quem sugeriu o pkgutil foi, portanto, o Python mais novo da máquina.
- Saída do py -0p. O asterisco marca o 3.15 como padrão do launcher, e o caminho pythoncore-3.15-64 dentro de AppData\Local\Python é o formato do gerenciador de instalação mais novo do Windows.
Essas três pistas não substituem um teste, mas apontam na mesma direção. Na próxima seção você vai ver por que o Windows escolheu o Python errado justamente quando o arquivo foi chamado sem nenhum comando na frente.
Como o Windows escolhe o Python quando você digita só o nome do arquivo?
Quando você digita apenas possibilidades_X.py, o cmd não chama o python que está no PATH. Ele consulta a associação de arquivos da extensão .py e executa o programa cadastrado ali, que pode ser o launcher py ou diretamente um python.exe. Por isso o resultado pode diferir do comando python.
Esse é o ponto que mais confunde quem tem duas versões instaladas, porque existem três caminhos independentes para um script rodar no Windows, e cada um tem sua própria regra de escolha:
| Forma de executar | Quem decide o Python | Onde mexer |
|---|---|---|
| python script.py | A primeira pasta com python.exe na ordem do PATH, ou o gerenciador de instalação, conforme o que está instalado | Variável PATH |
| py script.py | O launcher: versão pedida na linha de comando, linha shebang do script, ambiente virtual ativo ou o padrão configurado | Configuração do launcher |
| script.py (só o nome) | A associação do tipo de arquivo .py no Windows | Aplicativos padrão ou comando ftype |
A especificação original do launcher, a PEP 397, explica o motivo de ele existir: ser o programa associado aos arquivos .py para que várias versões de Python convivam, escolhendo a versão pela linha shebang ou pelo padrão configurado. Já a documentação atual sobre Python no Windows descreve o gerenciador de instalação, que traz os comandos python, py e pymanager e diz que o padrão será a versão estável mais recente, a menos que você o altere por variável de ambiente ou arquivo de configuração.
Isso explica a armadilha do log: o python do cmd estava resolvendo para C:\Program Files\Python38, enquanto o launcher listava o 3.15 como padrão. Mesmo depois de a pessoa conseguir que o comando py --version devolvesse 3.8.10, o nome solto do arquivo continuou falhando. Isso mostra algo que a maioria dos tutoriais ignora: acertar o padrão do py não garante que a associação .py use esse padrão. A associação pode apontar direto para outro executável.
Há também a linha shebang. Se a primeira linha do script começar com algo como #!python3, o launcher respeita esse pedido antes do padrão. Então três lugares podem desempatar: o shebang, o padrão do launcher e a associação. Diagnosticar significa olhar os três, nessa ordem, e é exatamente o que a próxima seção faz.
Como descobrir qual Python está realmente executando o seu script?
Peça ao próprio Python que se identifique. Imprimir sys.executable dentro do script mostra o interpretador real, e os comandos where, py -0p e ftype Python.File mostram, respectivamente, o que está no PATH, o que o launcher conhece e qual programa o Windows associou aos arquivos .py.
Siga a sequência abaixo no cmd, dentro da pasta do projeto. Cada passo responde a uma pergunta diferente, e juntos eles fecham o diagnóstico sem depender de suposição.
- Liste os Pythons visíveis pelo PATH. Execute o comando abaixo para ver todos os python.exe que o cmd encontra, na ordem em que eles são consultados. O primeiro da lista é o que responde quando você digita python. Você deve ver pelo menos uma linha com C:\Program Files\Python38\python.exe. Erro comum: aparecer também um python.exe em WindowsApps, que é o atalho da loja da Microsoft e pode abrir a loja em vez de rodar o Python.
where python where py - Liste os Pythons conhecidos pelo launcher. O comando py -0p mostra cada versão registrada e marca com asterisco a que o py usa quando nenhuma é pedida. Ele existe para você enxergar o conflito, já que o asterisco no 3.15 contra o python do PATH no 3.8 é exatamente a divergência do caso analisado. Se o launcher for o gerenciador novo, o comando py list traz a mesma informação em formato de tabela.
py -0p py list - Descubra o programa associado aos arquivos .py. Os dois comandos abaixo mostram, primeiro, o tipo de arquivo ligado à extensão e, depois, o executável que abre esse tipo. É aqui que o mistério costuma se resolver, porque a linha pode apontar para py.exe, para um python.exe específico ou para outro aplicativo. Resultado esperado: algo como Python.File seguido do caminho de um executável entre aspas.
assoc .py ftype Python.File - Faça o script se identificar. Adicione estas duas linhas no topo do arquivo, antes do import psutil. Elas imprimem o executável e a versão que estão rodando de verdade, o que elimina qualquer dúvida. Se a saída mostrar a pasta pythoncore-3.15-64, você acabou de provar que o script não rodou no 3.8. O erro comum aqui é colocar o print depois do import, caso em que a falha ocorre antes de ele aparecer.
import sys print("Python em uso:", sys.executable, sys.version)
Com esses quatro resultados na mão, você sabe qual Python o script usa, qual o pip usa e qual o launcher prefere. Sem essa tabela mental, qualquer correção é tentativa e erro. Com ela, o caminho até a solução fica curto, e a seção seguinte aplica a correção imediata.
Qual é a correção imediata para o erro ModuleNotFoundError do psutil?
A correção imediata é usar o mesmo interpretador para instalar e para executar. Instale com py -3.8 -m pip install psutil e rode com py -3.8 script.py. Assim, pip e script ficam presos à mesma versão e a pasta de bibliotecas consultada é sempre a mesma.
Esse é o padrão que o log já provou funcionar: depois de executar py -3.8 possibilidades_X.py, o programa imprimiu o uso de memória, entrou no processamento e só parou porque a pessoa pressionou Ctrl+C. O psutil nunca foi o problema. Veja o procedimento completo, já com as verificações:
- Instale o pacote pelo módulo do interpretador certo. O formato py -3.8 -m pip chama o pip que pertence ao Python 3.8, e não um pip qualquer encontrado no PATH. Isso importa porque o executável pip.exe é um atalho que pode pertencer a outra versão, e a documentação da comunidade chama atenção para esse risco. O resultado esperado é a linha Successfully installed psutil ou Requirement already satisfied. Erro comum: esquecer o -m e cair de novo no pip do PATH.
py -3.8 -m pip install psutil - Teste a importação no mesmo interpretador. Antes de executar o programa grande, confirme com uma linha curta que o módulo carrega e informa a versão. O teste isola a instalação do resto do código, de modo que, se ele passar, qualquer erro seguinte não tem relação com o psutil. Você deve ver apenas o número da versão, como 7.2.2. Se aparecer ModuleNotFoundError aqui, a instalação realmente falhou.
py -3.8 -c "import psutil; print(psutil.__version__)" - Execute o script com a mesma versão. Agora rode o arquivo pedindo explicitamente o 3.8 ao launcher. Isso contorna a associação de arquivos e o padrão do py ao mesmo tempo, porque a versão foi dita na própria linha de comando, que sempre vence. A primeira saída deve ser a linha de memória inicial do seu programa. Erro comum: digitar só o nome do arquivo por hábito, o que reabre o problema.
py -3.8 possibilidades_X.py
Se você usa o gerenciador de instalação mais novo e o comando py -3.8 recusar a versão, rode py list para ver o nome exato registrado e use essa mesma etiqueta. A regra de ouro vale para qualquer versão: o número que você digita no -m pip e o número do script precisam ser iguais.
Como deixar o Python 3.8 como padrão no Windows?
Há três ajustes independentes: colocar as pastas do 3.8 antes das outras no PATH para o comando python, definir o padrão do launcher para o comando py e corrigir a associação dos arquivos .py. Fazer só um deles resolve apenas um dos três caminhos de execução.
A dica mais repetida para esse problema é criar o arquivo py.ini com python=3.8 dentro de %LOCALAPPDATA%. Ela é correta para o launcher clássico, descrito na PEP 397, que lê esse arquivo e também as variáveis PY_PYTHON e PY_PYTHON3. Porém o caso analisado tinha um launcher mais moderno, e a documentação do gerenciador de instalação aponta outro mecanismo: a variável PYTHON_MANAGER_DEFAULT ou um arquivo de configuração próprio dele. Use a tabela abaixo para escolher a ferramenta que combina com o seu cenário.
| Objetivo | Launcher clássico | Gerenciador de instalação novo |
|---|---|---|
| Padrão do comando py | py.ini com python=3.8 ou variável PY_PYTHON | Variável PYTHON_MANAGER_DEFAULT ou arquivo de configuração do gerenciador |
| Padrão do comando python | Ordem das pastas no PATH | Ordem das pastas no PATH e o padrão do gerenciador |
| Script aberto pelo nome | Associação .py apontando para py.exe | Associação .py conferida com ftype |
Para a variável de ambiente, o caminho é simples. Abra o diálogo de variáveis de ambiente do Windows, crie uma variável de usuário chamada PYTHON_MANAGER_DEFAULT com o valor 3.8, feche o cmd e abra de novo. Depois teste com py --version. Verifique o nome do arquivo de configuração e as opções disponíveis na página oficial Using Python on Windows, porque elas mudam entre versões do gerenciador e o ideal é conferir a sua instalação com py help.
Para o PATH, o ponto mais importante é a ordem: as duas pastas do 3.8 (a raiz e a subpasta Scripts) precisam aparecer acima das pastas de qualquer outra versão. Lembre que o PATH do usuário é lido antes do PATH do sistema em alguns cenários, então olhe os dois. Depois de salvar, é obrigatório abrir um novo terminal, porque terminais já abertos guardam uma cópia antiga das variáveis.
Um aviso honesto: mudar padrão global afeta todos os seus projetos. Se um deles precisa do 3.15, ele vai quebrar. Por isso, a última seção do corpo recomenda ambientes virtuais, que dispensam a briga pelo padrão.
Como corrigir a associação dos arquivos .py para executar pelo nome?
Abra Configurações, vá em Aplicativos padrão, procure a extensão .py e escolha o aplicativo desejado. Se ele não listar o Python 3.8, use o comando ftype para apontar a associação direto para o python.exe da pasta C:\Program Files\Python38, ou para o launcher py.
Corrigir a associação resolve o caso de digitar apenas o nome do arquivo ou de dar duplo clique nele, que é exatamente o fluxo que falhou no log. Há duas formas de fazer, e a escolha depende de você querer fixar uma versão ou delegar a escolha ao launcher.
- Pelo painel do Windows. Em Configurações, abra Aplicativos, depois Aplicativos padrão e use a busca por tipo de arquivo com a extensão .py. O painel permite escolher o programa que abre esse tipo. Resultado esperado: o nome do aplicativo escolhido aparece ao lado de .py. Erro comum: o Python 3.8 não aparecer na lista, pois instaladores mais antigos nem sempre se registram como aplicativo; nesse caso, escolha Procurar outro aplicativo e aponte o executável manualmente.
- Pelo comando ftype. Num cmd aberto como administrador, o comando abaixo redefine o que abre os arquivos do tipo Python.File. O trecho %1 recebe o arquivo e %* repassa os argumentos, e sem eles o script abriria sem receber nada. Ele altera uma configuração do sistema, então anote o valor original mostrado por ftype Python.File antes de trocar, para poder desfazer.
ftype Python.File="C:\Program Files\Python38\python.exe" "%1" %* - Pela linha shebang do script. Em vez de mexer no sistema, escreva na primeira linha do arquivo o pedido de versão. O launcher lê essa linha e escolhe o interpretador, desde que a associação passe pelo launcher. A linha vale somente quando o launcher é quem abre o arquivo; se a associação apontar direto para um python.exe, a linha será ignorada como simples comentário.
#!python3.8
Depois de qualquer um dos três ajustes, repita o teste da quarta etapa do diagnóstico: o print de sys.executable precisa mostrar a pasta Python38. Se mostrar, a associação foi corrigida. Se continuar mostrando outra pasta, volte ao ftype e confira qual executável ele aponta.
Como fazer o script avisar claramente quando falta uma dependência?
Envolva o import em um bloco try/except ImportError e imprima o interpretador em uso junto com o comando exato de instalação. Assim, a falha deixa de ser um traceback genérico e vira uma mensagem que diz qual Python rodou e como instalar o pacote nele.
O traceback original apontava para a linha do import, mas não dizia o que importava de verdade: qual Python estava ativo. Você pode transformar o erro em instrução. O bloco abaixo tenta importar o psutil e, se falhar, imprime o caminho do executável, a versão e o comando que instala o pacote especificamente naquele interpretador, usando o próprio caminho do executável para não haver ambiguidade.
import sys
try:
import psutil
except ImportError:
print("psutil nao encontrado neste Python:")
print(" executavel:", sys.executable)
print(" versao:", sys.version.split()[0])
print("Instale com:")
print(' "{}" -m pip install psutil'.format(sys.executable))
sys.exit(1)Repare no detalhe do comando impresso: ele usa o caminho completo de sys.executable entre aspas, e isso é o mais seguro possível, pois a instalação vai para o interpretador que acabou de falhar, sem depender de PATH, launcher ou associação. Se o caminho tiver espaços, como em Program Files, as aspas são obrigatórias, e por isso o código as inclui.
Esse padrão pode ser copiado para qualquer dependência opcional do seu projeto. Em programas maiores, vale listar as dependências em um arquivo requirements.txt e instalar tudo de uma vez com o mesmo formato py -3.8 -m pip install -r requirements.txt. Fixe versões que você testou, como psutil==7.2.2, para que o ambiente de amanhã seja igual ao de hoje.
Uma observação sobre compatibilidade: o projeto psutil declara suporte ao CPython a partir da 3.6, de modo que o 3.8 continua coberto. Quando você migrar um dia para uma versão muito nova do Python, confira na página do pacote no PyPI se já existe roda pronta para ela antes de culpar o seu código. Se não existir, o pip tentará compilar o pacote, e isso exige ferramentas de compilação no Windows.
Qual é a solução definitiva: ambiente virtual por projeto?
Crie um ambiente virtual dentro da pasta do projeto. Ele traz uma cópia isolada do interpretador e das bibliotecas, de modo que python e pip dentro dele sempre pertencem à mesma versão. Com o ambiente ativado, nenhum padrão do Windows interfere e o conflito entre 3.8 e 3.15 deixa de existir.
A documentação do launcher também prevê isso: com um ambiente virtual ativo, sem versão pedida e sem shebang, o padrão do py passa a ser o próprio ambiente. É o mecanismo que torna a vida previsível, e o procedimento é curto:
- Crie o ambiente com o Python desejado. Dentro da pasta do projeto, execute o comando abaixo uma única vez. Ele cria a pasta .venv com uma cópia do interpretador 3.8, e a escolha da versão acontece agora, de forma consciente, e fica gravada no ambiente. Resultado esperado: nenhuma mensagem de erro e uma nova pasta .venv.
py -3.8 -m venv .venv - Ative o ambiente. O script de ativação reconfigura o PATH da janela atual para colocar o Python do ambiente em primeiro lugar. O prompt passa a exibir (.venv) no início da linha, e esse é o sinal de que a ativação funcionou. Em PowerShell, o script pode ser bloqueado pela política de execução; no cmd isso não acontece.
.venv\Scripts\activate.bat - Instale e execute dentro do ambiente. Agora python e pip são do mesmo lugar, então o formato curto é seguro. Instale o psutil e rode o programa normalmente. Confirme com python -c "import sys; print(sys.executable)": o caminho deve terminar em .venv\Scripts\python.exe. Erro comum: abrir um terminal novo e esquecer de ativar de novo.
python -m pip install psutil python possibilidades_X.py
Os limites: o ambiente vale só para aquele projeto e para a janela em que foi ativado, e a pasta .venv não deve ser copiada para outro computador, porque guarda caminhos absolutos. Para levar o projeto, leve o requirements.txt e recrie o ambiente no destino. Como custo, você gasta alguns segundos e alguns megabytes por projeto, em troca de nunca mais depender do padrão global do Windows.
O KeyboardInterrupt e a saída enorme no log têm relação com o erro?
Não. O KeyboardInterrupt apareceu porque o programa foi interrompido com Ctrl+C durante a gravação no banco SQLite, e a saída gigante é o resultado normal da geração de números. Esses trechos provam que o Python 3.8 e o psutil funcionavam, mas não indicam falha de instalação.
Vale ler esses trechos do log com calma, porque eles confirmam o diagnóstico. A execução com py -3.8 imprimiu a linha de memória inicial, anunciou o processador aleatório e começou a produzir longas linhas de números separados por ponto e vírgula. A parada veio na linha 194, dentro da chamada main, quando o código estava em conn.executemany, a operação do SQLite que grava muitos registros de uma vez. O nome KeyboardInterrupt indica que o usuário pressionou Ctrl+C, e não que o programa quebrou.
Há, porém, um ponto de atenção que não é erro, mas custa tempo e memória. Imprimir milhões de números no terminal deixa o programa lento, porque o console do Windows é bem mais lento que o processamento. Se a intenção é gravar no banco, considere reduzir a impressão, por exemplo mostrando um contador a cada alguns milhares de registros. Se a ideia do monitor de memória é acompanhar o consumo, o psutil já oferece o necessário, e a leitura da memória do processo atual pode ser feita com o objeto Process do próprio pacote.
Outro cuidado vale para a gravação em lote: o executemany sobre uma lista enorme guarda tudo na memória antes de gravar. Quando o volume é grande, grave em pedaços, confirmando a transação a cada bloco, e você terá dois ganhos: o consumo de memória fica estável e uma interrupção como a do log não perde todo o trabalho já feito. Isso é uma melhoria opcional do seu programa, e não tem relação com o erro do psutil.
O recado principal desta seção é de método: quando um log mostra falha e sucesso do mesmo código, compare as condições de execução antes de culpar o código. No caso analisado, a diferença era uma só, a versão do Python.
Perguntas frequentes sobre o erro do psutil com várias versões do Python
Por que o pip diz que o psutil já está instalado se o Python não o encontra?
Qual a diferença entre os comandos python, py e pip no Windows?
Preciso desinstalar uma das versões do Python para resolver o conflito?
A mensagem "Defaulting to user installation" significa que algo deu errado?
O psutil funciona nas versões mais novas do Python?
{Erros e Soluções}
Estes são os cinco erros mais frequentes quando duas versões do Python convivem no Windows. Em todos eles, a causa raiz é a mesma: uma ferramenta aponta para um interpretador e outra aponta para outro. Cada cartão traz a mensagem literal, a causa, a solução e como prevenir.
ModuleNotFoundError: No module named 'psutil'
Causa: o script rodou em um Python diferente daquele em que o pacote foi instalado, geralmente por causa da associação de arquivos .py ou do padrão do launcher.
Solução: rode py -3.8 -m pip install psutil e depois py -3.8 script.py. Para confirmar, imprima sys.executable no topo do script.
Prevenção: use um ambiente virtual por projeto e nunca dependa do nome solto do arquivo para executar.
Requirement already satisfied: psutil in c:\users\qb\appdata\roaming\python\python38\site-packages
Causa: o pip chamado pertence ao Python 3.8 e já encontrou o pacote na própria pasta. A mensagem é verdadeira para ele, mas diz nada sobre o interpretador que falhou.
Solução: leia o caminho da mensagem para descobrir a versão do pip (aqui, python38) e execute o script com essa mesma versão. Reinstalar com --force-reinstall não ajuda.
Prevenção: prefira sempre o formato py -3.8 -m pip, que deixa explícita a versão do pip.
Defaulting to user installation because normal site-packages is not writeable
Causa: a pasta global de bibliotecas fica em Program Files e exige permissão de administrador, então o pip instala para o usuário atual.
Solução: não há o que corrigir; é um aviso. Se quiser evitar a mensagem, instale dentro de um ambiente virtual, que sempre tem permissão de escrita.
Prevenção: use .venv por projeto e evite instalar bibliotecas na pasta global do Python.
'python' não é reconhecido como um comando interno ou externo, um programa operável ou um arquivo em lotes.
Causa: a pasta do Python não está no PATH da janela atual, ou o terminal foi aberto antes de a variável ser alterada.
Solução: abra um terminal novo depois de editar o PATH. Se ainda falhar, use o launcher com py -3.8, que não depende do PATH, ou chame o executável pelo caminho completo.
Prevenção: sempre feche e reabra o terminal após mexer em variáveis de ambiente e confira com where python.
ERROR: Could not find a version that satisfies the requirement psutil (from versions: none)
Causa: o pip não conseguiu listar versões do pacote. Os motivos comuns são falta de internet, proxy ou firewall bloqueando o PyPI, ou um pip muito antigo.
Solução: teste a conexão, atualize o pip com py -3.8 -m pip install --upgrade pip e tente de novo. Em rede corporativa, configure o proxy da sua empresa.
Prevenção: mantenha o pip atualizado em cada ambiente e registre as dependências em requirements.txt.
Gostou do passo a passo? Veja mais tutoriais no canal @CanalQb no YouTube e confie nos testes do blog canalqb.com.br.
Conformidade Global: As informações regulatórias refletem as legislações vigentes no momento da publicação. Leis de privacidade variam por jurisdição e estão em constante evolução. Consulte as autoridades locais de proteção de dados e o IAPP Global Privacy Directory. Este conteúdo não constitui aconselhamento jurídico.
Fontes e Referências
Fontes consultadas em 05/11/2026. Os comportamentos do gerenciador de instalação podem mudar entre versões, então confira sempre a documentação oficial da sua instalação.
- Documentação oficial: Using Python on Windows (gerenciador de instalação, comandos python, py e pymanager)
- PEP 397: Python launcher for Windows (associação de arquivos, shebang e py.ini)
- PEP 773: A Python Installation Manager for Windows
- PEP 486: Make the Python Launcher aware of virtual environments
- psutil no PyPI: versões e Pythons suportados
- Anúncio do psutil 7.2.2 (lista de rodas, incluindo cp37-abi3 para Windows)
- Adam Johnson: Use python -m pip everywhere
- Discussão da comunidade: como definir a versão padrão do Python no Windows 11
