Python 3.2.1

> Межпроцессное же

Первое использовать тоже не помешает)

Понравился мне питон забавным синтаксисом. Короткие объявления функций и классов. Блоки кода объединяются одинаковыми отступами. И вообще только в питоне я узнал про threads, создал окно одним оператором, написал первую действительно полезную хотя бы самому себе программу. Короче очень простой язык для начинающих, эдакая огромадная дубина, которую легко поднять и легко не туда долбануть ей. Вообще интересно почему так много интерпретируемых языков?

Больше эту новость как и многие другие я открывать не буду. Единственная польза для меня от лора - это банк информации по полезным, новым программам. Не думал не гадал, а как-то раз нашёл программу генерации своих собственных стереограмм.

Список нововведений неплохой. Рад за язык, он развивается. К сожалению GIL и некоторые другие признаки неправильного дизайна до сих пор напоминают нам о том, что язык был создан не для промышленного использования, а для обучения. Для серьёзного применения нужно что-то посерьёзней. Но для маленьких проектов, и обучения новичков, языки вроде Python/Ruby - отличный вариант.

Бывают языки вроде Scheme - которые могут показаться сложнее питона, но дизайн у них ближе к их промышленным аналогам. А питон именно для новичка хорош, потом надо переползать в сторону C/C++/C#/Java, или можно оказаться в такой абсурдной ситуации, как у разработчиков Facebook. Которые похожи на кота, жрущего кактус: юзать MySQL и PHP на масштабных проектах.

Список нововведений неплохой…

Думал паста, ан нет. Очень неплохой подход, очень.

джанга не нужна пока не запилят поддержку третьего питона //fixed

>«Должно работать быстрее кода на C!!!»

Догоним и перегоним ассемблер, а там и до Java рукой подать.

_________

//wfrr

>А питон именно для новичка хорош

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

_________

//wfrr

> Полгода вася пытался понять почему если программу на питоне открыть и сохранить вордом

программу ... сохранить вордом

Васи, использующие офисные пакеты (LO/MSO/OO.o/etc. — не важно) для написания/редактирования программ (офисные макросы не в счёт), не нужны.

проеблы

Старина Фрейд гордится тобой.

Как и деление языков на категории «промышленные» и «для обучения».

Это не баг, это фича.

Действительно, даешь с++ на уроках информатики в пятом классе!

Почему у вас уроки информатики ассоциируются с программированием на каких-то определённых языках? Вы хотите поговорить об этом?

А у вас уроки информатики с формулами Бэкуса-Наура ассоциируются? Или с общей теорией информации?

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

>В остальном ооооочень часто можно поднять производительность просто изменив алгоритмы. Я вот повышал в 10 раз изменяя три четыре строки

Простите, но вы быдлокодер. Хорошо, что вы пытаетесь вырасти из этого состояния.

Тем не менее, на учебном by design Паскале можно и промышленный код писать.

Ну дак и на VBA пишут промышленный софт. Контур-Актив во всем своем разнообразии тому яркий пример. Но это не делает язык подходящим для таких вещей.

> А ABI — это о том, что .so для 3.2.1 подойдёт и для 3.2.2 Ви так говоr'ите, будто сейчас внутри ветки типа 2.7 надо модули пересобирать.

ABI меняется только между мажорными ветками. Если он будет один и тот же для 3.2 и 3.3, например, это, конечно, славно.

чем плох паскаль для промышленного применения?

Ну дак и на VBA пишут промышленный софт.

VBA ни в коем случае не учебный язык.

GIL создан намеренно и не избавляются от него намеренно. А ты иди матчасть поучи.

VBA = Visual Basic for Applications

Уж бейсик то точно не для энтерпрайза создавали.

chinarulezzz
Pascal тоже был учебным языком. Другое дело, что на его основе создали Delphi, а сейчас и Lazarus с FreePascal. Насколько этот язык эффективен в реальной разработке, я не берусь судить, потому что последний раз его использовал лет 9 назад на первом курсе и сейчас уже благополучно забыл его синтаксис и возможности.

Проще говоря — будет некоторая версионность Python ABI и гарантия наличия тех или иных фич, на сколько я понял.

Уж бейсик то точно не для энтерпрайза создавали.

Бейсик, может быть. А VBA — голимый энтерпрайз.

> Delphi ... Насколько этот язык эффективен в реальной разработке

Delphi — одна из первых сред разработки, ориентированных на быструю разработку приложений (RAD). В сочетании с синтаксисом популярного в обучении программированию паскаля, ИМХО, делфи можно считать первопроходцем и чуть ли не эталоном (в не самом хорошем смысле этого слова) в области формошлёпства. Результат — популярность среди школотоподобного народа и прочих любителей по-быстрому накидать на форму кучку контролов и компонентов, после чего так же по-быстрому двойными кликами наклепать обработчики их событий, производя при этом эпичный говнокод с адским форматированием, кучей неинформативных идентификаторов типа Button123, TreeView4 и прочей подобной трудночитаемой (о том, чтобы как следует разобраться в таком коде, я уже не говорю) мутью.

