Имеет ли python строгое использование; и используйте предупреждения; как в perl?

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

Две прагматы в вашем исходном вопросе действительно расширяются до:

use strict "vars";
use strict "refs";
use strict "subs";
use warnings;

Чтобы ответить каждому по очереди:

• Эффект use strict "vars" заключается в том, что ошибка времени компиляции ссылается на переменную без предварительного объявления о ее существовании (например, по умолчанию в более статических языках, таких как C, C ++ и Java). Поскольку в Python нет специального синтаксиса для объявления о существовании переменной, у него нет эквивалента. Присвоение имени в Python всегда создает его, если оно сначала не существовало. Эта функция strict не имеет эквивалента Python, и безопасность, которую она обеспечивает, не может быть воссоздана.

Eg:

$ perl -c -e 'use strict "vars"; $foo = 1'
Global symbol "$foo" requires explicit package name at -e line 1.
-e had compilation errors.

$ perl -c -e 'no strict "vars"; $foo = 1'
-e syntax OK

• Эффект use strict "refs" состоит в том, чтобы запретить использование простых строк, содержащих имя (существующей или новой) переменной, в качестве ссылки на саму переменную. Python этого не делает, поэтому отключать его не нужно.

Eg:

$ perl -e 'use strict "refs"; ${"message"} = "hello"; print $message'
Can't use string ("message") as a SCALAR ref while "strict refs" in use at -e line 1.

$ perl -e 'no strict "refs"; ${"message"} = "hello"; print $message'
hello

• Эффект use strict "subs" состоит в том, чтобы вызвать во время компиляции любую попытку вызвать функцию, о существовании которой известно, что она не существует. Python не выполняет такую ​​проверку и не имеет возможности включить такую ​​функцию.

Eg:

$ perl -c -e 'use strict "subs"; foo'
Bareword "foo" not allowed while "strict subs" in use at -e line 1.
-e had compilation errors.

$ perl -c -e 'no strict "subs"; foo'
-e syntax OK

• Эффект use warnings состоит в том, чтобы включить больше предупреждений как во время компиляции, так и во время выполнения различных категорий поведения, которые были по умолчанию в более ранних версиях, иногда могут быть желательными или которые никогда не были хорошей идеей, но не являются строго ошибкой. Например, использование неинициализированных значений в качестве чисел обычно должно вызывать предупреждение, но изначально этого не было.

Eg:

$ perl -e 'use warnings; my $u; print 2 + $u'
Use of uninitialized value $u in addition (+) at -e line 1.
2

$ perl -e 'no warnings; my $u; print 2 + $u'
2

Ну наконец то; были сделаны некоторые комментарии о том, что Python имеет аналогичные функции в __future__. Однако это не следует рассматривать как аналог прагматов Perl, поскольку большинство последних имеют лексическую область видимости и могут быть включены или отключены в небольших пределах по мере необходимости; где __future__ Python включен только для всего исходного файла.

Eg.

use strict;
use warnings;

my $total;

$total += count_things($_) for @list;

{
   no warnings 'uninitialized';
   printf "The total is %d\n", $total;
}

Несколько надуманный пример, но этот демонстрирует использование no warnings 'uninitialized' для отключения предупреждения об использовании неинициализированного значения просто внутри оператора printf, при этом остальные предупреждения остаются включенными везде.

Итак, в итоге: Python не имеет use strict или какого-либо почти эквивалента, поскольку любые из функций безопасности, которые он предоставляет, являются обязательными или недоступными на языке Python и не имеют use warnings. Те функции, которые он предоставляет, включены только на уровне файлов и не могут быть выборочно включены или отключены для каждой области.

Изменить: На самом деле теперь я был проинформирован о том, что в Python есть некоторые управляемые предупреждающие флаги, которые можно включать и отключать по мере необходимости.

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

Без сомнения, найдутся приверженцы Python, которые обидятся на это заявление. Я слышал, что некоторые говорят, что им не нужны строгие правила. Я считаю, что те, кто так говорит, обычно не знают, что вам нравится в строгости. Рассмотрим следующий блок кода на Python:

