Andrey Dugin

Я делаю так, если уж приспичит, но нужно стараться делать выражения проще и читабельнее:

print(*[
    str(int(i) ** 2) 
    for i in input().split(' ') 
    if int(i) % 2 == 1 and str(int(i) ** 2)[-1] != '9'
])

Для сложных кусков правил несколько:
- не экономьте строки.
- открытые скобки (любые) намекнут питону, что оператор еще не закончился.
- ни к чему лишний раз ставить символ переноса строки, это может привести к ошибкам.
- не экономь на спичках: если кусок алгоритмически сложен, не нужно экономить на промежуточных переменных, это позволит сделать код понятнее. Если уж хочется освободить память пораньше, то можно удалять переменные, но всё должно быть целесообразно.
- если уж нагородил литералов сборки спика или словаря, отформатируй их понятно.

https://docs.python.org/3/library/collections.html...

Можно попробовать перевести дату и время по отдельности к типу str, затем через пробел сделать конкатенацию, после чего полученное выражение подать на вход функции pd.to_datetime, которая вернет полноценный datetime формат искомых значений.

В случае, если изначальные даты у вас в формате datetime сделать так:
pd.to_datetime(df['start_date'].dt.date.astype(str) + ' ' + df['start_time'].dt.time.astype(str))

А если изначальные даты в строковом формате, то опустить "dt.date" и "dt.time" части.

UPDATE

Еще можно сделать так, например:
date = pd.to_datetime('start_date')
time = pd.to_timedelta('start_time')
date + time
Чтобы получить datetime формат следует сделать следующее:
(date + time).to_pydatetime()

С помощью ctypes:

import sys
import ctypes
import ctypes.wintypes as wintypes


PROCESS_ALL_ACCESS = 0x1F0FFF

kernel32 = ctypes.windll.kernel32

kernel32.OpenProcess.restype = wintypes.HANDLE
kernel32.OpenProcess.argtypes = [
    wintypes.DWORD,
    wintypes.BOOL,
    wintypes.DWORD
]

kernel32.CloseHandle.restype = wintypes.BOOL
kernel32.CloseHandle.argtypes = [ wintypes.HANDLE ]

kernel32.WriteProcessMemory.restype = wintypes.BOOL
kernel32.WriteProcessMemory.argtypes = [ 
    wintypes.HANDLE,
    wintypes.LPVOID,
    wintypes.LPCVOID,
    ctypes.c_size_t,
    ctypes.POINTER(ctypes.c_size_t)
]


pid = int(sys.argv[1])
addr = int(sys.argv[2], 16)

val = 42
buf = (val).to_bytes(4, byteorder='little')
buf_ptr = ctypes.c_char_p(buf)

ph = kernel32.OpenProcess(PROCESS_ALL_ACCESS, False, pid)
kernel32.WriteProcessMemory(ph, addr, buf_ptr, len(buf), None)
kernel32.CloseHandle(ph)

Взять бумажку.
Нарисовать пример двух вписанных в прямоугольник окружностей.
Подумать.
Заподозрить, что точка соприкосновения окружностей всегда будет лежать на линии, соединяющей их центры. Доказать это.
Провести линию между центрами окружностей и перпендикуляры от центров к сторонам прямоугольника.
Сообразить, что нужно просто определить, влезет ли линия между центрами в габариты прямоугольника минус радиусы окружностей...
Немножко посчитать.

Парсинг — это чуть ли не первое в списке того, ради чего стоит использовать асинхронность. Чем больше IO операций — тем больше преимуществ у асинхронного подхода перед тредпулом. Если при парсинге необходимо выполнять CPU-bound операции (разбор XML/HTML и прочее) — это выносится в тредпул (для питона — процеспул) и через асинхронные биндинги (например, в питоне это run_in_executor) отдаётся на откуп туда, главный же поток при этом не блокируется.

Пример на коленке, который парсит граф ссылок с википедии, с процесспулом, lxml и прочими ништяками: тык

Я не знаю, какая у вас выборка, но на всякий случай стандартное отклонения я бы считал, задав np.std (data, ddof = 1).
По моему представлению, правильный вариант - с использованием ttest_ind(ctrl, test, equal_var=False). С ним я бы и сравнивал.

Как наиболее оптимизированно это реализовать?

С помощью Базы Данных. Если взять Sqlite3, то можно уложиться в 15-30 строк кода.

Разбить весь текст на предложения, а внутри на слова. Затем 2 цикла один по предложениям в этом вложенном словаре, другой - по списку уникальных слов. И для каждого уникального слова считать кол-во его вхождений в текущее предложение (через count).
Через list_comprehension будет выглядеть так

[[sentence.count(word) for word in unique_words] for sentence in sentences]

где unique_words - это собственно список уникальных слов
sentences - вложенный список слов по каждому предложению.

Разбить на предложения и слова наверное проще регулярными выражениями