Мне тут недавно удалось посмотреть на кусок кода вполне себе ынтерпрайзной софтины (САПР ТП), сделанной именно в Delphi. Лучше б я этого не видел...

Я знаком с многопоточным программированием, писал даже под оффтоп на ассемблере MASM что-то когда-то... И про потоки, и про семафоры(в том числе мьютексы), и про локи я в курсе. И почти на всех компилируемых языках, да и многих интерпретируемых многопоточность реализованна правильно.

А вот пистон с его GIL - это адское подделие. Из-за особенностей реализации GIL(а именно из-за уродского дизайна подсистемы связывающей модули расширения CPython, общие структуры памяти для модулей расширения на C, и кода на Python) мы имеем крайне неэффективное использование много-поточности в силу крайне не эффективного переключения потоков. И того факта, что даже при наличии ста ядер у ПК, интерпретатор CPython в один момент может предоставить доступ к некотором внутренним структурам данных интерпретатора всегда одному потоку.

Посылка сигналов потокам тоже крайне не эффективна, в силу всё той-же убогости дизайна. И проблема не в GIL - он был создан из-за необходимости разрулить хоть как-то ситуацию с многопоточностью в CPython.

Проблема на самом деле в убогом дизайне самого интерпретатора, ядро которого имеет похабный дизайн. И изменить ничего нельзя, ведь навернётся совместимость с расширениями Python написанными на C. А без этих расширений этот язык - пустышка.

Вот Iron Python и Jython не имеют проблем с GIL, просто потому, что у них нет убогого дизайна CPython с его расширениями. А вызов кода на C из Jython строится на основе потокобезопасного, прекрасного механизма JNI. В .NET система вызова низкоуровневого нативного кода тоже прекрасна, в отличии от CPython. Надо просто перевести основную реализацию CPython с C на нормальную VM, и проблемы с расширениями, потоками и памятью отпадут сами.

P.S.: Вы можете не верить мне в данном вопросе, ведь я не являюсь профессиональным программистом(всегда хотел им стать, но пришлось после 12 классов валить на работу в сферу торговли). Просто иногда жизнь заставляла мяня что-то делать, и приходилось изучать некоторые вещи. Много лет имею дело с компьютером, но в основном я оказываю помощь знакомым или делаю что-то для личного использования. Иногда использую и Python, поэтому знаю о его достоинствах и недостатках. Хотите реально оценить всю ширину проблемы GIL? Тогда гляньте на эти статейки:

• http://wiki.python.org/moin/GlobalInterpreterLock
• http://habrahabr.ru/blogs/python/84629/
• http://asvetlov.blogspot.com/2011/07/gil.html

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

Нда, идентификаторы типа Button123 - вещь серьёзная. Меня аж улыбнуло:) В своей первой программе с небольшой формочкой я когда-то именно так и сделал. Выходит, не я изобрёл сей метод. А жаль, запатентовал бы в Пендосии и денег со школярусов срубил... Теперь то я использую camel case и вменяемые названия, чётко указывающие на функцию контрола. Но до этого ещё додуматься надо было.

> Вы можете не верить мне в данном вопросе, ведь я не являюсь профессиональным программистом(всегда хотел им стать, но пришлось после 12 классов валить на работу в сферу торговли)

Эпик. Ты хоть скромнее будь, а то всё «похабный дизайн» да «убогий» - как будто сам ты сделал несколько масштабируемых интерпретаторов.

ну вот... Не помнишь, забыл, не знаешь и не пробовал а судишь :)

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

О Паскале вам уже несколько раз ответили выше. Вы можете делить языки на учебные и промышленные, если вам так нравится, и за уши притягивать каждый конкретный язык в ту или иную категорию… Но зачем?

ссылки на PEP 384 и PEP 391 в новости битые, надо нолик в начало числа дописать (e.g. 0384). поправьта, пожалуйста

Он когда-то опечатался, с тех пор, видимо, пишет так спецом. А ведь действительно не в бровь :)

> А вот пистон с его GIL - это адское подделие. Из-за особенностей реализации GIL(а именно из-за уродского дизайна подсистемы связывающей модули расширения CPython, общие структуры памяти для модулей расширения на C, и кода на Python) мы имеем крайне неэффективное использование много-поточности в силу крайне не эффективного переключения потоков. И того факта, что даже при наличии ста ядер у ПК, интерпретатор CPython в один момент может предоставить доступ к некотором внутренним структурам данных интерпретатора всегда одному потоку.

