Por instrução de impressão não é pythônico? [fechadas]

StackOverflow https://stackoverflow.com/questions/1053849

  •  20-08-2019
  •  | 
  •  

Pergunta

Esta questão foi me incomodando há algum tempo (como evidenciado por minha pergunta anterior): por que exatamente é print(x) melhor (que é definido como sendo mais Python) do que print x

Para aqueles que não sabem, a declaração print foi mudado em função em Python 3.0. A documentação formal está em PEP 3105 e motivação está em de Guido van Rossum e-mail .

Para aqueles pontos que eu gostaria de fazer um contraponto:

  1. Existem outros operadores, como import que nós escrevemos como uma declaração, embora a sua funcionalidade é realmente duplicado com uma __import__ função
    • Para iniciantes, o print operador não pertencem à lógica de aplicação geral. Para eles, é o operador misteriosa que é a culminação de seu programa. Eles esperam que olhar de forma diferente.
    • Todos os livros iniciantes que foram descrevendo Python básica 2.x estão agora garantida para ser quebrado a partir do primeiro exemplo . Certamente, as línguas mudam às vezes, mas essas alterações são geralmente menos visível para os novatos.
    • Não é imediatamente óbvio para mim que uma funcionalidade de print pode ser duplicado em um nível de aplicação. Por exemplo, às vezes eu gostaria de redirecionar impressão a partir de um console como um diálogo OS modal.
    • Quando as pessoas dizem que é difícil para reescrever todas as declarações print para uma função, eles forçaram cada desenvolvedor 2.x do Python para fazer exatamente isso para todos os seus projetos. Bom, não é difícil com conversor automático.
    • Todo mundo que gosta de ter uma capacidade de manipular a função print seria tão bem-servido se print era um __print__ função embrulho comunicado.

Assim, podemos por favor dê uma resposta canónica a esta pergunta nas páginas do Stack Overflow?

Foi útil?

Solução

Parece-me que o seu é um debate, não uma pergunta - você está realmente indo para aceitar uma resposta que mostra como profundamente e muito mal você estava em suas afirmações

?!

Em aos seus pontos de debate:

Existem outros operadores, como de importação que nós escrevemos como uma declaração, embora a sua funcionalidade é realmente duplicados com um __import__ função

Absolutamente errado: função __import__ (como todas outra função - e operador, para que o assunto) se liga não nomes no âmbito do "chamador" (código contendo-o ) - quaisquer "thingie" que liga nomes no "âmbito do chamador" deve ser uma declaração (como atribuição, def e call). Seu "ponto" parece perder totalmente a distinção extremamente profundo e fundamental que Python traça entre instruções e expressões - um possa razoavelmente antipatia essa distinção, mas ignorar que é, mais obviamente, simplesmente errado.

comandos Python são coisas que o compilador Python deve ser especificamente ciente de - eles podem alterar a ligação de nomes, pode alterar o fluxo de controle, e / ou podem precisar de ser completamente removido do bytecode gerado em determinadas condições (este último é aplicável para assert). print foi o única exceção a essa afirmação em Python 2; removendo-o da lista de declarações, Python 3 remove uma exceção, faz a afirmação geral "apenas espera", e, portanto, é uma linguagem mais regular. Casos especiais não são suficientes especial para quebrar as regras tem sido um princípio Pythonic (fazer import this em >>> de um intérprete interativo prompt para ver "o Zen de Python" exibido), e essa mudança para os remove da língua uma violação deste princípio que teve que permanecer por muitos anos devido a um início, design decisão errônea.

Para os iniciantes, a impressão operador faz não pertencem à aplicação geral lógica. Para eles é o misterioso operador que é o culminar de seu programa. Eles esperam que ele procure diferente.

Cura iniciantes de seus equívocos tão cedo quanto possível é uma coisa muito boa.

Todos os livros que eram iniciantes descrevendo Python básico são agora 2.x garantido para ser quebrado a partir do punho exemplo. Certamente, línguas às vezes muda, mas as mudanças são geralmente menos visível para os novatos.

Línguas raramente mudam de maneiras profundas e para trás-incompatíveis (Python faz isso uma vez por década) e alguns recursos de linguagem são "altamente visível para os novatos", de modo que o número total de observações é pequeno - mas mesmo dentro desse minúsculo bússola podemos facilmente encontrar contra-exemplos, onde uma característica altamente visível para iniciantes foi tão mal concebidos que a remoção foi bem vale o rompimento. Por exemplo, dialetos modernos do Basic, como Visual Basic, da Microsoft, não utilize números de linha inseridos pelo usuário explícitos, um "recurso" que era ao mesmo tempo terrível e altamente visível para absolutamente todos, uma vez que era obrigatória em dialetos iniciais do Basic. variantes modernas do Lisp (do Esquema em diante) não use escopo dinâmico, um misfeature que foi, infelizmente, altamente visível (geralmente manifestando-se como difícil de entender bugs no seu código) para iniciantes, basicamente, logo que eles começaram a escrever funções em Lisp 1.5 (eu era uma vez um novato nisso e pode testemunhar o quanto ele me mordeu).

Não é imediatamente óbvio para mim que uma funcionalidade de impressão pode ser duplicados em um nível de aplicação. Por exemplo, às vezes eu gostaria de impressão de redirecionamento de um console como um modal OS diálogo.

