И действительно оказывается, что функции pickle.load() можно дать совершенно разумный тип в Java:
Я бы переформулировал это так: чтобы не писать на уже готовом динамическом языке, который фу-фу-фу, мы (в очередной раз) имплементируем его часть − динамическую систему типов − на нашем любимом статически типизируемом языке. Потому что Serializable − это же только интерфейс. В общем, NIH-синдром в полный рост.
Правда ваша, кто про что, а шелудивый (я) про баню…
С другой стороны, тут также самозародились C, Fortran, ассемблер, Go. А на горизонте маячат загадочные языки без return. Видимо, не я один проморгал тег “Java”.
Этот тест сравнивает эксепшн с if. if, конечно, менее затратен, чем поимка эксепшна, но не способствует читаемости кода. Я сравниваю поимку эксепшна с вызовом функции.
Например, выход из двойного цикла.
Вариант 1 − двойная проверка
def t1():
result = False
for i in range(10):
for j in range(20):
if i == j == 5:
break
if i == j == 5:
result = True
break
return result
Вариант 2 − исключение
def t2():
result = False
try:
for i in range(10):
for j in range(20):
if i == j == 5:
raise Exception
except:
result = True
return result
Вариант 3 − вынос циклов в отдельную функцию
def t3_inner():
for i in range(10):
for j in range(20):
if i == j == 5:
return True
return false
def t3():
result = False
result = t3_inner()
return result
Вариант 4 − for… else
def t4():
result = False
for i in range(10):
for j in range(20):
if i == j == 5:
break
else:
continue
result = True
break
return result
Все варианты выполняются за примерно одинаковое время, ±5%, если верить timeit. Вариант с эксепшном мне кажется наиболее читаемым. Последний вариант − самый быстрый, но и самый нечитаемый. В общем, затраты на обработку эксепшна вполне приемлемы.
бросить почти ни чего не стоит, а перехват обходится дорого.
Во-первых, перехват эксепшна − это никаким боком не дорого в Python. Да, я читал документацию. Тем не менее, технически перехват эксепшна сводится к поиску в некоем фиксированном количестве словарей. Как и вызов функции/метода. То есть если вы хотите оптимизировать, например, выход из двойного цикла, который в других языках можно было бы оптимизировать с помощью goto, то выход с помощью эксепшна в Python будет как минимум так же эффективен, как вынос внутреннего цикла в отдельную функцию. Плюс, выход по эксепшну может быть даже более читаем, чем вариант с объявлением дополнительной функции.
Во-вторых, «никакого разворачивания стека» и «не собирать стек трейс» − это совершенно несопоставимые вещи, вам не кажется?
Исключения для управления потоком выполнения нехороши только потому, что приводят к неопределённым затратам времени на разворачивание стека. То есть в С++ и Java. В Python, например, никакого разворачивания стека не происходит, поэтому исключения стоят столько же, сколько вызовы − пренебрежимо мало в большинстве ситуаций. Поэтому управление потоком выполнения через исключения широко используется в Python, даже в системных библиотеках.
Я, кстати, не в первый раз замечаю, что плюсовики и джависты обобщают свой опыт на все ЯП, включая те, для которых он нерелевантен. Интересно, почему это?
Да, точно, теперь я вспомнил. Вы мне указали на книгу; я нашёл в этой книге (видимо, в более поздней редакции, чем ваша) цитату, которая опровергает вашу точку зрения. Действительно, спорить не о чем.
Я уже спрашивал вас в прошлый раз, кто ещё придерживается такой же точки зрения на типы, что и вы? Откуда вы взяли такую терминологию? Вы мне ничего не ответили, насколько я помню. Есть смысл продолжать?
Абсолютно для всех акселераторов (кроме Oracle F160) нужно 8 линий шины PCI-E.
Получается, вставленные в типичную бытовую материнку с двумя слотами PCIe x16, которые автоматически конфигурируются как x16+x1 или x8+x8, эти платы откусят половину пропускной способности от слота видеокарты? Вот в чём может быть засада для бытового использования.
Или можно как-то обойти этот неприятный момент? Просто посадить флеш-акселератор на x1, или добавить какой-нибудь мост PCIe-PCIe?
Я бы переформулировал это так: чтобы не писать на уже готовом динамическом языке, который фу-фу-фу, мы (в очередной раз) имплементируем его часть − динамическую систему типов − на нашем любимом статически типизируемом языке. Потому что
Serializable
− это же только интерфейс. В общем, NIH-синдром в полный рост.С другой стороны, тут также самозародились C, Fortran, ассемблер, Go. А на горизонте маячат загадочные языки без
return
. Видимо, не я один проморгал тег “Java”.if
.if
, конечно, менее затратен, чем поимка эксепшна, но не способствует читаемости кода. Я сравниваю поимку эксепшна с вызовом функции.Например, выход из двойного цикла.
Все варианты выполняются за примерно одинаковое время, ±5%, если верить
timeit
. Вариант с эксепшном мне кажется наиболее читаемым. Последний вариант − самый быстрый, но и самый нечитаемый. В общем, затраты на обработку эксепшна вполне приемлемы.Во-первых, перехват эксепшна − это никаким боком не дорого в Python. Да, я читал документацию. Тем не менее, технически перехват эксепшна сводится к поиску в некоем фиксированном количестве словарей. Как и вызов функции/метода. То есть если вы хотите оптимизировать, например, выход из двойного цикла, который в других языках можно было бы оптимизировать с помощью
goto
, то выход с помощью эксепшна в Python будет как минимум так же эффективен, как вынос внутреннего цикла в отдельную функцию. Плюс, выход по эксепшну может быть даже более читаем, чем вариант с объявлением дополнительной функции.Во-вторых, «никакого разворачивания стека» и «не собирать стек трейс» − это совершенно несопоставимые вещи, вам не кажется?
Я, кстати, не в первый раз замечаю, что плюсовики и джависты обобщают свой опыт на все ЯП, включая те, для которых он нерелевантен. Интересно, почему это?
Значит, вы и есть та самая тётя.
Или можно как-то обойти этот неприятный момент? Просто посадить флеш-акселератор на x1, или добавить какой-нибудь мост PCIe-PCIe?