Да при чем здесь неэффективность? Еще раз, если бы сделали как в Jython (вот нормальное объяснение (хоть и упрощенное) http://morepypy.blogspot.com/2011/06/global-interpreter-lock-or-how-to-kill.html ) — то есть при каждом обращении к изменяемой (mutable) структуре — получать на нее лок — был бы CPython таким же тормозом, как Jython. Собственно, попытка уже была, и осознали, что CPython станет в 2 раза медленнее при однопоточной работе.

Потому решено было оставить GIL, поскольку CPython тормоз, а CPython хитро оптимизировать не получится, потому что его оставляют «чистым» для расширения легкого и хакинга. Вот дилемма.

Таки PyPy спасет ситуацию скоростью, а там, глядишь, и GIL уберут.

Ну, я честно признаю - я не программист. Но как устроена работа многопоточного приложения, я знаю. А также я знаю и то, что на такой вот глобальный лок наткнуться можно только в ПО, которое defective by design. Мало того, я ведь могу смотреть и на другие ЯП. Есть ведь LISP,Java,C# и прочие языки, которые не имеют проблем с параллельным выполнением кода в потоках. И не надо даже быть программистом, что-бы понять: создатели пистона плохо думали над дизайном в начале, тогда, когда потоки казались не очень нужными. Времена меняются, и сегодня параллельное выполнение - это обязательное требование к современному ПО. Даже школьники могут это понять, уровень образования для понимания таких очевидных ляпов не так уж и важен. Вы же сами понимаете, что Python стал заложником старого кода, ради поддержки которого на сегодняшний момент не возможно полностью переписать интерпретатор. То, что в Python 3.2 GIL немного усовершенствовали - это уже победа. Решить эту проблему в ближайшие 10 лет невозможно. Отбросив модули на C и совместимость со старым legacy-кодом, Python потеряет своё единственное преимущество. И другие подобные языки его просто порвут. Тот же Jython или Groovy отстают от пистона только из-за наличия у последнего нехилых «батареек в комплекте».

Про PyPy я читал. Вроде даже от GIL там намерены избавится серьёзно. Но это проект, который носит экспериментальный характер. По сути дела, это прототип. Полигон для обкатки идей. И многие из них - правильные. Например, использование JIT увеличивает потребление памяти(но она нынче дешёвая и доступная), но зато увеличивает быстродействие программы в разы. Ну, и разработка в проекте ведётся активно. Вот только одно моё подделие на PyQt почему-то не завелось на нём. Видно, модули на C оно цеплять как надо не умеет.

defective by design

Нет, тебя точно можно на макароны раздергивать. Какая концентрация спорных утверждений!

> Ну, я честно признаю - я не программист. Но как устроена работа многопоточного приложения, я знаю. А также я знаю и то, что на такой вот глобальный лок наткнуться можно только в ПО, которое defective by design.

Еще раз. GIL сделан _специально_ и его можно убрать и сделать как в Java, но тогда будет еще в 2 раза медленнее на однопоточных программах, а многопоточнасть нормальная (вычислительная) питон-программам нужна очень редко (да еще и чтоб через multiprocessing не решалась). Так что не defective а наоборот.

> Про PyPy я читал. Вроде даже от GIL там намерены избавится серьёзно. Но это проект, который носит экспериментальный характер. По сути дела, это прототип. Полигон для обкатки идей. И многие из них - правильные. Например, использование JIT увеличивает потребление памяти(но она нынче дешёвая и доступная), но зато увеличивает быстродействие программы в разы. Ну, и разработка в проекте ведётся активно. Вот только одно моё подделие на PyQt почему-то не завелось на нём. Видно, модули на C оно цеплять как надо не умеет.

Плохо читал, видимо. Нет, не намерены там избавляться серьезно, а готовы в качестве эксперимента попробовать.

Это не прототип, а уже готовый и совместимый с Python 2.7 интерпретатор. Никакой это не полигон для обкатки идей.

Да, поделия на PyQt работать не будут и непонятно когда начнут, потому что эта задача не в приоритете (расширения на Си). Разве что CTypes допилят скоро вроде. А в приоритете сейчас — на чистом питоне весь код сделать исполняемым быстро. И пока у них получается (и я и многие другие уже новые проекты на pypy спокойно пишем).

> многопоточнасть

:-D о, конечно же

Какой годный был у меня вброс. Бедные питонеры всегда бесятся, когда наезжают на их священный грааль - GIL. Вот фаны Ruby - скучный народец, все такие правильные, тихие:( А фаны пистона - на редкость фанатичны.

Да я читал среди документации на официальном сайте об этом. И про снижение скорости работы на однопоточном коде я тоже в курсе. И про устройство GIL я тоже читал не мало. Но есть одно но - всё больше многоядерных машинок у юзверей, которые просто просят загрузить все их ядра. Я конечно знаю, что можно задействовать не процессы, а потоки. И такой подход даже приносит дополнительные бонусы. Но, с точки зрения дизайна GIL - костыль обыкновенный. Да легче с ним ходить, опираясь на одну ногу(ядро процессора), а когда гипс снимут(прейдёт время для параллельных вычислений на сотне процессорных ядер)? Количество ядер нарастает, и в такой вычислительной среде чем больше потоков - тем больше плюшек. Особенно хорошо, если работа потоков идёт в асинхронном режиме. Ведь синхронизация много времени отнимает, особенно на Python версий до 3.1 включительно:)

> Какой годный был у меня вброс

Сам себя не похвалишь...

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

Нет, ну это уже неприличное какое-то вбрасывание :-D Если есть много ядер — еще не значит, что они нужны. Особенно для питонячьих задач.