Não sei se seguir esta "point". Basta alterar sys.stdout ao seu objeto pseudo-arquivo favorito e redirecionamento para conten do seu coraçãots -. você tem a opção de macaco remendar o built-in print função (que você nunca teve em Python 2), mas ninguém de torcer o braço e forçá-lo a fazê-lo

Enquanto as pessoas dizem que é difícil para reescrever todas as instruções de impressão para uma função, eles forçaram cada 2.x do Python desenvolvedor para fazer exatamente isso para todos seus projetos. Bom, não é difícil com conversor automático.

A ferramenta 2to3 de fato cuidar de todas as tais incompatibilidades fácil de superfície - sem suor (e ele precisa ser executado de qualquer maneira para cuidar de alguns mais além print, para que as pessoas não usá-lo extensivamente). Então, qual é o seu "ponto" aqui?

Todo mundo que gosta de ter uma capacidade para manipular a função de impressão seria tão bem servido se a impressão foi um função declaração de embrulho print .

Tal arranjo não seria, por si só, remover uma palavra-chave desnecessário (e mais especialmente, uma injustificada irregularidade , como expliquei acima: uma declaração que tem não bom razão para ser a declaração porque não há absolutamente nenhuma necessidade para o compilador ser especialmente conscientes disso de qualquer maneira, forma ou formulário!). Está longe de ser claro para mim que ter uma função tão subjacente acrescentaria qualquer valor real, mas se você tiver casos de uso real, você certamente pode propor o caso na lista de discussão Idéias Python - uma função tão subjacente, se provado ser precioso certamente , poderia ser adaptado para ser usado pela instrução print em Python 2.7, bem como pela função print em Python 3.2.

No entanto, considere um caso típico em que um pode querer macaco-patch o built-in print: ajustes fantasia acrescentando argumentos chave para permitir. Como é que a função __print__ você está aparentemente proposta já ge esses argumentos KW de uma declaração __print__? ainda alguma sintaxe funkier do que os horrores da >> myfile ea vírgula no final ...?! Com print como uma função, argumentos nomeados seguir apenas as regras perfeitamente normais e comuns que se aplicam a todas função e chamada de função - a felicidade

Assim, em resumo, é mais Pythonic para print ser uma função porque remove anomalias, casos especiais, e qualquer necessidade de sintaxe excepcional estranho -. Simplicidade, regularidade e uniformidade são a marca registrada da Python

Outras dicas

Eis a razão pela qual eu odeio a declaração de impressão em 2.x. 

>>> something()
<something instance at 0xdeadbeef>
>>> print something()
<something instance at 0xdeadbeef>

objeto inútil não tem __str__ útil, bem, eu posso lidar, olhar para ele um pouco mais. 

>>> dir(something())
['foo', 'bar', 'baz', 'wonderful']
>>> help(something().foo)
"foo(self, callable)"

hmm .. Então, isso argumentos take exigível? 

>>> something().foo(print)
    something().foo(print)
                        ^
SyntaxError: invalid syntax
>>> something().foo(lambda *args: print(*args))
    something().foo(lambda *args: print(*args))
                                      ^
SyntaxError: invalid syntax

Então ... Eu tenho que quer definir uma função para uso 

>>> def myPrint(*args): print *args
    def myPrint(*args): print *args
                              ^
SyntaxError: invalid syntax
>>> def myPrint(*args): print args
...
>>> myPrint(1)
(1,)

Shudder ou uso sys.stdout.write, que é quase tão cludgy, uma vez que tem um comportamento muito diferente do print. Ele também aparência diferente, o que significa que quase nunca vai se lembrar que ele existe.

Usando declarações print em um curto, one-off instalação tipo e, em seguida, melhorá-lo para usar o log ou algo melhor é apenas deselegante. Se impressão funcionou como essas coisas e, especialmente, poderia ser usado com funções de alta ordem, então seria melhor do que apenas a coisa que você usa quando você não usar real logging ou real depuradores.

A declaração print também carrega a sintaxe >> incomum para imprimir para um arquivo específico. Não há outra declaração em Python que tem essa sintaxe, por isso é incomum nesse sentido.

Eu acredito que você são embora certo, a maioria dos problemas com a declaração print poderia ter sido resolvido com a introdução de uma função __print__.

Eu encontrei de GvR "print é a única funcionalidade em nível de aplicativo que tem uma declaração dedicado a ele" convencer. Python é uma linguagem de propósito geral, e não deve ter uma declaração de saída para um fluxo como um operador ou palavra-chave.

Não é pythônico porque a sintaxe deve ser: 

stdout.append("Hello World")

ou 

stdout += "hello world"

Disclaimer:. I como Python realmente

Em uma nota séria ...

Eu acho que o modelo de objeto do Python e 'implementá-lo' abordagem para coisas como a visibilidade atributo é grande. Eu acho que esse 'tudo é um objeto' abordagem para OOP, e até mesmo os objetos definidos como um conjunto de estrutura de objetos é muito clara-mente.

O que eu temo Python vai fazer é tornar-se uma linguagem que não apresentá-lo de intenções de uma forma clara ... e eu odiaria ver a beleza dos princípios se atolar em excesso de pensar a apresentação sintaxe já não convencional . Mais ou menos como Lisp , bonito em sua estrutura, desagradável, IMHO em sua sintaxe.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top