Python - это лучший язык программирования! Говорю как бывший С/C++ программист с почти 20-летним стажем.

был неплохой язык. жаль они обсрались с двумя ветками питонов. зато теперь пишу на F# - намного лучше, проще и мощнее и кромплатформенно.

Нет, теперь OrderedDict - это тонкая обертка вокруг dict, сам dict переписали: https://bugs.python.org/issue27350

http://pythonz.net/articles/76/

И что с чем я компоную?

restFiles = [os.path.join(d[0], f) for d in os.walk(".") if not "_test" in d[0]
             for f in d[2] if f.endswith(".rst")]

https://ru.wikipedia.org/wiki/Списковое_включение

За щеку себе скомпонуй, изобретатель терминологии.

компоновки

Интересный перевод, неплохо выглядит.

А питон-то все монструознее становится. Так, взгляд со стороны

компоновать — составлять целое из частей

Не знаю, кому как, а мне «включения списков/словарей/etc» режут слух. Здесь уж действительно не понятно, что и куда включем. Поэтому ранее я предпочитал кальку с английского. «Компоновка списков/словарей/etc» гораздо лучше выглядит.

За щеку себе скомпонуй, изобретатель терминологии.

Эти твои «включения» как только не называют. Если ты не можешь спокойно реагировать, то советую обратиться к доктору.

У тебя какой-то неправильный Python, в 2.7 и 3.4:

In [1]: 'Лутц' == 'быдлокодер'[5:]
Out[1]: False

составлять целое из частей

Но ведь мы не составляем целое из частей, мы описываем трансформацию. Ближайшая аналогия SQL-запрос (трансформация отношений кортежей), linq из сишарпа, и т.п.

Эти твои «включения» как только не называют

Ну да, определение Васяна более авторитетно, чем определение из Википедии.

не можешь спокойно реагировать, то советую обратиться к доктору.

Закономерная реакция на попытку форсить унылый васянский креатив.

restFiles = [os.path.join(d[0], f) for d in os.walk(".") if not «_test» in d[0] for f in d[2] if f.endswith(".rst")]

код в стиле «смотрите как я умею!» обычно нормальные люди через code review не пропускают.

Бесплатный код ревью! Мерси.

Может человек всю жизнь патчи Бармина пишет.

А теперь прикинь сколько его в Linux.

Посмотри в сторону golang. Забросил питон именно из-за него.

Но ведь мы не составляем целое из частей

Почему же? Из элементов одного итерируемого объекта составляется новый. Я могу вообще ничего с ними не делать. А вот как из «включения» получить «трансформацию», когда под включением подразумевается что что-то становится частью чего-то? Ведь по сути это почти тоже самое, что и компоновка, разве не так? Только компоновка однозначна, в отличии от, потому что может быть непонятно что и куда включаем.

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

Ничего подобного. Просто не работай в конторах где надо поддерживать легаси-код. Кто мешает?

Из элементов одного итерируемого объекта составляется новый

Это и есть трансформация.

когда под включением подразумевается что что-то становится частью чего-то

Выражение-описатель списка/генератора/словаря/чего угодно (вот откуда взялось постижение, да?) становится частью кода. Т.е. мы включаем в свой код comprehensive description (declaration) того самого генератора. Короче, включаем инлайн-декларацию генератора. А в сишарпе мы вообще включаем sql-like код в блок.

А что не так-то? Я недолюбливаю питон, но эта конкретная фича ведь прекрасна. Скриптовать стало проще.

Потому что изначально не предусмотрели хоть какой-то возможности расширения языка средствами самого языка. Теперь приходится городить костыль на костыле.

А так-то, в 90-х, питон и правда был неплохим языком для quick-n-dirty скриптов.

Держи нас в курсе, твое мнение очень важно.

язык из табуляций который умеет хорошо одну вещь (для которой и предназначен): бросать ексепшены.

анонимус умеет хорошо одну вещь (для которой и предназначен): бросать какахи.

Надо было им ещё официально и серьёзно ввести разные переменные окружения для разных версий. Например, не просто $PYTHONPATH, а $PYTHONPATH2 и $PYTHONPATH3. А то после настройки $PYTHONPATH для Python 3 не работает Python 2. Правда, как выясняется, Python 2 знает $PYTHONPATH2, но $PYTHONPATH сбивает его с толку. А Python 3 $PYTHONPATH3 не знает. Получается чехарда с необходимостью переопределения $PYTHONPATH при переключении между версиями Python'а.

А, вообще, по хорошему, лучше бы были конфиги в хомяке.

А зачем это нужно то вообще?

Зачем нужно настраивать $PYTHONPATH? Затем, чтобы в случае нестандартных путей они были найдены. Случаи бывают разные, но один из них таков: если хочется покрасноглазить левой пяткой и загнать весь базовый Python в /usr/lib64 минимальными усилиями. Левой пяткой в случае того же сабжевого Python 3.6.0 это делается так:

sed -i 's/\/usr\/lib\//usr\/lib64\//g' setup.py
sed -i 's/\/local\/lib\//local\/lib64\//g' setup.py
sed -i 's/lib\/python/lib64\/python/g' configure
sed -i 's/\"lib\"/\"lib64\"/g' Lib/site.py
...
sed -i 's/SCRIPTDIR=\t$(prefix)\/lib/SCRIPTDIR=\t$(prefix)\/lib64/' Makefile

export PYTHONPATH="/usr/lib64/python3.6:/usr/lib64/python3.6/lib-dynload"

