Qual versão do Python (2.4, 2.5, 2.6, 3.0) você padronizar para os esforços de desenvolvimento da produção (e porquê)?

Question

No nosso grupo nós fazemos principalmente procurar arquitetura do motor e do trabalho de integração de conteúdo e a maior parte desse código base é em Python. Todas as nossas ferramentas de compilação e Python dependências do módulo estão no controle de origem para que eles possam ser retirados e o ambiente carregado para uso independente de os / plataforma, meio semelhante à abordagem vIRTUALENV usos.

Por anos temos mantido uma base de código compatível com Python 2.3 porque um dos produtos comerciais que usamos depende Python 2.3. Ao longo dos anos esta tem causado mais e mais questões como novas ferramentas e bibliotecas precisam de novas versões do Python desde 2.3 saiu em ~ 2004.

Nós dissociado recentemente o nosso ambiente de construção de dependências no ambiente do produto comercial e pode usar qualquer versão do Python (ou Java) que queremos. Sua sido cerca de um mês ou assim desde que padronizou o Python 2.6 como a versão mais recente do Python, que é compatível com versões anteriores.

Python 3.0 não é uma opção (por agora), uma vez que teria que migrar muito de nossa base de código para tornar os nossos construção e ferramentas de integração para funcionar corretamente novamente.

Nós como muitos dos novos recursos do Python 2.6, especialmente os módulos melhoradas e coisas como decoradores de classe, mas muitos módulos que dependem causa o interpretador Python 2.6 a jorrar vários avisos de depreciação. Outra ferramenta que estamos interessados ??para gerenciar os nós do cluster EC2 nuvem, Supervisor nem sequer funciona corretamente com o Python 2.6.

Agora eu estou querendo saber se devemos padronizar em Python 2.5 para agora, em vez de usar o Python 2.6 em desenvolvimento de ferramentas do ambiente de produção. A maioria das ferramentas que quiser / precisar parecem funcionar corretamente com o Python 2.5. Estamos tentando resolver isso agora, antes que há muitas dependências em Python 2.6 recursos ou módulos.

Muito obrigado!

-Michael

Answer 1

Eu não iria abandonar 2.6 apenas por causa de avisos deprecation; aqueles vai desaparecer ao longo do tempo. (Você pode usar a opção -W ignore para o interpretador Python para evitar que sejam impressos, pelo menos) Mas se os módulos que você precisa para usar realmente não funcionam com o Python 2.6, que seria uma razão legítima para estadia com 2,5. Python 2.5 é largamente utilizado agora e provavelmente será por um longo tempo para vir (considerar quanto tempo durou 2.3!), Por isso mesmo se você ir com 2.5, você não será forçado a atualizar por um tempo.

Eu uso Python 2.5 para todo o meu trabalho de desenvolvimento, mas apenas porque é a versão que passa a estar disponível em Gentoo (Linux) 's repositório de pacotes. Quando os mantenedores do Gentoo declarar Python 2.6 * "estável", eu vou mudar para isso. Claro, esse raciocínio não se aplica necessariamente a você.

* Python 2.6, na verdade, é estável, a razão não é declarado como tal no Gentoo é que Gentoo depende de outros programas que se dependem de Python e ainda não está atualizado para trabalho com 2.6. Mais uma vez, este raciocínio provavelmente não se aplica a você.

Answer 2

A minha empresa é padronizado em 2,5. Como você não pode fazer a troca de 3,0 por um milhão de razões, mas eu muito gostaria que poderia subir para 2,6.

Fazendo dia codificação para os dias eu vou estar olhando através da documentação e eu vou encontrar exatamente o módulo ou função que eu quero, mas, em seguida, ele vai ter a pequena anotação: Novo na versão 2.6

Eu diria que ir com a versão mais recente, e se você tiver avisos de depreciação pop-up (provavelmente haverá muito poucos), então basta ir em uma encontrar uma maneira melhor de fazê-lo. No geral o seu código será melhor com 2.6.

Answer 3

Para mim o mais importante para ficar com python 2.5+ é porque ele suporta oficialmente ctypes, que mudou muitos sistemas de plugin.

Embora você possa encontrar ctypes para trabalhar com 2.3 / 2.4, eles não são empacotados oficialmente.

Assim, a minha sugestão seria 2.5.

Answer 4

Nós estamos furando com 2.5.2 para agora. Nossos centros de pilha tecnologia no Django (mas nós temos uma dúzia de outros bits e bobs.) Então, nós ficar perto o que eles fazem.

Nós tivemos que voltar para docutils a 0,4 por isso iria trabalhar com epydoc 3.0.1. Até agora, este não foi um grande problema, mas pode - em algum momento -. Causa-nos a repensar o uso de epydoc

A atualização 2.6 é parte de nosso plano de desenvolvimento. Temos orçamento, mas não fixa agenda agora.

A atualização 3.0, da mesma forma, é algo que eu lembrar povos de. Temos de orçamento para isso. Nós não vai fazê-lo este ano, a menos Django salta para 3,0. Podemos fazê-lo no próximo ano.

Answer 5

Eu acho que a melhor solução é abandonar a esperança no total uniformidade, apesar de ter um ambiente comum é algo por que lutar. Você sempre será confrontado com problemas de versão, por exemplo, quando o upgrade para a próxima versão melhor intérprete.

Então, ao invés de lidar com ele em um por questão de base que você poderia resolver este problema, tendo uma boa olhada no seu gerenciamento de liberação.

Em vez de liberar fonte, vá para binários plataforma dependendo (além da distribuição do código fonte).

Então, o que você faz é que você define um número de CPUs suportados, por exemplo: x86-32, x86-64, sparc

Sistemas Depois que operam: Linux, Windows, Solaris, FreeBSD

Para cada sistema operacional que você apoiar uma série de suas versões principais.

O próximo passo é que você fornecer binários para todos eles.

Sim, de fato isso vai exigir algum investimento em infraestrutura e regulação do edifício automática de seus repositórios (você tê-los?).

As vantagens é que os usuários só tem 'um' coisa de instalar e você pode alternar facilmente versões ou mesmo versões de mistura. Na verdade, você ainda pode usar diferentes linguagens de programação com esta abordagem, sem afetar o seu gerenciamento de liberação demais.