Здравствуйте. Я хочу изучить программирование на питоне. Дайте пожалуйста список тем которые надо изучить

Начни с ассемблера.

статика только усложняет

не пейсал - не выпендривайся

спортивного кода

шта

Хорошее оглавление, где взять это материал? Это книга?

https://ru.wikipedia.org/wiki/Титон_(мифология)

++

Лучше бы ТС начал с С. Если ему ООПщина понадобится, то пусть с С не начинает, а начинает сразу с С++. Сишнику лучше в кресты не соваться, я уже такую толпу быдлокода видел, где вроде как кресты, а содержимое внутри все сишное! И строки в char*…

Это как посмотреть. Python назван в честь змеи, а она по-русски питон.

Но т.к. это не яп, а говно, правильней говорить «пхытон» или «пихтон».

Python назван в честь змеи

чЁ? долб…б? RTFM!

Название языка произошло вовсе не от вида пресмыкающихся. Автор назвал язык в честь популярного британского комедийного телешоу 1970-х «Летающий цирк Монти Пайтона». Впрочем, всё равно название языка чаще связывают именно со змеёй, нежели с передачей — пиктограммы файлов в KDE или в Microsoft Windows и даже эмблема на сайте python.org (до выхода версии 2.5) изображают змеиные головы. Важная цель разработчиков Python — создавать его забавным для использования. Это отражено в его названии, которое пришло из Монти Пайтона

Разработка языка Python была начата в конце 1980-х годов сотрудником голландского института CWI Гвидо ван Россумом. Для распределённой ОС Amoeba требовался расширяемый скриптовый язык, и Гвидо начал писать Python на досуге, позаимствовав некоторые наработки для языка ABC (Гвидо участвовал в разработке этого языка, ориентированного на обучение программированию). В феврале 1991 года Гвидо опубликовал исходный текст в группе новостей alt.sources. С самого начала Python проектировался как объектно-ориентированный язык.

Наличие дружелюбного, отзывчивого сообщества пользователей считается наряду с дизайнерской интуицией Гвидо одним из факторов успеха Python. Развитие языка происходит согласно чётко регламентированному процессу создания, обсуждения, отбора и реализации документов PEP (англ. Python Enhancement Proposal) — предложений по развитию Python.

Сишнику лучше в кресты не соваться, я уже такую толпу быдлокода видел, где вроде как кресты, а содержимое внутри все сишное! И строки в char*…

Эдичка, да что ты там мог видеть вообще — у тебя мозг жиром заплыл и давит на глазной нерв.

Сишники/крестоносцы во главе Эдички-истерички в треде про Python — это же по мотивам классики, когда в тред на каком-нибудь ресурсе про линукс вваливаются виндузятники и начинают обсирать сабж, которому посвящен этот тред.

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

может кто знает про хорошую статью о регулярных выражениях (модуль re)? а то я не нашел...

https://en.wikipedia.org/wiki/Thompson's_construction#cite_note-1

https://github.com/python/cpython/blob/master/Lib/re.py

в чём собственно затруднения?

нет

зачем? что ты с ним делать собрался?

Возникает только один вопрос: чем тебе не угодил Nim?

нет ты

фу бяка

Тем, что никуда не взлетел и не светит? Посмотри на Rust, посмотри на Nim - видишь некоторую... разницу (я о реальном «промышленном» применении ЯП)?

Забавно это слышать от любителя perl.

1) что мешает использовать процессы это проблемы? Есть очень удобный multiprocessing. Есть всякая асихронщина. Тем более http://perldoc.perl.org/threads.html

2) pypy довольно популярен.

3) есть стандарный очень годный модуль logging, который используют все нормальные библиотеки и приложения

4) не пользовался. использую кучу приложение на питоне, с которыми проблем нет. начиная от всяких fabric и ansible, заканчивая meld и deluge

5) pypy написан на питоне.

Метод ветвей

Запаздывающие генераторы

Дерево

Поиск наименьшего набора ребер

функции, учитывающие близость

Поиск ближайшего соседа

детский сад

Три сообщения подряд про Эдичку.

Похоже горит как раз у тебя.

