Решение с использованием list.index
:
def indices(lst, element):
result = []
offset = -1
while True:
try:
offset = lst.index(element, offset+1)
except ValueError:
return result
result.append(offset)
Это намного быстрее, чем понимание списка с enumerate
для больших списков. Он также намного медленнее, чем решение numpy
, если у вас уже есть массив, в противном случае стоимость преобразования перевешивает коэффициент усиления (проверяется на целых списках с 100, 1000 и 10000 элементами).
ПРИМЕЧАНИЕ. Замечание, основанное на комментарии Chris_Rands: это решение быстрее, чем понимание списка, если результаты достаточно разрежены, но если в списке есть много экземпляров элемента, который выполняется поиск (более ~ 15% списка, при тестировании со списком из 1000 целых чисел), понимание списка выполняется быстрее.
Теперь он может быть легко исправлен для Python 3.6+ этим классом (потомок FTP_TLS):
class MyFTP_TLS(ftplib.FTP_TLS):
"""Explicit FTPS, with shared TLS session"""
def ntransfercmd(self, cmd, rest=None):
conn, size = ftplib.FTP.ntransfercmd(self, cmd, rest)
if self._prot_p:
conn = self.context.wrap_socket(conn,
server_hostname=self.host,
session=self.sock.session) # this is the fix
return conn, size
Вероятнее всего, проблема vsftpd, чем ftplib, поскольку вы упоминаете обновление до новейшей версии, исправила проблему.
Если вы не можете прикасаться к настройкам сервера, подкласс класса FTP_TLS
может помочь решить проблему ваша проблема, хотя, на мой взгляд, это довольно HACK , ссылаясь на этот вопрос SO & amp; ответы Проблема подключения к FTP TLS Python . Вы также можете взглянуть на эту ошибку python bug issue 19500 :
". Разумно для сервера настаивать на том, что подключение к данным использует кешированный сеанс TLS. может быть кешем предыдущего подключения к данным или очищенного соединения управления. Если это является причиной отказа в передаче данных, тогда ответ «522» должен указывать на это.
Примечание: это имеет большое влияние на дизайн клиента, но позволяет серверам минимизировать циклы, используемые во время переговоров TLS, отказываясь выполнять полное согласование с ранее прошедшим проверку клиентом ».
Похоже, что сервер vsftpd реализован именно так, «повторное использование сеанса SSL между соединением управления и данными».
http://scarybeastsecurity.blogspot.com/2009/02/vsftpd-210-released.html
Глядя на источник базовой библиотеки Python ftplib.py, нет никакого отношения к идее повторного использования сеанса SSL между соединением передачи данных и контрольным соединением (исправьте меня, если я ошибаюсь здесь. Я пробовал FTP_TLS.transfercmd (cmd [, rest]) ¶, не работал).
Эта проблема хорошо документирована на других FTP-клиентах, поддерживающих FTPS, I.E. WinSCP: https://winscp.net/tracker/668
См. Файл тестового журнала. Сервер vsftpd с требованием «require_ssl_reuse», установленным в true в vsftpd.conf, выполнит трюк и может быть воспроизведен.
blockquote>Надеюсь, что это поможет.