Ну и зачем его туда загонять? Не понимаю.

Затем, что в мультилибовых системах есть необходимость разделять библиотеки как-то так:

/usr/lib - 32-х битные бинарники
/usr/lib64 - 64-х битные бинарники

Т.е. ты хочешь на 64 битной системе держать 32 битный питон? Но ты так и не объяснил, зачем это надо?

Нет. На 64-х битной 64-х битный. Но, в /usr/lib64. Потому, что /usr/lib для 32-х битных библиотек, а у 64-х битного Python'а они 64-х битные. А для 64-х битных библиотек /usr/lib64.

multilib, напоминаю, это когда в 64-х битной системе можно держать параллельно и 32-х битные библиотеки. И во избежание конфликтов файлов принято разделять библиотеки по разным директориям. Одна специально для 64-х разрядных библиотек, а другая - специально для 32-х разрядных.

Строковая интерполяция. Хитро вывернулись, надо отметить.

Да. Взгляд со стороны старого питона.

Зачем жизнь усложнять? Мне вот нравится чистый питон.

Вот например:

imgfiles = [path.join(d, x) for d,_, fn in walk("img") for x in fn if x[-4:] in [".jpg",".png",".gif","jpeg"]]

f = lambda x: path.getsize(x)

fsz = [ (x, f(x)) for x in imgfiles ]

Хочу иметь возможность последнюю строку разбить и выполнить в двух тредах

fsz1 = [ (x, f(x)) for x in imgfiles[0:int(len(imgfiles)/2)] ]
fsz2 = [ (x, f(x)) for x in imgfiles[int(len(imgfiles)/2):] ]

или пусть f возвращает sha256, а не размер

Это ресурсоемкие вычисления? Нет, в самом деле?

А зачем это нужно то вообще?

Дебил? Установи в убунту питон 3.6 с оффсайта и попытайся позапускать скрипты с любого места системы по выбору: во встроенном питоне или в 3.6. И еще нужон 2.* для некоторых прог от дебилоидов-ретроградов, которые не могут в 3.

Вот именно, что нет. Я подожду когда меинтенеры соберут. Или же буду юзать арч, как я и делал.

Этим меинтейнеры занимаются вообще-то.

Выполняй, что мешает? Inb4: gil, но он здесь не помеха.

Можно быть и самому себе маинтейнером. Тем более, что и дистрибутивы бывают разные.

Кстати, Python 3.6.0 пока ещё нигде официально не опакетили. Даже в testing'е Arch'а его ещё нет.

Я подожду когда меинтенеры соберут

Есть тут на лоре один(?) тип, который в своём стабильным дебиане использует софт только из офф репов. Тухлый qt(для разработки), плесенелый blender и прочее. Ты такой же?

Мешает бессмысленность. Выполняться-то они на одном и том же ядре будут. Чо там про гил не помеха? Кому он не помеха?

С пулом из multiprocessing параллелятся, но это выглядит убого. А с тредами - видимость одна.

Выполняться-то они на одном и том же ядре будут

Кто тебе такое сказал? Треды питона выполняются в нативных тредах, а глобальный лок - он только для питоновского кода, у тебя же все будет в ожидании результата от системных / сишных api (точнее, перед входом в блокирующий C-api call будет выполнен релиз GIL, и тред может висеть в этом состоянии сколько угодно, без воздействия на интерпретатор), если конечно ты pure-python sha256 не впендюришь, лол. Короче, проблема надуманная.

Сказал опыт. И монитор загрузки процессора. Но хорошо признал, что все-таки питоний код параллелить нельзя. Теперь другая отмазка: это не тренды в Питоне говно, это просто так надо. Ясно.

Естественно, надо понимать, что ты делаешь. В лоб писать хайперфоманс (потому я и написал, что язык не про него, все нагруженное нужно выносить в нативный код) — результаты будут плачевные.

*треды, чертова клава

Ну вот знаю я, что треды в питоне одна видимость и что простые и очевидные (казалось бы) вещи решаются через задницу. А мне хотелось бы, чтобы простые и очевидные вещи решались просто и очевидно. Потому и говорю, что вместо асинхронных генераторов лучше бы наконец гил убрали.

Тогда лучше возьми какой-нибудь язык под JVM, там такой проблемы нет, или пиши на плюсах. GIL врядли когда-то выпилят, в мире сетевых сервисов, скриптинга повседневных задач, и научных вычислений, он никому не мешает, а что-то другое редко пишут на питоне.

Вот он, патч для Python'а 3, который учит его смотреть в $PYTHONPATH3. Таким образом, можно настроить ему $PYTHONPATH3, и это не поломает Python 2:

sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' PC/getpathp.c
sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Modules/getpath.c
sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Mac/IDLE/IDLE.app/Contents/MacOS/IDLE

читал и его и еще остальных, эфекта 0.

и не сравниваю в том то и дело в том смысле в котором ты подразумеваеш повидимому, а сравниваю в том смысле что что нужно сделать на питоне что бы апосля сказать хм я походу знаю основы программирования, и что такое основы программирования, как определить этот порог, ведь не способностью к написанию хело ворлд

мы с другом вчера началм писать интерпретатор питона на расте, желающие принять участие пишите тут! давайте объединимся и напишем быстрый и безопасный интерпретатор этого замечательного языка. хотим успеть за каникулы и это вполне реально! станьте частью команды, меняйте мир с нами