def Main():
    print(GetPrice(100,"Alaska"))
    print(GetPrice(100,"Florida"))
    print(GetPrice(100,"Michigan"))
    print(GetPrice(100,"Wisconsin"))

def GetPrice(UnitPrice,State):
    StateSalesTaxRate = 0
    if State == "Alabama": StateSalesTaxRate = 0.04
    if State == "Alaska": StateSalesTaxRate = 0
    if State == "Arizona": StateSalesTaxRate = 0.056
    if State == "Arkansas": StateSalesTaxRate = 0.065
    if State == "California": StateSalesTaxRate = 0.075
    if State == "Colorado": StateSalesTaxRate = 0.029
    if State == "Connecticut": StateSalesTaxRate = 0.0635
    if State == "Delaware": StateSalesTaxRate = 0
    if State == "Florida": StateSalesTaxRate = 0.06
    if State == "Georgia": StateSalesTaxRate = 0.04
    if State == "Guam": StateSalesTaxRate = 0.04
    if State == "Hawaii": StateSalesTaxRate = 0.04
    if State == "Idaho": StateSalesTaxRate = 0.06
    if State == "Illinois": StateSalesTaxRate = 0.0625
    if State == "Indiana": StateSalesTaxRate = 0.07
    if State == "Iowa": StateSalesTaxRate = 0.06
    if State == "Kansas": StateSalesTaxRate = 0.0615
    if State == "Kentucky": StateSalesTaxRate = 0.06
    if State == "Louisiana": StateSalesTaxRate = 0.04
    if State == "Maine": StateSalesTaxRate = 0.055
    if State == "Maryland": StateSalesTaxRate = 0.06
    if State == "Massachusetts": StateSalesTaxRate = 0.0625
    if State == "Michigan": StateSalesTexRate = 0.06
    if State == "Minnesota": StateSalesTaxRate = 0.06875
    if State == "Mississippi": StateSalesTaxRate = 0.07
    if State == "Missouri": StateSalesTaxRate = 0.04225
    if State == "Montana": StateSalesTaxRate = 0
    if State == "Nebraska": StateSalesTaxRate = 0.055
    if State == "Nevada": StateSalesTaxRate = 0.0685
    if State == "New Hampshire": StateSalesTaxRate = 0
    if State == "New Jersey": StateSalesTaxRate = 0.07
    if State == "New Mexico": StateSalesTaxRate = 0.05125
    if State == "New York": StateSalesTaxRate = 0.04
    if State == "North Carolina": StateSalesTaxRate = 0.0475
    if State == "North Dakota": StateSalesTaxRate = 0.05
    if State == "Ohio": StateSalesTaxRate = 0.0575
    if State == "Oklahoma": StateSalesTaxRate = 0.045
    if State == "Oregon": StateSalesTaxRate = 0
    if State == "Pennsylvania": StateSalesTaxRate = 0.06
    if State == "Puerto Rico": StateSalesTaxRate = 0.105
    if State == "Rhode Island": StateSalesTaxRate = 0.07
    if State == "South Carolina": StateSalesTaxRate = 0.06
    if State == "South Dakota": StateSalesTaxRate = 0.04
    if State == "Tennessee": StateSalesTaxRate = 0.07
    if State == "Texas": StateSalesTaxRate = 0.0625
    if State == "Utah": StateSalesTaxRate = 0.0595
    if State == "Vermont": StateSalesTaxRate = 0.06
    if State == "Virginia": StateSalesTaxRate = 0.053
    if State == "Washington": StateSalesTaxRate = 0.065
    if State == "West Virginia": StateSalesTaxRate = 0.06
    if State == "Wisconsin": StateSalesTaxRate = 0.05
    if State == "Wyoming": StateSalesTaxRate = 0.04
    return(UnitPrice*(1+StateSalesTaxRate))

if __name__ == '__main__': Main()

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

Итак, вы видите что-то не так с кодом? Нет? Попробуйте запустить его. Когда вы получите:

100
106.0
100
105.0

Все еще не видите проблемы? Тогда у вас проблема посерьезнее, чем вы думаете. Вот эквивалентный код, отрисованный на Perl:

use strict;

sub Main
{
    print GetPrice(100,"Alaska"), "\n";
    print GetPrice(100,"Florida"), "\n";
    print GetPrice(100,"Michigan"), "\n";
    print GetPrice(100,"Wisconsin"), "\n";    
}

sub GetPrice
{
    my($UnitPrice,$State) = @_;
    my $StateSalesTaxRate = 0;
    $StateSalesTaxRate = 0.04 if $State eq "Alabama";
    $StateSalesTaxRate = 0 if $State eq "Alaska";
    $StateSalesTaxRate = 0.056 if $State eq "Arizona";
    $StateSalesTaxRate = 0.065 if $State eq "Arkansas";
    $StateSalesTaxRate = 0.075 if $State eq "California";
    $StateSalesTaxRate = 0.029 if $State eq "Colorado";
    $StateSalesTaxRate = 0.0635 if $State eq "Connecticut";
    $StateSalesTaxRate = 0 if $State eq "Delaware";
    $StateSalesTaxRate = 0.06 if $State eq "Florida";
    $StateSalesTaxRate = 0.04 if $State eq "Georgia";
    $StateSalesTaxRate = 0.04 if $State eq "Guam";
    $StateSalesTaxRate = 0.04 if $State eq "Hawaii";
    $StateSalesTaxRate = 0.06 if $State eq "Idaho";
    $StateSalesTaxRate = 0.0625 if $State eq "Illinois";
    $StateSalesTaxRate = 0.07 if $State eq "Indiana";
    $StateSalesTaxRate = 0.06 if $State eq "Iowa";
    $StateSalesTaxRate = 0.0615 if $State eq "Kansas";
    $StateSalesTaxRate = 0.06 if $State eq "Kentucky";
    $StateSalesTaxRate = 0.04 if $State eq "Louisiana";
    $StateSalesTaxRate = 0.055 if $State eq "Maine";
    $StateSalesTaxRate = 0.06 if $State eq "Maryland";
    $StateSalesTaxRate = 0.0625 if $State eq "Massachusetts";
    $StateSalesTexRate = 0.06 if $State eq "Michigan";
    $StateSalesTaxRate = 0.06875 if $State eq "Minnesota";
    $StateSalesTaxRate = 0.07 if $State eq "Mississippi";
    $StateSalesTaxRate = 0.04225 if $State eq "Missouri";
    $StateSalesTaxRate = 0 if $State eq "Montana";
    $StateSalesTaxRate = 0.055 if $State eq "Nebraska";
    $StateSalesTaxRate = 0.0685 if $State eq "Nevada";
    $StateSalesTaxRate = 0 if $State eq "New Hampshire";
    $StateSalesTaxRate = 0.07 if $State eq "New Jersey";
    $StateSalesTaxRate = 0.05125 if $State eq "New Mexico";
    $StateSalesTaxRate = 0.04 if $State eq "New York";
    $StateSalesTaxRate = 0.0475 if $State eq "North Carolina";
    $StateSalesTaxRate = 0.05 if $State eq "North Dakota";
    $StateSalesTaxRate = 0.0575 if $State eq "Ohio";
    $StateSalesTaxRate = 0.045 if $State eq "Oklahoma";
    $StateSalesTaxRate = 0 if $State eq "Oregon";
    $StateSalesTaxRate = 0.06 if $State eq "Pennsylvania";
    $StateSalesTaxRate = 0.105 if $State eq "Puerto Rico";
    $StateSalesTaxRate = 0.07 if $State eq "Rhode Island";
    $StateSalesTaxRate = 0.06 if $State eq "South Carolina";
    $StateSalesTaxRate = 0.04 if $State eq "South Dakota";
    $StateSalesTaxRate = 0.07 if $State eq "Tennessee";
    $StateSalesTaxRate = 0.0625 if $State eq "Texas";
    $StateSalesTaxRate = 0.0595 if $State eq "Utah";
    $StateSalesTaxRate = 0.06 if $State eq "Vermont";
    $StateSalesTaxRate = 0.053 if $State eq "Virginia";
    $StateSalesTaxRate = 0.065 if $State eq "Washington";
    $StateSalesTaxRate = 0.06 if $State eq "West Virginia";
    $StateSalesTaxRate = 0.05 if $State eq "Wisconsin";
    $StateSalesTaxRate = 0.04 if $State eq "Wyoming";
    return($UnitPrice*(1+$StateSalesTaxRate));
}

Main();

Без включения строгой прагмы Perl вы даже получите идентичный вывод:

100
106.0
100
105.0

Но если строгий включен, вы получите следующее сообщение об ошибке при запуске этого Perl-скрипта:

Global symbol "$StateSalesTexRate" requires explicit package name at line 37.
Execution aborted due to compilation errors. 

Проблема в обоих примерах заключается в опечатке в одной из строк вычислений. У меня есть StateSalesTexRate вместо StateSalesTaxRate для строки расчета налога с продаж для штата Мичиган. Perl явно находит и устраняет эту ошибку. Тем временем Python поворачивает голову и смотрит в другую сторону.

Это большое дело. Представьте, что это программное обеспечение используется вашим онлайн-бизнесом для расчета суммы, которую вы снимаете с кредитной карты клиента. Сколько времени пройдет, прежде чем вы поймете, что клиенты из Мичигана получают пропуск по налогу с продаж? Когда вы это сделаете, вы вернетесь к покупателю и скажете: «Извините, нам нужно от вас больше денег», или вы сами съедите потерю?

Конечно, у любой компании, использующей этот тип алгоритма кодирования для расчета налога с продаж, вероятно, есть более серьезные проблемы. Но на этом примере вы можете ясно увидеть, что делает прагма strict в Perl и почему я и другие считают, что она должна быть важной особенностью любого языка сценариев.

Есть много вещей, которые мне действительно нравятся в Python. Я понимаю, почему некоторые люди предпочитают Python Perl. Но есть несколько вещей, которые я действительно ненавижу в Python. Это один.

Чтобы запустить Python с включенными предупреждениями:

python -W all file.py

В ответ на:

Есть ли что-то, что я должен делать в обычном порядке для моих скриптов Python?

Я думаю, что в целом неплохо убедиться, что ваш код соответствует PEP 8. Как упоминалось в другом ответе, вы можете сделать это программно:

pip install pep8 && pep8 file.py

LeoNerd дает прекрасное объяснение того, почему в Python нет «строгого использования» или «предупреждений об использовании».

В ответ на:

Есть ли что-то, что мне следует делать в обычном порядке для моих скриптов Python?

Возможно, вам будет интересно запустить свой код с помощью статического анализатора кода, такого как pylint, и / или проверки форматирования кода, например pep8.

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

Вот достойное обоснование их использования. И соответствующие вопросы по Stackoverflow здесь и здесь.

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

Вероятно, это сводится к Дзен Python «Должно быть один - а желательно только один - очевидный способ сделать это ». Дизайн Python сосредоточен на удобочитаемости, и наличие множества способов выполнения или изменения способа работы языка затрудняет чтение кода.

Я бы сказал, что наиболее близким из них является импорт из __future__ в более старые версии Python в ввести некоторые исправления / новые функции из более новых версий в более старые версии (например, деление, переходящее от целочисленного к делению с плавающей запятой по умолчанию). Это похоже на то, что улучшает поведение по умолчанию, делая его более разумным в стандартном случае.

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

Это не ошибка времени компиляции, но у Python есть много линтеров, которые могут идентифицировать тот же тип ошибок, что и Perl "use strict":

Рассмотрим файл Python с именем tmp.py с:

def foo():
    a = 1
    b = 2
    return a

flake8 tmp.py вернет:

tmp.py:13:5: F841 local variable 'b' is assigned to but never used

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