Если я использую распространенный:: распознайтесь или просто придерживайтесь 'использования, строгого', и 'используют предупреждения'?
Я не думаю, что существует встроенная функция, которая делает это. Вы будете иметь к самокрутке, например:
def human_format(num):
magnitude = 0
while abs(num) >= 1000:
magnitude += 1
num /= 1000.0
# add more suffixes if you need them
return '%.2f%s' % (num, ['', 'K', 'M', 'G', 'T', 'P'][magnitude])
print('the answer is %s' % human_format(7436313)) # prints 'the answer is 7.44M'
8 ответов
Хотя мне нравится идея сократить шаблонный код, я с большим подозрением отношусь к таким инструментам, как Modern :: Perl и common :: sense.
У меня проблема с такими модулями состоит в том, что они объединяют группу поведений и скрывают имена glib с изменяемым значением.
Например, Modern :: Perl сегодня состоит из включения некоторых функций Perl 5.10 и использования строгих и предупреждений. Но что произойдет, когда Perl 5.12, 5.14 или 5.24 выйдет с новыми замечательными новинками, и сообщество обнаружит, что нам нужно использовать прагму frobnitz везде? Будет ли Modern :: Perl обеспечивать согласованный набор поведений или останется «современным». Если MP будет идти в ногу со временем, он сломает существующие системы, которые не соблюдают требования к компилятору. Он добавляет дополнительное тестирование совместимости для обновления. По крайней мере, это моя реакция на депутата. Я первым признаю, что хроматик примерно в 10 раз умнее меня и к тому же лучший программист - но я все еще не согласен с его мнением по этому вопросу.
common :: sense есть проблема с именем , тоже. Чья идея здравого смысла задействована? Изменится ли это со временем?
Я бы предпочел модуль, который позволяет мне легко создавать собственный набор стандартных модулей и даже создавать группы связанных модулей / прагм для конкретных задач (например, манипулирование датой и временем, взаимодействие с базой данных, синтаксический анализ HTML и т. Д.)
Мне нравится идея Toolkit , но она отстой по нескольким причинам: в ней используются исходные фильтры, а макросистема слишком сложна и хрупка. Я очень уважаю Дэмиана Конвея, и он создает великолепный код, но иногда заходит слишком далеко (по крайней мере, для производственного использования, эксперименты хороши).
Я не потерял достаточно времени, набирая use strict; используйте предупреждения; , чтобы почувствовать необходимость создать свой собственный стандартный модуль импорта. Если бы я почувствовал острую потребность в автоматической загрузке набора модулей / прагм, было бы идеально было бы что-то подобное Toolkit, позволяющее создавать стандартные группы функций:
use My::Tools qw( standard datetime SQLite );
или
use My::Tools;
use My::Tools::DateTime;
use My::Tools::SQLite;
Toolkit очень близко подходит к моему идеалу. Его роковые дефекты - облом.
Что касается того, имеет ли смысл выбор прагм, это дело вкуса. Я бы предпочел время от времени использовать no strict 'foo' или no warnings 'bar' в блоке, где мне нужна возможность делать что-то, что этого требует, чем отключать проверки весь мой файл. Плюс, ИМО, потребление памяти - отвлекающий маневр. YMMV.
обновление
Похоже, что существует много (сколько?) Различных модулей этого типа, плавающих вокруг CPAN.
- Есть последний , который уже не последний. Демонстрирует часть проблемы именования.
- Кроме того, uni :: perl , который добавляет разрешающую часть соединения Unicode.
- ToolSet предлагает подмножество возможностей
Toolkit, но без исходных фильтров . - Я включу сюда Moose , поскольку он автоматически добавляет
strictипредупрежденияв вызывающий пакет. - И, наконец, Acme :: Very :: Modern :: Perl
Распространение этих модулей и возможность перекрытия требований добавляет еще одну проблему.
Что произойдет, если вы напишете такой код:
У меня явно нет здравого смысла, потому что я предпочитаю Modern :: Perl ; -)
Я бы сказал, что придерживайтесь предупреждений и строгих по двум основным причинам.
- Если другие люди собираются использовать или работать с вашим кодом , они (почти наверняка) используются для
предупрежденийистрогихи их правил. Они представляют собой норму сообщества, на которую вы и другие люди можете рассчитывать. - Даже если этот или тот конкретный фрагмент кода предназначен только для вас, вы, вероятно, не хотите беспокоиться о том, чтобы помнить: «Это проект, в котором я придерживаюсь
предупрежденияистрогиеили тот, где я придерживаюсьздравого :: смысла? " Перемещение между двумя режимами просто запутает вас.
The "lower memory usage" only works if you use no modules that load strict, feature, warnings, etc. and the "much" part is...not all that much.
Not everyone's idea of common sense is the same - in that respect it's anything but common.
Go with what you know. If you get undef warnings, chances are that your program or its input is incorrect.
Warnings are there for a reason. Anything that reduces them cannot be useful. (I always compile with gcc -Wall too...)
I have never had a warning that wasn't something dodgy/just plain wrong in my code. For me, it's always something technically allowed that I almost certainly don't want to do. I think the full suite of warnings is invaluable. If you find use strict + use warnings adequate for now, I don't see why you'd want to change to using a non-standard module which is then a dependency for every piece of code you write from here on out...
When it comes to warnings, I support the use of any module or built-in language feature that gives you the level of warnings that helps you make your code as solid and reliable as it can possibly be. An ignored warning is not helpful to anyone.
But if you're cozy with the standard warnings, stick with it. Coding to a stricter standard is great if you're used to it! I wouldn't recommend switching just for the memory savings. Only switch if the module helps you turn your code around quicker and with more confidence.
Кажется, есть один бит, который никто не заметил, и это FATAL в предупреждениях Список .
Итак, начиная с версии 2.0, use common :: sense больше похож на:
use strict;
use warnings FATAL => 'all'; # but with the specific list of fatals instead of 'all' that is
Это в некоторой степени важная и часто упускаемая из виду особенность предупреждений, которая на целую степень увеличивает строгость выше. Вместо интерполяции строк undef, или бесконечная рекурсия просто предупреждает вас, а затем продолжает работу, несмотря на проблему, она фактически останавливается.
Для меня это полезно, потому что во многих случаях интерполяция строки undef приводит к дальнейшим более опасным ошибкам, которые могут незаметно остаться незамеченными, и неудача и спасение - это хорошо.