Почему оператор печати не является pythonic? [закрытый]

Question

Почему оператор печати не является pythonic? [закрытый]

Люди жалуются на удаление слова «goto» из языка. Мне кажется, что любой вид условного перехода сильно переоценен и что «если», тогда как «switch» и цикл общего назначения для «for» сильно переоценены и должны использоваться с особой осторожностью.

Каждый раз, когда вы делаете сравнение и условный переход, добавляется крошечная сложность, и эта сложность быстро возрастает, когда стек вызовов достигает пары сотен элементов.

Мой первый выбор - избегать условных, но если это нецелесообразно, я предпочитаю оставить условную сложность в конструкторах или фабричных методах.

Очевидно, что это не практично для многих проектов и алгоритмов (таких как циклы потока управления), но это то, что мне нравится продвигать.

-Rick

33

python python-3.x

задан Community 23 May 2017 в 12:02

5 ответов

Вот причина, по которой я ненавижу оператор печати в 2.x.

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

бесполезный объект не имеет полезного __ str __ , Хорошо, я могу разобраться, взгляните на него еще.

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

хм .. так этот вызываемый объект принимает аргументы?

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

Итак ... у меня есть либо определить функцию для использования

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

Shudder, либо использовать sys.stdout.write , что почти так же неудобно, поскольку его поведение сильно отличается от print . Он также выглядит по-другому, что означает, что я почти никогда не вспомню, что он существует.

Использование операторов print в коротком одноразовом средстве типа и последующее улучшение его для использования регистрация или что-то получше просто неэлегантно. Если бы печать работала так же, и особенно ее можно было бы использовать с функциями высокого порядка, тогда это было бы лучше, чем просто то, что вы используете, когда не используете реальное ведение журнала или реальное отладчики.

11

ответ дан 27 November 2019 в 17:46

Оператор print также несет необычный синтаксис >> для печати в конкретный файл. В Python нет другого оператора с таким синтаксисом, поэтому он необычен.

Я считаю, что вы правы, большинство проблем с оператором print можно было бы решить с помощью введение функции __ print __ .

8

ответ дан 27 November 2019 в 17:46

Я обнаружил, что «печать GvR - единственная функциональность уровня приложения, для которой есть заявление, посвященное ей», убедительным. Python - это язык общего назначения, и в нем не должно быть операторов для вывода в поток в виде оператора или ключевого слова.

6

ответ дан 27 November 2019 в 17:46

Это не питонический язык, потому что синтаксис должен быть:

stdout.append("Hello World")

или

stdout += "hello world"

Отказ от ответственности: мне очень нравится Python.

На серьезном замечании ...

Я думаю, что Объектная модель Python и подход «Реализуй это самостоятельно» к таким вещам, как видимость атрибутов, великолепны. Я думаю, что подход «все является объектом» к ООП, и даже объекты, определенные как совокупность структур объектов, очень ясны.

Я боюсь, что Python станет языком, который не представляет его. намерения в ясной форме ... и мне не хотелось бы видеть, как красота принципов увязла в чрезмерном обдумывании и без того нетрадиционного синтаксического представления. Вроде как Лисп , красивый по своей структуре, мрачный, имхо по синтаксису.

3

ответ дан 27 November 2019 в 17:46

Другие вопросы по тегам:

python python-3.x

Похожие вопросы:

score 57 · Accepted Answer

Мне кажется, что ваша дискуссия - это дискуссия, а не вопрос. вы действительно собираетесь принять ответ, который показывает, насколько глубоко и сильно вы ошибались в своих утверждениях?!

Теперь о ваших дискуссиях:

Есть и другие операторы, такие как import, который мы пишем как утверждение, хотя их функциональность на самом деле дублируется функцией __ import __

Абсолютно неверно: функция __ import __ (например, каждая другая функция - и оператор, если на то пошло) связывает нет имена в области «вызывающего» (код, содержащий его) - любая «штука», которая связывает имена в «области действия вызывающего» , должна быть оператором (точно так же, как присвоение, def , и звоните ). Ваша «точка», похоже, полностью упускает из виду чрезвычайно глубокое и решающее различие, которое Python проводит между операторами и выражениями - можно разумно не любить это различие, но игнорируя , наиболее очевидно, просто неправильно.

