Por qué impresión declaración no es python?[cerrado]

https://stackoverflow.com/questions/1053849

20-08-2019
|

Pregunta

Esta pregunta estaba molestando bastante tiempo (como lo demuestra mi pregunta anterior):qué es exactamente print(x) mejor (que se define como más python) que print x?

Para aquellos que no saben, el print la declaración fue cambiado en función en Python 3.0.La documentación formal es en PEP 3105 y la motivación es en Guido van Rossum correo electrónico.

A los puntos que me gustaría hacer un contrapunto:

Hay otros operadores, tales como import los que escribimos como una declaración, aunque su funcionalidad es realmente duplicado con una función __import__
- Para los principiantes, el operador print no pertenece a la general de la lógica de la aplicación.Para ellos es el misterioso operador que es una culminación de su programa.Ellos esperan que se vea de manera diferente.
- Todos los principiantes libros que describían básicos de Python 2.x ahora garantizado para ser roto desde el primer ejemplo.Sin duda, los idiomas, a veces cambiar, pero los cambios son por lo general menos visible a los novatos.
- No es inmediatamente obvio para mí que una funcionalidad de print puede ser duplicado en un nivel de aplicación.Por ejemplo, a veces me gustaría redirección de impresión desde una consola como un modal OS de diálogo.
- Mientras que las personas dicen que es difícil volver a escribir todo print declaraciones a una función, que han obligado a todos los Python 2.x developer para hacer exactamente eso para todos sus proyectos.Bueno, no es difícil con cambio automático de convertidor.
- Todo el que disfruta de tener una capacidad para manipular la función print sería igual de bien servido si print fue una declaración de la envoltura de la función __print__.

Así que, por favor podemos tener un canónica respuesta a esta pregunta en las páginas de Desbordamiento de Pila?

Solución

A mí me parece que el tuyo es un debate, no una pregunta: ¿realmente va a aceptar una respuesta que muestra cuán profundamente y mal que estaban en sus afirmaciones?!

En el debate de los puntos:

Hay otros operadores, tales como de importación que escribimos como una declaración, aunque su funcionalidad es realmente duplicado con una función __import__

Absolutamente equivocado:la función __import__ (como cada otra función -- y el operador, para el caso) se une no los nombres en el ámbito de la "llamada" (código que lo contiene) -- cualquier "cosita" que se une a los nombres en la "llamada del alcance" debe ser una declaración de principios (como la asignación, def, y call).Su "punto" parece que pierde el muy profundo y crucial distinción que Python dibuja entre las afirmaciones y expresiones -- uno puede razonablemente aversión esta distinción, pero ignorando es, más obvia, es simplemente incorrecto.

Python declaraciones son cosas que el compilador de Python debe ser específicamente consciente de -- pueden alterar la unión de los nombres, pueden alterar el flujo de control y/o pueden necesitar ser totalmente eliminado de la bytecode generado en ciertas condiciones (el último se aplica a assert). print fue el sólo la excepción a esta afirmación en Python 2;por sacarlo de la lista de declaraciones, Python 3 elimina una excepción, hace la afirmación general de que "sólo espera", y por lo tanto es una forma más de lenguaje regular. Casos especiales no son lo suficientemente especial como para romper las reglas siempre ha sido una de Python el principio (¿ import this en un intérprete interactivo de la >>> mensaje para ver "el Zen de Python" muestra), y este cambio en el lenguaje quita una violación de este principio que había de permanecer por muchos años, debido a una errónea decisión de diseño.

Para los principiantes, el operador de impresión ¿ no pertenecen a la aplicación general de la lógica.Para ellos es el misterioso operador que es una culminación de su programa.Ellos esperan que se vea de forma diferente.

El curado de los principiantes de sus ideas tan pronto como sea posible, es una cosa muy buena.

Todos los principiantes libros que fueron describir básicos de Python 2.x ahora garantizado para ser roto por el puño ejemplo.Sin duda, idiomas a veces los cambios, pero los cambios son por lo general menos visible a los novatos.

Idiomas rara vez cambio en profundidad y hacia atrás incompatible con las formas (Python hace alrededor de una década) y algunas características del lenguaje son "altamente visible para los novatos", por lo que el número total de observaciones es pequeño, pero incluso dentro de esa pequeña brújula que podemos encontrar fácilmente ejemplos de lo contrario, donde una característica muy visible para los principiantes fue tan mal diseñado que la eliminación fue bien vale la pena la interrupción.Por ejemplo, los dialectos de Basic, tales como Microsoft Visual Basic, no uso explícito introducido por el usuario en los números de línea, una "característica" que era a la vez terrible y altamente visible para absolutamente todo el mundo, ya que era obligatorio en los principios de los dialectos de Basic.Variantes modernas de Lisp (de Esquema en adelante) no uso dinámico de alcance, un misfeature que, lamentablemente, muy visible (generalmente se manifiesta como difícil de comprender, los errores en su código), para los principiantes, básicamente, tan pronto como empezaron a escribir funciones en Lisp 1.5 (una vez fui a un principiante en eso y puede dar testimonio de lo mal que me mordió).