# по предложениям
re.split(r'[\.!\?]', text)
# по словам
re.split(r'[\n \.,!\?]', text)

Удачи.

такой eval нельзя использовать лишь потому, что это небезопасно. Фактически, если использование eval не усугубит ситуацию, то почему бы не использовать.
Довольно сумасшедшая идея ходить с открытой раной по улице. Но в защищенной среде в больнице между перевязками - это штатная ситуация, хотя и не отменяет необходимости быть осторожным.

Оголённые провода в жилом помещении - это недопустимо, но в фазные шины с правильной маркировкой в электрощитовой, наверно, допустимы.
Это касается не только eval.
Однажды я слышал от студента примерно следующие рассуждения, когда ему требовалось написать простейший калькулятор:

eval использовать нельзя (небезопасно), поэтому я пользовательский ввод записываю в питоновский файл и этот файл импортирую как модуль...

Если нужно четко условие "И по длине И по ширине больше остальных":

from functools import reduce

a = [[1, 6], [3, 5], [3, 6], [7, 7]]
result = reduce(lambda res,x: x if x[0]>res[0] and x[1]>res[1] else res, a)
print(result)

[7, 7]

В питоне функции и классы - это тоже объекты. У них есть особый синтаксис объявления, после объявления эти объекты доступны по имени как и любой другой объект с именем (переменная).

Лирическое отступление. В питоне переменные работают не так же как в Си. В Си переменная - это ящичек, а значение в нём как бы лежит. В питоне объект - это как чайный пакетик, а имя как ярлычок на ниточке. Можно к одному пакетику несколько ярлычков привязать, то есть несколько имён. В Си это достигается указателями. В питоне, получается, всё "как бы указатели" и разыменовываются они неявно, под капотом. Но сейчас не о том...

Есть такой паттерн проектирования - декоратор. Декоратор - это функция, которой в аргументе передаётся какой-то объект, а на выходе она возвращает другой объект, каким-то образом задекорированный. В реальной жизни декорация объекта - это, скажем, раскрасить ассенизаторную машину под божью коровку или сделать заточку из ложки (есть, по-прежнему, можно, но можно и пырнуть)... Также декоратор может и вовсе подменять объект полностью, к примеру, нам даётся пластилиновая фигурка, а декоратор - это процесс заливки её её гипсом и производство формы под литьё. Пластилин из готовой формы выковыряли и выкинули, а декоратор - это процесс (функция) производства формы из пластилиновой фигурки.

Повторюсь, в общем случае декоратор - это функция, которая либо немного меняет какой-то объект, либо делает на его основе или по его мотивам какой-то новый. Новый при этом может как содержать старый внутри, так и не содержать. Декоратор может и вовсе не трогать сам объект, а возвращать его без изменения, зато регистрировать его в каком-то внешнем списке создавая так называемый сайд-эффект. Примеров можно придумать уйму.

Итак:

my_object_instance = MyClass()
my_object_instance = my_decorator1(my_object_instance)
my_object_instance2 = my_decorator2(my_object_instance)

В этом примере дважды задекорирован объект. Здесь при первом декорировании оригинал нам, судя по коду, не нужен (или декоратор его не менял, смотря что за декоратор, может просто зарегал где-то в списке...), а при втором декорировании нам остаётся доступным и оригинал и задекорированная версия.

Пока всё просто и не ясно причем тут собаки и чем эти декораторы отличаются от обычных функций. На второй вопрос ответ прост -- ничем особенным. Просто мы такой смысл вкладываем в эти функции. Такая абстрактная концепция.

В Питоне есть синтаксический сахар, чтобы декорировать объявления функций и классов.

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

my_pretty_functions = {}

def my_deco(decorated_function):
    '''Это декоратор, который не меняет декорируемый объект, 
    лишь регистрирует его в словаре'''
    my_pretty_functions[decorated_function.__name__] = decorated_function
    return decorated_function

def my_function(x):
    return x ** 2

# вот декорирование вручную, без сахара
my_function = my_deco(my_function)

# Но в питоне же есть сахар для этого, и вот альтернативный вариант декорирования:
@my_deco
def my_other_function(x):
    return x ** 3

Эти два способа декорирования работают одинаково, просто "собака" - это синтаксический сахар.

Не все декораторы такие безобидные. Декоратор может вернуть совершенно другую функцию или вообще что угодно. Тогда это что угодно окажется под оригинальным именем функции, а оригинальная функция вовсе может быть потеряна (выброшена) или засунута в новую с помощью так называемого "замыкания".

Но замыкания - это отдельная большая история, а узнать об этом вы сможете, к примеру, на занятиях по питону на otus.ru, где я скоро, надеюсь, стану преподавать=).

Спрашивайте сто не понятно. Я тут не рассмотрел даже малой доли от разных способов применения декораторов в народном хозяйстве. Надо будет состряпать специальный курс про это.