Операторы Python - это то, о чем компилятор Python должен специально знать - они могут изменить привязку имен, могут изменить поток управления и / или могут потребоваться полностью удалить из сгенерированного байт-кода в определенных условиях (последнее применяется к утверждают ). print был единственным исключением из этого утверждения в Python 2; удаляя его из списка операторов, Python 3 удаляет исключение, делает общее утверждение «просто сохраняемым» и, следовательно, является более регулярным языком. Особые случаи недостаточно особенные, чтобы нарушать правила уже давно является догматом Питона ( импортируйте этот в запрос >>> интерактивного интерпретатора, чтобы увидеть " Zen of Python »), не относятся к общему приложению логика. Для них это загадочно оператор, который является кульминацией их программа. Они ожидают, что это будет выглядеть по-разному.

Излечить новичков от их заблуждений как можно раньше - это очень хорошо.

Все книги для начинающих, которые были описание базового Python 2.x теперь гарантированно сломается из кулака пример. Конечно, языки иногда меняется, но изменения обычно менее заметны для новичков.

Языки редко меняются глубоким и обратно несовместимым образом (Python делает это примерно раз в десятилетие), и некоторые языковые особенности «хорошо заметны новичкам», поэтому общее количество наблюдений невелико - тем не менее, даже в этом крошечном компасе мы можем легко найти контрпримеры, где функция, хорошо заметная для новичков, была настолько плохо спроектирована, что ее удаление стоило нарушения. Например, современные диалекты языка Basic, такие как Visual Basic от Microsoft, не используют явно вводимые пользователем номера строк - «особенность», которая была ужасной и хорошо заметной абсолютно всем, поскольку была обязательной в ранних диалектах Basic. Современные варианты Lisp (начиная с Scheme) не используют динамическую область видимости, ошибка, которая, к сожалению, была очень заметна (обычно проявлялась в виде трудных для понимания ошибок в их коде) для новичков, в основном, как только они начали писать функции в Lisp 1.5 (когда-то я был новичком в этом и могу засвидетельствовать, насколько плохо это укусил меня).

Для меня это не сразу очевидно что функциональность печати может быть дублируется на уровне приложения. Например, иногда мне хотелось бы перенаправить печать с консоли как модальный диалог ОС.

Не уверен, что следую этому "пункту". Просто замените sys.stdout на свой любимый объект псевдофайла и перенаправьте на то, что вам по душе - у вас есть вариант обезьяны, исправляющей встроенную функцию print (чего у вас никогда не было в Python 2), но никто не выкручивает вам руку и не заставляет вас это делать.

Хотя люди говорят, что это сложно переписать все операторы печати для функции, они заставили каждый Python 2.x разработчик сделать именно это для всех свои проекты. Хорошо это не сложно с автоматическим преобразователем.

Инструмент 2to3 действительно устраняет все такие простые несовместимости поверхностей - без проблем (и его все равно нужно запускать, чтобы позаботиться о некоторых других, кроме print , поэтому люди широко его используют). Итак, в чем ваш "смысл"?

Каждый, кому нравится иметь способность манипулировать функцией print было бы так же хорошо обслуживали, если бы печать была функция-оболочка операторов print .

Такая схема сама по себе не удалит ненужное ключевое слово (и особенно неоправданную неправильность , как я объяснил выше: утверждение, которое не имеет никаких веских оснований для того, чтобы быть оператором, потому что компилятору совершенно не нужно знать об этом каким-либо образом, формой или формой!). Мне далеко не ясно, что наличие такой базовой функции добавит реальную ценность, но если у вас есть реальные варианты использования, вы, безусловно, можете предложить вариант в списке рассылки Python Ideas - такая базовая функция, если окажется, что она действительно драгоценна. , может быть модифицирован для использования оператором print в Python 2.7, а также функцией print в Python 3.2.

Однако, рассмотрим типичный случай, когда кто-то может захотеть исправить встроенный print : добавление аргументов ключевого слова, чтобы разрешить причудливые настройки. Как функция __ print __ , которую вы, по-видимому, предлагаете, когда-либо будет получать эти аргументы KW из оператора __ print __ ? Еще более забавный синтаксис, чем ужасы >> myfile и запятая в конце ...?! С print в качестве функции аргументы ключевого слова следуют совершенно обычным и обычным правилам, которые применяются к каждой функции и вызову функции - блаженство!