No es inmediatamente obvio para mí que una funcionalidad de impresión puede ser duplicado en un nivel de aplicación.Por ejemplo, a veces me gustaría redirección de impresión desde una consola como un modal OS de diálogo.

No estoy seguro de que siga este "punto".Acaba de cambiar sys.stdout a su favorito de la pseudo-objeto de archivo y redirigir a su corazón el contenido, usted tiene el opción de monkey patching la función integrada print (que nunca tuvo en Python 2), pero nadie torcer el brazo y la obliga a hacerlo.

Mientras que las personas dicen que es difícil volver a escribir todas las instrucciones de impresión para una función, ellos han obligado a todos los Python 2.x desarrollador para hacer exactamente eso para todos de sus proyectos.Bueno, no es difícil con cambio automático de convertidor.

El 2to3 la herramienta no ocupará de todos esos fácil superficie de incompatibilidades -- sin sudar (y es necesario ejecutar de todos modos para tomar el cuidado de todo un poco más, además de print, por lo que las personas hacen un uso mucho).Así que, ¿cuál es tu "punto" aquí?

Todo el que disfruta de tener una capacidad para manipular la función de impresión sería como bien servido si la impresión fue un declaración de la envoltura de la función imprimir.

Esta solución no es, per se, quitar una innecesaria de palabras clave (y, más especialmente, en un injustificado irregularidad, como he explicado anteriormente:una declaración de que se ha no una buena razón para ser una declaración debido a que no hay absolutamente ninguna necesidad para que el compilador ser especialmente conscientes de ello en ninguna manera, forma o forma!).Es muy claro para mí que tener una función subyacente gustaría añadir cualquier valor real, pero si usted tiene verdaderos casos de uso que sin duda puede proponer en el caso de Python Ideas de la lista de correo -- tal función subyacente, si se demuestra que son preciosas, de hecho, podría ser adaptado para ser utilizado por el print declaración en Python 2.7, así como por el print función en Python 3.2.

Sin embargo, considere un caso típico en el que uno puede querer mono-parche de la incorporada en el print:la adición de palabras clave argumentos para permitir el lujo de ajustes.¿Cómo sería la __print__ la función está aparentemente propuesto nunca ge aquellos KW argumentos de un __print__ declaración?Algunos funkier sintaxis sin embargo, que los horrores de la >> myfile y el punto y coma final...?!Con print como una función, los parámetros de palabra clave seguir perfectamente normal y ordinario de las reglas que se aplican a cada la función y la función de llamada -- la felicidad!

Así que, en resumen, es más Python para print para ser una función porque elimina las anomalías, casos especiales, y la necesidad de raro, excepcional sintaxis -- simplicidad, regularidad y uniformidad de Python son marca registrada.

Otros consejos

Esta es la razón por la que odio la declaración impresa en 2.x.

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

objeto sin valor no tiene útil __str__, bien, puedo tratar, míralo un poco más.

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

hmm ... entonces, ¿esa llamada puede tomar argumentos?

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

Entonces ... tengo que definir una función para usar

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

Shudder, o use sys.stdout.write, que es casi tan torpe, ya que tiene un comportamiento muy diferente de print. También se ve diferente, lo que significa que casi nunca recordaré que existe.

Usar sentencias <=> en una instalación breve de tipo único y luego mejorarlo para usar el registro o algo mejor es simplemente poco elegante. Si la impresión funcionara de esa manera, y especialmente podría usarse con funciones de alto orden, entonces sería mejor que solo lo que usa cuando no usa el registro real o real depuradores.

La declaración print también lleva la inusual sintaxis >> para imprimir en un archivo específico. No hay otra declaración en Python que tenga esta sintaxis, por lo que es inusual de esa manera.

Sin embargo, creo que tiene razón, la mayoría de los problemas con la declaración __print__ podrían haberse resuelto con la introducción de una función <=>.

Encontré GvR's " print es la única funcionalidad de nivel de aplicación que tiene una declaración dedicada a ella " Convincente. Python es un lenguaje de propósito general, y no debería tener una declaración para enviar a una secuencia como operador o palabra clave.

No es pitónico porque la sintaxis debería ser:

stdout.append("Hello World")

stdout += "hello world"

Descargo de responsabilidad: me gusta Python realmente.

En una nota seria ...

Creo que el modelo de objetos de Python y el enfoque 'Impleméntalo tú mismo' para cosas como la visibilidad de atributos es genial. Creo que este enfoque de "todo es un objeto" para OOP, e incluso los objetos definidos como una estructura de colección de objetos es muy claro.

Lo que temo que Python hará es convertirse en un lenguaje que no presente sus intenciones de una manera clara ... y odiaría ver que la belleza de los principios se empantana al pensar demasiado en la presentación de sintaxis ya poco convencional . Algo así como Lisp , hermoso en su estructura, sombrío, en mi sintaxis.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow