- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
class ScanFiles:
DIRECTORY_SEPARATOR = '/'
def __init__(self, rootDir, searchPattern, filesExtension = None):
self.rootCatalogPath = rootDir # Absolute path to directory to parse
self.filesExtension = filesExtension # Specified files(if typed)
self.pattern = searchPattern # Key word's regex pattern
def scan(self, path = '', absPath = ''):
if (not os.path.exists(self.rootCatalogPath)):
raise Exception("Directory is not exists.")
if (not absPath):
absolutePath = self.rootCatalogPath + self.DIRECTORY_SEPARATOR + path
else:
absolutePath = absPath + path + self.DIRECTORY_SEPARATOR
for item in os.listdir(absolutePath):
if (os.path.isdir(absolutePath + item)):
# recursive call
self.scan(item, absolutePath)
elif (os.path.isfile(absolutePath + item)):
if (self.filesExtension):
if (not re.search('\.%s$' % (self.filesExtension), item)):
return 0;
self.__parse_file(absolutePath + item)
def __parse_file(self, pathToFile):
f = open(pathToFile)
if (re.search(self.pattern, f.read(), re.IGNORECASE)):
print pathToFile;
return 1;
а так же модуль glob
Не пишет так питонец
А пишет
Ну и сам подход показывает что человек не умеет модуль os и os.path
А это стандартная либа, её бы подучить
В целом же у питона принято ничего не ассертить. Просто пишешь в документации: "не суй сюда несуществующий файл" и все.
"у моей подруги с её парнем" (С) 😉
Ну если мы закрываем глаза на велосипеды, на незнание os и os.path, на громоздкость по сравнению с питонячьей идеологией, лишние скобки и на комменты вместо докстрок то в целом нормально.
Отсутствие файла это НЕ ошибка программиста (если только у тебя не транзакционная fs как ntfs, когда ты можешь сначала проверить файл, а потом гарантировать что он никуда не делся).
Нужно или вертать ошибку, или уж кидать FileNotFoundException, чтобы его ловили и проверяли снова.
Но в 99% случаев можно считать что файл никуда не денется, а значит если программист не удосужился его проверить то можно и кинуть assert.
Опять таки: если очень хочется fast fail
Што?
что именно тебе не понятно?
проверил тебе, проверь
В жабе тоже такое есть
А в сишечке есть препроцессор чтобы делать собрку для дебага.
1) ты запускаешь код с ассертами. Он тормозит, потому что проверяет каждый пук, зато отлавливает тебе всё говно
2) ты отключаешь assert, и запускаешь продукт в продакшен, потому что он уже отлажен
Ну это как дебаговые сборки нативного кода: без оптимиизации и с символами и без base pointer omition итд
Не могли бы вы перевести это на человеческий язык?
>без оптимиизации
Что эти оптимизации дают для фитона?
>с символами и без base pointer omition итд
Для фитона ненужны
Почитай книжку Code Complete, там масса примеров.
Очевидно что код, в котором проверяется контракт и постусловия более склонен к fast fail, и потому его легче тестировать. С другой стороны это может вызвать тормоза.
Например ты можешь после каждого вывоза метода обсчитывать состояние объекта и убеждаться что он консистентен. Это удобно делать через assert.
В продакшене ты просто скажешь -O, и уберешь ненужные тебе проверки.
2) ты отключаешь assert, и запускаешь продукт в продакшен, потому что уж там то все файлы всегда существуют, это же продакшн
ну-ну.
Я это понимаю. Ну ничто же не мешает мне верить в сказку
Совет был в том, чтобы не писать явно if и raise Exception. Проверка файла тут просто пример проверки контракта. Вопрос о том можно-ли считать наличие файла контрактом остается открытым.
В любом случае код
ВСЕГДА хуже чем
А нахуя? Даже в сишке ассёрты и оптимизация - ортогональные вещи.
. So if code uses assertions heavily, but is performance-critical, then there is a system for turning them off in release builds
Тоже самое есть в жабе: ключ -ea.
А потом пришли дурачки, и написали
И оказалось что продакшен версии юзери не удаляются
Почему?
Если банковская питушня, пусть лучше упадёт, чем в оптимизированном варианте заплатит кому-нибудь за товар None.
А если мы не уверены в коде, то почему мы не проверяем каждую переменную?
Но это наверно только в том коде, где программистам платят миллионы за час, а за малейший баг расстреливают. Или в том коде, корректность которого математически доказана, а доказательство проверено математиками, которых за каждый баг расстреливают.
Если мы пишем важный код, связанный с оплатой реальными деньгами, мы не уверены в нём. И вот в той части, где надо платить, расставляем такие проверки, чтоб точно ничего не вышло, а в каком-нибудь гуе или шупоподавлялке для фотографий - assertы. Я это как-то так представляю на уровне идей.
Тесты могут доказать только то, что в коде есть баги. Обратного они не могут, увы.
Даже хардкорная формальная верификация ничего не доказывает, вдруг в прувере баги. Ну и предпосылки и модели, соответствие которым проверюется, всегда противоречивые или неполные.
Человеческая природа несовершенна, надо с этим смириться.
Вспомнился твой анус.
2. Если у пользователя нет прав на открытие всего одного файла в дереве, весь поиск накроется, когда до него дойдет.
Если это отдельная утилита, её лучше выкинуть и заменить на grep -R / find + grep / ack / ag
2. вот да) слона-то никто и не приметил кроме тебя. PyCharm даже ругает за open() без with
Imho ничо не будет само зкрываться, иначе как дескриптор вернуть?
Контекст менеджер нужен
Не закроет, нужен with.
https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_dealloc
> The destructor function is called by the Py_DECREF() and Py_XDECREF() macros when the new reference count is zero.
Для файлов это file_dealloc:
https://hg.python.org/cpython/file/c6880edaf6f3/Objects/fileobject.c#l2400
И оно закрывет файл:
https://hg.python.org/cpython/file/c6880edaf6f3/Objects/fileobject.c#l618
Ну и эксперементально подтверждается.
Py_DECREF() and Py_XDECREF() -- это куски сишного апи, к коду в топике не имеют никакого отношения. Когда-то в питоне мусор собирался счётчиком ссылок, но так циклы не удаляется. Сейчас там настоящий сборщик мусора, а
Py_DECREF() и Py_XDECREF() нужны для сишных расширений.
Хз, я вторым пользуюсь, там счетчик ссылок. И он обнуляется при выходе из __parse_file в данном конкретном коде из топика. Если ты говорил за какой-то новый петон, в котором нет подсчета ссылок, то ок.
Кроме шуток: запусти такую хуйню под strace:
А потом попробуй
Да похоже, что именно в нём. Выяснилось, что сейчас в обоих пистонах и счётчик ссылок, и гц одновременно. При этом всё это неявно и спрятано под капотом.
Выводит следующее:Ничего интересного в байткоде нет, счётчики ссылок изменяются где-то в кишках интерпретатора. Что ж, ГК познавательный.
А #include <Python.h> это что?
Я имел в виду, что всякие Py_DECREF нужны только когда пишешь модули на сишке и работаешь с пистоньими объектами. То, что интерпретатор их тоже в кишках использует — это логично, т.к. на одни и те же объекты могут ссылаться одновременно и сишный модуль, и интерпретатор. Просто не совсем очевидно.
> Связь там прямая
Да, это я уже понял.
Как трейсящий по-русски называется?
> Есть операция перемещения памяти, а не копирования?
Ну да, вынимаешь планку из одной материнки и втыкаешь в другую. Только это имеет такое же отношение к алгоритмам сборки мусора, как и твоя операция копирования.
> Как трейсящий по-русски называется?
Хз. Зачем тебе по-русски? Гугли tracing gc.
Он копирует, а потом старое место высвобождает 🙂
> Зачем тебе по-русски?
Ну эти вещи не настолько элементарные чтобы понимать их на бусурманском.
Ну суть от этого не меняется.
в сипитоне вариация на тему mark & sweep с поколениями.
И там явно отмечено, что он не копирующий:
> Some garbage collectors deal with fragmentation by copying all live objects into a different section of memory and freeing up an entire section of memory, but CPython doesn’t.
А питонистам (даже сеньёрам) подчас похуй совершенно. И в официальной доке про это мало.
На винде IRP_MJ_CLEANUP летит пере выходом из функции. Во что референс каунтинг животворящий делает.
На линуксе (судя по strace) тоже close() случается
Тем не менее, это стандарт это нарушает, и гарантии нет.
зис. Как например никто не гарантирует что str += производится на месте. В сипитоне-то да, а в остальных может быть и нет. Впрочем, всем похуй.