Процессы не мешало бы использовать только при наличии нормальной поддержки хранения структур данных пользователя в расшаренной памяти. Но в силу то ли «неуниверсальности» подхода, то ли ещё каких-то непонятных мне трудностей - по-человечески использовать shared memory именно как просто место для хранения любых переменных (это же тупо мапинг страниц памяти, самых обычных страниц, самый обычный мапинг!) - невозможно. Каждый разработчик интерпретатора считает, что его данные в расшаренной памяти могут катастрофически разрушиться злонамеренными «третьими лицами», поэтому лучше копировать от расшренной памяти в обычную сериализованные данные - и делать десериализацию. Почему вообще безопасность использования shmem должна касаться разработчиков интерпретаторов, и почему я не имею права выстрелить себе в ногу, если мне это действительно необходимо (или, внезапно, я просто слышал о правах доступа в shmem) - это мне тоже неизвестно.

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

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

Perl'овые потоки - такой же кривой механизм, как и потоки Python, просто суть кривости в другом. Ну да, интерпрератор сам себя копирует в каждый поток, чтобы там состояние интерпретатора было уникальным для потока, но при использовании пулов это грозит только нерациональным расходом памяти. Зато в Python есть прекрасная «блокировка интерпретатора» (https://ru.wikipedia.org/wiki/Global_Interpreter_Lock), которая делает параллельность непараллельной, причём не только для потоков, которым нужны одни и те же данные, но и для вообще всех потоков (из соображений «как бы чего не вышло»).

Не совсем, расширения на си могут вполне себе использовать потоки без gil. Кроме того, gil есть не во всех реализациях python. Во всяких jython его нет, например. И gil уже выпиливали и питон стал от этого медленней. Да gil есть и, например, в ruby.

Ну так расширения на Си могут, разумеется, и для perl наплодить нативные потоки. Только что в этом прекрасного - непонятно. Не легче ли тогда сразу на Си писать?

A byte of Python

Алгоритмы везде одинаковые.

Не легче ли тогда сразу на Си писать?

Значит предлагаете скрипты на Си писать вместо питона. Спасибо, поржал.

Удивлен, что никто до сих пор не упомнянул https://learnpythonthehardway.org/

От чего же? От того, что этот придурок противопоставляет скриптовый динамический язык компилируемому статическому? Да я смеюсь над ним и презираю этого невежду.

Я вот держу связку из питона и Си для своего будущего проекта — простота и производительность.

а где ты тут взрослых видишь?

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

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

Скрипты в многопоточном режиме? Ну-ну.

Особенно в 2005-м году на одноядерной машине - все алгоритмы одинаковые.

А питон по умолчанию многопоточен? Нет, но несмотря на GIL, на нем можно писать «многопоточные скрипты».

то пиши на том, на чем предполагает умная книжка с основами программирования и сайтик,

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

Вопрос не только в этих книжечках по алгоритмам. Кнут и его товарищи всё это сделали и расписали.

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

комбo С(sh)/UnixOs в временна усато-волосатые тоже можно было и в С-коде(с тех пор как в юнихе появились потоки)поточить - но всегда до и часто после проще было С-кодом реализовавать функции-процессы а их увязку заклеивать «высокоуровневой» shелкотой.

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

Не легче ли тогда сразу на Си писать?

У меня и скрипты на сях есть... Если на баше что-то сложно сделать, то на сях — как 2 пальца об асфальт!

Давайте расскажем всем о том, что в Python не реализованы быстрые алгоритмы сортировки! Давайте сорвём покровы в самом деле!

А вы их, простите, на чём реализовать собрались? На Питоне??? Да ещё однопоточно? Просто Вау! Ну удачи вам, крепкого здоровья и всяческих успехов.

Конечно на питоне, это же скрипты, как раз изучаю алгоритмы сортировки на нем и уже реализую их в своих поделиях. Только как это вяжется к поточности, лол. Я видел реализации сортировок на различных языках, в том числе на Perl, PHP и Си. Не думаю, что все они многопоточные :)

Просто Вау! Ну удачи вам, крепкого здоровья и всяческих успехов.

Спасибо.

Это не скрипты.

Дайте пожалуйста список тем которые надо изучить

Русские физики выбирают Slackware

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

Давайте расскажем всем о том, что в Python не реализованы быстрые алгоритмы сортировки! Давайте сорвём покровы в самом деле!

Угу, давай, расскажи всем.

И про многопоточность с модулями threading и multiprocessing

https://docs.python.org/3.6/library/multiprocessing.html

Можно и на тракторе Формулу-1 гонять. Но шансы не очень хорошие - даже если все сойдут с дистанции, всё равно ждать тебя никто не будет.

На тракторе у себя в карьере можно и не спешить.