После 18 месяцев разработки представлен (https://www.python.org/downloads/release/python-350/) значительный релиз языка программирования Python 3.5.Среди добавленных в Python 3.5 новшеств (https://docs.python.org/3.5/whatsnew/3.5.html):
- Добавлен (https://www.python.org/dev/peps/pep-0441/) новый модуль zipapp (https://docs.python.org/3.5/library/zipapp.html#module-zipapp), предоставляющий API и утилиту командной строки для создания упакованных в один файл приложений, которые можно запустить командой "python приложение.pyz". Для создания исполняемого архива достаточно поместить все файлы программы в отдельную директорию, создать выполняемый по умолчанию скрипт __main__.py и выполнить команду "python -m zipapp имя_директории";
- Расширено (https://www.python.org/dev/peps/pep-0448/) применение операторов распаковки "*" и "**", которые теперь можно использовать для произвольного числа распаковок при вызове функции или при манипуляциях с множествами, кортежами, списками и словарями.
(ранее допускалась только одна распаковка). Например, для функции "def fn(a, b, c, d)" можно выполнить fn(**{'a': 1, 'c': 3}, **{'b': 2, 'd': 4})"), а для словаря - "{*range(4), 4, *(5, 6, 7)}";- Поддержка (https://www.python.org/dev/peps/pep-0461/) использования оператора форматирования вывода "%" для объектов bytes (https://docs.python.org/3.5/library/functions.html#bytes) и bytearray (https://docs.python.org/3.5/library/functions.html#bytearray) по аналогии с тем, как выполняется форматирование строк. Например, выполнение "b'x=%i y=%f' % (1, 2.5)" приведёт к выводу "b'x=1 y=2.500000'";
- В стандартной библиотеке представлена (http://www.python.org/dev/peps/pep-0471) новая функция os.scandir() (https://docs.python.org/3.5/library/os.html#os.scandir) для очень быстрого обхода содержимого директорий. Выполнение os.walk() на базе новой функции работает в 3-5 раз быстрее на POSIX-системах и в 7-20 раз быстрее в Windows, за счёт сокращения числа вызовов os.stat();
- Возможность (http://www.python.org/dev/peps/pep-0475) автоматического повторного выполнения прерванных системных вызовов без установки отдельных обработчиков EINTR или InterruptedError;
- Представлен (http://www.python.org/dev/peps/pep-0484) модуль typing (https://docs.python.org/3.5/library/typing.html#module-typing), который позиционируется в качестве нового стандарта для задания аннотаций типов. При подключении модуля можно предоставить данные о типах аргументов и возвращаемого значения функции, например "def greeting(name: str) -> str";
- Реализована (http://www.python.org/dev/peps/pep-0485) функция
math.isclose() (https://docs.python.org/3.5/library/math.html#math.isclose) для приблизительного сравнения значений с заданным уровнем точности. Например, "math.isclose(5.0, 4.99998, abs_tol=0.00003)" вернёт True;
- В ланчере Python для платформы Windows добавлена (http://www.python.org/dev/peps/pep-0486) поддержка работы в виртуальных окружениях;
- Искоренена (http://www.python.org/dev/peps/pep-0488) концепция PYO-файлов, использовавшихся для хранения оптимизированного байткода. Для размещения как оптимизированного, так и неоптимизированного байткода теперь применяются единые файлы ".pyc";- Новый механизм (http://www.python.org/dev/peps/pep-0489) для загрузки модулей-расширений, обеспечивающий возможность инициализации в несколько стадий;
- Значительно улучшены средства асинхронного программирования, благодаря поддержке (https://www.python.org/dev/peps/pep-0492/) нового async- и await-синтаксиса для определения сопрограмм, асинхронно выполняемых объектов и итераций. Например, для создания и вызова сопрограммы можно указать "async def http_get(domain)" и "data = await db.fetch('SELECT ...')";
- Возможность (http://www.python.org/dev/peps/pep-0479) изменения обработки исключений StopIteration (https://docs.python.org/3.5/library/exceptions.html#StopIter...) внутри генераторов;
- Класс collections.OrderedDict (https://docs.python.org/3.5/library/collections.html#collect...) переписан на языке Си, что позволило ускорить его выполнение от 4 до 100 раз. На Си также переписана функция functools.lru_cache() (https://docs.python.org/3.5/library/functools.html#functools...);
- Добавлен новый вызов subprocess.run() (https://docs.python.org/3.5/library/subprocess.html#subproce...) для быстрого запуска подпроцессов;
- В стандартной библиотеке по умолчанию отключена поддержка SSLv3;
- Добавлен (https://www.python.org/dev/peps/pep-0465/) новый оператор "@" для умножения матриц. Например, вместо "S = dot((dot(H, beta) - r).T, dot(inv(dot(dot(H, V), H.T)), dot(H, beta) - r))" теперь можно использовать более понятное представление "S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)".
URL: https://www.python.org/downloads/release/python-350/
Новость: http://www.opennet.me/opennews/art.shtml?num=42952
В Ubuntu и Debian "Python 3.5" появится в релизах Ubuntu 16.04 и Debian 9.
upd:
Народ пишет, что в Proposed разрабатываемой Ubuntu 15.10 уже появился Python 3.5.
В раче уже прежднюю версию замаскировали
В чём проблема собрать из исходных кодов?
Ubuntu 12.04 LTS, Python3.5 поставил только что из .tar.gz, брат жив.
Приятно, что язык развивается. Как бы то не было появление py3k воспринимаю очень позитивно, хоть он и нарушает совместимость.
Обратная совместимость это такая штука, которую так или иначе иногда хочется нарушить любому проектировщику. Мало кто на это решается. А вот решиться, осуществить и остаться популярным могут вовсе единицы.
вот только другим хватает мужества и мозгов перестать поддерживать "устаревшие" версии
Это всего лишь означает, что данный язык является не только "попсово-молодёжным", но и используется и в очень серьёзных ситуациях. И как оказалось они способны поддерживать и старую ветку местами портируя улучшения, а также развивать новую. Это хорошо, что проектировщики-идеалисты неплохо уживаются с разработчиками-прагматиками. Всем бы так же...
Всё бы ничего, но из-за них новые приложения пишут под 2.х, а на вопрос "какой же в этом смысл?" отвечают "так работает же".
Вот и получается что одни другим помогают и стагнируют вместо того, чтобы принимать участие в разработке и использовании новой версии.
Так продолжают они писать на 2ом потому что 3яя ветка ничего принципиально нового не предлагает, только немного поправили кривость строк и это в основном всё.
Знатока за версту видно. Выполните в ветках python 2.7 и 3:
a = range(10**9)
2 вопроса:
1) 3 какая версия нужна?
2) в каком дистрибутиве найти свежий питон 3?
>> 2) в каком дистрибутиве найти свежий питон 3?- В любом живом.
тебе про xrange ещё ни разу не рассказывали?
Просто в 3-м range = xrange, вот и все, а xrange сработает нормально и там и там.
У людей уже есть код на 2.7 и от переписывания его на 3.5 они никакого профита не получат.
А новое пишут на 2.7 обычно когда модуль нужный только под него есть, например pyamf.
Ага, а то, что третий питон в 2 раза медленнее второго ничего?
Что еще за чушь?
Это на каких задачах?
Берите любую: http://acm.timus.ru/problemset.aspx?space=1&page=all&skipac=...
Над решением некоторых работало больше тысячи человек. Во многих реализациях присутствуют несвойственные языку ускоряющие костыли. И все равно везде реализация на 3-ем проигрывает второму, и при этом четко можно утверждать что это максимум, на что способен язык.
Данный сайт с задачками не является показательным.
Здесь есть более интересные результаты:
http://www.gossamer-threads.com/lists/python/dev/1013761
> Ага, а то, что третий питон в 2 раза медленнее второго ничего?Ничего. Питон не для обгонов, он для того, чтобы ничего не произошло ака выстрела себе в ногу. Он за всем проследит, "язык"-робот...
Да, питон не для обгонов. Он наоборот супертормозной супермостр.
Это не он наоборот, это такие как ты наоборот. Те, кто в упор не понимает, что late binding и garbage collection не могут быть аппаратными и что overheadы порождаются обслуживающим всю эту кухню увесистым потоком машинных инструкций, а вовсе не злобным-вам-назло ван Россумом.
Да, пользователям внутренняя кухня определенно важнее испытываемых ежедневно тормозов, выкачивания обновлений распухших пакетов и постоянных падений. И ничего что всё это происходит почти во всех linux дистрибутивах, нам ведь главное всякие "увесистые потоки машинных инструкций" и т.п. лабуда. А linux круче винды априори, может тормозить сколько угодно. То, что люди не переходят на него с винды - дак они просто тупые дураки, не могут понять весь шик и шарм "увесистого потока машинных инструкций", зажирающего все ресурсы системы.
Именно! Пользователям внутренняя кухня гораздо дороже испытываемых ежедневно мифических тормозов там, где важно обеспечение сервиса высокой доступности. Где любой простой в случае неожиданного спотыка вылетает в копеечку. Где стоимость оборудования не существенна по сравнению с возможным ущербом. Почему мифических? См. предыдущее предложение.
Падения и тормоза менеджера приложений убунты конечно же мифические.
> Падения и тормоза менеджера приложений убунты конечно же мифические.И что? Вангую, что если бы писалось на плюсах или Си, то всей разницы - половина (C++) или четверть фунционала и жесточайшая течь с сегфольтами. Это только в сказках и мечтах школьников "чудо инструмент" дает автоматом +10500 на скиллы.
> Да, питон не для обгонов. Он наоборот супертормозной супермостр.Так толсто, что просто толсто. Сравните с ruby например или java (хотя с последней не все так плохо, ибо как подтверждает практика, как правило проблема java - программисты, пишущие на ней)
> Всё бы ничего, но из-за них новые приложения пишут под 2.х, а
> на вопрос "какой же в этом смысл?" отвечают "так работает же".Угу. А еще я могу до сих пор писать на C89, если мне так хочется. И даже программы на нем собираются. Прикинь какой пи..ц?!
>писать на C89
>Прикинь какой пи..ц?!сочувствую.
Себе посочувствуй.
> Себе посочувствуй.Юзер, я не пишу в 21 веке скрипты на Си :-D
А Вы на питоне только скрипты пишете? Сочувствую.
акцент на слове питон, только, или сочувствую? :-D
> акцент на слове питон, только, или сочувствую? :-DАкцент на слове "скрипты". Пробовали писать большие и сложные приложения, а не только два числа складывать?
>> акцент на слове питон, только, или сочувствую? :-D
> Акцент на слове "скрипты". Пробовали писать большие и сложные приложения, а не
> только два числа складывать?Пробую потихоньку. Только на perl а не на python. На си - застрелился б.
Ага, пускай застрелятся пользователи этого приложения.
> Ага, пускай застрелятся пользователи этого приложения.С чего бы им застрелиться? Они не тулкитофобы, не фанатики статики или динамики, им главное результат.
Вы никогда ничего не слышали об областях применения?
> Вы никогда ничего не слышали об областях применения?И? Развейте свою мысль, пожалуйста.
Легко: на Python активно пишутся достаточно сложные сетевые сервисы, веб-прикладухи и т.п. А на Сях почему-то никто не торопится этого делать. Как Вы думаете, с чего бы это?
> Легко: на Python активно пишутся достаточно сложные сетевые сервисы, веб-прикладухи и т.п.
> А на Сях почему-то никто не торопится этого делать. Как Вы
> думаете, с чего бы это?Как это соотносится с моим сообщением #111, где я намекаю на тоже самое?
Ой, точно. Это я в режиме многозадачности совсем зарапортовался ) Обидно просто, когда незаслуженно хаят неплохой проект.
> Легко: на Python активно пишутся достаточно сложные сетевые сервисы, веб-прикладухи и т.п.
> А на Сях почему-то никто не торопится этого делать. Как Вы
> думаете, с чего бы это?С того, что порог вхождения в си достаточно высокий (ручная сборка мусора, операции с указателями), в отличии от пайтона и груби. Эрланг вон вообще сетецентричный, но готовых распространенных приложений на нем можно сосчитать на пальцах одной руки. Но эт не значит что язык плох, его просто сложно изучать. Впрочем это не умаляет достоинств пайтона.
> С того, что порог вхождения в си достаточно высокий (ручная сборка мусора,
> операции с указателями), в отличии от пайтона и груби.Нет. Просто потому что в XXI веке ручная сборка мусора и прочий онанизм - нужны для
ничтожной доли специальных приложений.
Скриптовый язык - высокоуровневый язык сценариев, или проще говоря для последовательностей операций, которые пользователь может выполнять на компьютере. Писать на нем приложение, особенно gui - богохульство и ересь.
Что за времена пошли, извращают всё, что только можно...
> Скриптовый язык - высокоуровневый язык сценариев, или проще говоря для последовательностей
> операций, которые пользователь может выполнять на компьютере. Писать на нем приложение,
> особенно gui - богохульство и ересь.
> Что за времена пошли, извращают всё, что только можно...ой! Ликбез?! Люблю!
Сцена́рный язы́к (язык сценариев, жарг. скрипто́вый язык, от англ. scripting language) — высокоуровневый язык сценариев (англ. script) — кратких описаний действий, выполняемых системой. Разница между программами и сценариями довольно размыта. Сценарий — это программа, имеющая дело с готовыми программными компонентами[1].
https://ru.wikipedia.org/wiki/%D0%A1%D1%...
Таки эталонным скриптовым языком является shell, все остальное это что-то между скриптами и полноценными программами(хотя то и другое программы).
Странно было-бы утверждать, что python - недоязык, удел которого подпрограммы запускать.
А насчет gui вы и тут неправы, pygobject Вам в помощь для устранения пробелов в знаниях.
> Скриптовый язык - высокоуровневый язык сценариев, или проще говоря для последовательностей
> операций, которые пользователь может выполнять на компьютере. Писать на нем приложение,
> особенно gui - богохульство и ересь.Ну да, а QML - это такие видоизмененные плюсы :)
На самом деле, чем именно дергать _высокоуровневые_ либы гуя - в принципе без разницы.
Когда средний такой "дерг" обходится (в лучшем случае) в пару-тройку тысяч тактов, плюс минус сотня погоды не сделает. Главное, не рукожопить.
> Обратная совместимость это такая штукаОбратная совместимость это такая штука, которая тебя лично не коснётся во веки веков :) :) :)
Путь Python понемногу начинает напоминать путь C++ от классики С++98 до С++17 ;)
Сделают опциональными скобки, откажутся от позиционного выражения отношения операторов и, наконец, получат Ruby :)
> Сделают опциональными скобки, откажутся от позиционного выражения отношения операторов
> и, наконец, получат Ruby :)Дадут максимум синтаксической свободы и доведут до полной нечитаемости результата.
Это сейчас общий тренд в новых редакциях языков.
> Дадут максимум синтаксической свободы и доведут до полной нечитаемости результата.Зато отформатировано будет безупречно. Полной свободы так не дадут. А вот кого надо заставлять форматировать код при помощи волшебных пи...лей - несложно догадаться.
> А вот кого надо заставлять форматировать код при помощи волшебных пи...лей - несложно догадаться.Кому ехать, а кому шашечки (ты буду тыкать пальцем в вышеотписавшегося анонима) не сложно догадаться.
>> А вот кого надо заставлять форматировать код при помощи волшебных пи...лей - несложно догадаться.* Кому ехать, а кому шашечки (не буду тыкать пальцем в вышеотписавшегося анонима) не сложно догадаться. Такие заданные стандарты, камрад.
>Дадут максимум синтаксической свободы и доведут до полной нечитаемости результата.Это сейчас общий тренд в новых редакциях языков.
Это вы просто про с и с++ не слышали
> Путь Python понемногу начинает напоминать путь C++ от классики С++98 до С++17 ;)Только с поправкой на хипстоту: старую программу на сях или плюсах можно скомпилить, а старый скрипт на каком-нибудь питон 2.4 - это опаньки...
>Только с поправкой на хипстоту: старую программу на сях или плюсах можно скомпилить, а старый скрипт на каком-нибудь питон 2.4 - это опаньки...Школота детект! Хорош уже пургу нести, большинство программ написанных в середине 90х ну никак не смогут скомпилироваться в современных реалиях. Нет ни тех ОС, ни тех библиотек. И чем больше программа тем больше вероятность что она не заведется. А если более ранний код разыскать то банальный helloworld не скомпилируется, прикинь, подключать stdio.h было не обязательным, а ведь еще и были его конкуренты conio.h например.
> А если более ранний код разыскать то банальный helloworld не скомпилируется, прикинь, подключать stdio.h было не обязательным, а ведь еще и были его конкуренты conio.h например.Бгг, а stdio.h и сейчас подключать необязательно, прикинь?
$ echo 'int main() { puts("Hello!");}' | gcc -xc -
$ ./a.out
Hello!$
>>puts("Hello!");Не-не-не, ты с printf давай уж.
>>>puts("Hello!");
> Не-не-не, ты с printf давай уж.Тебя ткнули носом хватить юлить студентик, признай уже свою неправоту.
Старую программу на сях в большинстве случаев удастся собрать без проблем (ну максимум добавить ключики в CFLAGS). С плюсами тяжелее - если программа заточена под какой-то один компилятор тех времен, то пиши пропало, если кросс-платформенная - то есть шанс отделаться несколькими проходами sed по исходникам и -fpermissive
> Старую программу на сях в большинстве случаев удастся собрать без проблем (ну
> максимум добавить ключики в CFLAGS).У меня есть бандл из примерно сотни исходников под Borland Turbo C вот как-то ни одна gcc не собирается, банально библиотек нет.
>> Старую программу на сях в большинстве случаев удастся собрать без проблем (ну
>> максимум добавить ключики в CFLAGS).
> У меня есть бандл из примерно сотни исходников под Borland Turbo C
> вот как-то ни одна gcc не собирается, банально библиотек нет.а это проблема языка, что библиотек нет? Портируйте и будет счастье. Хотя счастьем такой процесс трудно назвать.
> а это проблема языка, что библиотек нет?А чья это проблема?
Так ты писал под конкретный компилятор, о том, что такое портабельность, небось даже не подозревал, а теперь делаешь вывод космического масштаба, что "большинство программ написанных в середине 90х ну никак не смогут скомпилироваться в современных реалиях".
> Так ты писал под конкретный компилятор, о том, что такое портабельность, небось
> даже не подозревал, а теперь делаешь вывод космического масштаба, что "большинство
> программ написанных в середине 90х ну никак не смогут скомпилироваться в
> современных реалиях".Секунду, какая нахеер портабельность? Между PC DOS и MS DOS всё прекрасно работало, между 286 и 386 тоже. Машины времени у меня не было, как и ни у кого другого, и как всё будет через 20-25 лет никто не знал. Нотаций помимо K&R было масса. На стандарт C89 всем было ложить с высокой башни. Интернет только зародился и был недоступен для 99.9999% населения.
Что достал на дискете на том и пиши, может года через два что-то другое найдешь.
А сейчас появились молодые археологи зачатые уже в эпоху интернета и всеобщей компьютеризации, и несут несусветную чушь о портабельности.
Понятно. О портабельности ты не имел представления потому, что не догадывался о существовании чего-либо кроме MS DOS/PC DOC и 286/386... Ты хоть про компиляторы какие-нибудь, кроме Turbo C, тогда слышал? Там Watcom C или тот же Microsoft C?Нет, пойми меня правильно, я не обвиняю тебя в том, что ты чего-то не знал. У меня тоже где-то валяются исходники под Turbo C с conio.h и ассемблерными вставками. Но я же не делаю из этого обобщений о "большинстве программ, написанных в середине 90-х"!
>Понятно. О портабельности ты не имел представления потому, что не догадывался о существовании чего-либо кроме MS DOS/PC DOC и 286/386... Ты хоть про компиляторы какие-нибудь, кроме Turbo C, тогда слышал? Там Watcom C или тот же Microsoft C?Ты дурак или как? Компьютер в те времена стоил ровно столько же сколько двушка в центре города-миллионика, мышка или флопи-привод - среднюю зарплату. Компьютеров в современном понимание у населения не было от слова совсем, были "приставки к телевизору" на базе Z80 спаянные по схемам из журнала "Радио". Бейсик, Паскаль, Ассемблер и машинные коды - вот и всё, программы можно было купить только на радиорынках, распространялись они магнитофонных кассетах. Компьютеры на базе x86 были только на крупных предприятиях, вся информация об программирование только в заводской библиотеке, хочешь что-то узнать необходимо найти каталог новых книг, заказать - через месяца два привезут. Все программы были написаны исключительно под одну операционную систему под конкретную аппаратную платформу, под конкретную систему разработки. Borland был всех выше на две головы, хотя бы потому что это была IDE. Все писали под него, под DOS c ассемблерными вставками, которые нифига не похожи на гнутый синтаксис, вызывающими прерывания int 10h и int 21h, в кодировке cp866, под 3 или 13 видеорежим и EGA мониторы с 16 цветами. А сейчас появляются "умные школьники", которые освоили поиск по гуглу, и делают неверные ассоциации со стандартом C89, и считающие, что что-то из того кода сейчас скомпилируется.
Ну, понятно. Я в 90-е работал на SunOS/Solaris на Спарках, а ещё раньше - на PDP-11/СМ ЭВМ. А первый Линукс (слакварь, как сейчас помню) мы на писюке (ещё с дискет!) устанавливали в 1996 году. О чём мне с тобой разговаривать?
"классики" c++98? до c++98 c++ тоже существовал -- первое издание страуструпа именно этот диалект и описывает. вот как раз это классика и была.
Вроде и много чего добавили, а интересного по сути ничего. % для bytes - это, конечно, хорошо для портирования с 2.x, но новой функциональностью это никак нельзя назвать.
ИМХО самое ожидаемое сейчас - добавление JIT и избавление от GIL, остальное всё мелочи.
Самое ожидаемое было это опциональная строгая типизация со стороны самого языка которая помогла бы много багов отлавливать сразу и дала бы какие-то возможности к оптимизации сразу на этапе компиляции. Но нет, в очередной раз сделали какую-то уету.А про JIT можно вообще забыть, никогда его в стандартном питоне не будет ибо достаточно посмотреть на уродцев вроде PyPy, Jython и т.п. чтобы понять какое это монтсро будет. И с этим ничего поделать нельзя т.к. когда дизайнили ЯП позасовывали динамичность во все щели тем самым отрезав все пути человеческой оптимизации. И со временем дело становится только хуже - вместо того чтобы как-то со временем отрезать ненужную динамичность Гвидо клепает ещё больше динамичного гогна и делает его core частью языка.
У автора luajit же как-то получилось, получится и в https://github.com/dropbox/pyston
Динамичность и безтиповость - это вопрос философии, за которым к языку тянутся. Иначе фанаты разорвут. В Руби так же. Практичность выполнения идет боком (т.е. на другие VM и фреймворки).
> Самое ожидаемое было это опциональная строгая типизация со стороны самого языкаКогда такое ожидалось? Обещали аннотацию типов, но это не строгая типизация, а документирование типов.
> достаточно посмотреть на уродцев вроде PyPy, Jython и т.п. чтобы понять какое это монтсро будет
Да что на них смотреть? Посмотри сразу на жубу.
Вы просто повзрослели
Если я не ошибаюсь, в питоне типизация уже строгая, поскольку нет неявного приведения типов, строку с числом банально не сложишь. А у тебя мечта о статической, судя по всему.
Ох уж этот Гвидо! Опять его понятие о том, каким должен быть ЯП, не совпадает с твоим!
> Самое ожидаемое было это опциональная строгая типизация со стороны самого языкаПрикинь, Python c самого первого релиза имеет строгую динамическую типизацию!
Правда есть школота, которая путает строгую и статическую типизацию, но это другое.
> которая помогла бы много багов отлавливать сразу и дала бы какие-то возможности
> к оптимизации сразу на этапе компиляции. Но нет, в очередной раз
> сделали какую-то уету.Какой нахеер компиляции? CPython - интерпретатор.
> А про JIT можно вообще забыть, никогда его в стандартном питоне не
> будет ибо достаточно посмотреть на уродцев вроде PyPy, Jython и т.п.
> чтобы понять какое это монтсро будет.Эй что с PyPy-то не так? Замечательная вещь.
> И с этим ничего поделать
> нельзя т.к. когда дизайнили ЯП позасовывали динамичность во все щели тем
> самым отрезав все пути человеческой оптимизации. И со временем дело становится
> только хуже - вместо того чтобы как-то со временем отрезать ненужную
> динамичность Гвидо клепает ещё больше динамичного гогна и делает его core
> частью языка.Понятно всё с тобой, перепиши своё ДНК на ассемблере.
>самое ожидаемое сейчас - добавление JIT и избавление от GILИ сколько лет по сей час ждёшь?
> поддержка оператора форматирования вывода "%" для объектов bytes и bytearrayНу вот, можно наконец и переходить. Нет бы сразу по нормальному сделать, надо было выкобениваться, типа массивы байт это ни разу ни строки и для форматирования извольте дрочить вприсядку. Разум победил, алилуйя.
> Нет бы сразу по нормальному сделать,С байтовыми строками с самого начала было сделано нормально, это сейчас, видимо, прогнулся под быдлоту.
> Добавлен новый оператор "@" для умножения матриц.Гвидо окончательно утратил контроль над проектом и школие
потеряло берега. До кучи, еще и метод назвали идиотски - __matmul__.Moar закорючек, лавры Perl не дают покоя.
Он сам же всё это дерьмо аппрувит. Он превратился в овощ лет эдак 5 назад, или мб чуть более.
У него как раз были здравые мысли (см. rejected alternatives).
Сам ты овощ.
>> Добавлен новый оператор "@" для умножения матриц.
> Гвидо окончательно утратил контроль над проектом и школие
> потеряло берега. До кучи, еще и метод назвали идиотски - __matmul__.Матричное умножение, (matrix multiplication) что не так?
То, что это никакое не матричное умножение, в стандартной библиотеке даже нет реализации (принцип batteries included Гвидо тоже прос**л?). Синтаксически - это просто "еще одно операция вроде умножения", не отличается от * __ничем__.Хоть __ncmul__ назвали бы, вроде как некоммутативное умножение.
> в стандартной библиотеке даже нет реализации (принцип batteries included Гвидо тоже прос**л?)Схера ли ты несешь, что нет?! PEP 0465 видел? Created: 20-Feb-2014 Status:Final
@ Same as * __matmul__ , __rmatmul__
>> в стандартной библиотеке даже нет реализации (принцип batteries included Гвидо тоже прос**л?)
> Схера ли ты несешь, что нет?! PEP 0465 видел? Created: 20-Feb-2014 Status:Final
> @ Same as * __matmul__ , __rmatmul__Чукча, покажи мне реализацию этих методов в стандартной библиотеке.
Ты все слова понял?
> Ты все слова понял?Я-то все. Type: Standards Track. Для уроженцев Новой Гвинеи перевожу: Тип PEPа: новый стандарт API. Стандарт - тебе известно это слово, чудо заморское? Implementation details. New functions operator.matmul and operator.__matmul__ are added to the standard library, with the usual semantics. Готовый стандарт для numpy ( numpy.matrix ) и др. Какое из слов не понятно сейчас, говори?
> Готовый стандарт для numpy ( numpy.matrix ) и др. Какое из слов не понятно
> сейчас, говори?Непонятно где ты видишь тут реализацию этих "методов в стандартной библиотеке".
Функции в operator - не реализации, это лишь интерфейс к.
>>> import operator
>>> operator.mul(1, 2)2
>>> operator.matmul(1, 2)Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for @: 'int' and 'int'Доступно, мартышка?
Непонятно, где ты видишь, что я вижу тут реализацию этих "методов в стандартной библиотеке", папуасина?
Вот я мартышке и говорю, что их нету: #81Мартышка снова ничего не поняла? :)
Папуасик, это ты снова ничего не понял. В ПЕПах по стандартизации, как бы это попроще, немножечко не предполагается имплементации чего бы то ни было. Я конечно выразился совсем не удачно... нервы ни к черту (не сочти на попытку извинения - перед свиньями бисер метать не в моих правилах).
> В ПЕПах по стандартизации, как бы это попроще, немножечко не предполагается
> имплементации чего бы то ни было.Жаль, разочарую тапков: не только "предполагается", но всегда
есть, порой и не одна. Обычно патч вешают еще в процессе обсуждения.> Я конечно выразился совсем не удачно... нервы ни к черту
Не вопрос, весели дальше. Детишки переходят с PHP на Python, я уже
привык. Только вот "птичку жалко" :(
> в стандартной библиотеке даже нет реализацииИнтерфейс в STD реализован. Либам сто лет в обед. Телепатов нет.
> принцип batteries included Гвидо тоже прос**л?И да, сею батарейку легко заинклюдить в специализированных библиотеках. Она есть там, ежли что.
>> принцип batteries included Гвидо тоже прос**л?
> И да, сею батарейку легко заинклюдить в специализированных библиотеках.Откуда вы тут беретесь такие умные.
> Она есть там, ежли что.
В стандартной библиотеке нет, понял, школьник?
>>> import operator
>>> operator.mul(1, 2)2
>>> operator.matmul(1, 2)Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for @: 'int' and 'int'Доступно?
> В стандартной библиотеке нет, понял, школьник?Кто тебе рассказал, что в стандартной должно быть ВСЁ? Для ВСЕГО предусмотрены расширения.
python-numpy/vivid 1:1.8.2-1ubuntu1 amd64
быстрые методы работы с числовыми массивами – модуль для языка Pythonpython-scipy/vivid 0.14.1-1ubuntu1 amd64
scientific tools for PythonДалее apt install python-numpy python-scipy, import numpy, import scipy и поехали.
>> В стандартной библиотеке нет, понял, школьник?
> Кто тебе рассказал, что в стандартной должно быть ВСЁ?Бытовавшая ранее философия "batteries included". В частности, если python предоставляет
какой-то интерфейс - в стандартной библиотеке это как-то используется.Для посторонних марсиан - изменения делаются впервые. (Отмечу также,
что хотя конкурентов у numpy нет - его интеграция в stdlib не планируется.)
Ах да, идитыв*опу. Извини, забыл сразу послать. Дел много.
> То, что это никакое не матричное умножение, в стандартной библиотеке даже нет
> реализации (принцип batteries included Гвидо тоже прос**л?). Синтаксически - это
> просто "еще одно операция вроде умножения", не отличается от * __ничем__.Как нет, прямым текстом написано что есть.
> Хоть __ncmul__ назвали бы, вроде как некоммутативное умножение.
Ты такой умный.
Там действительно нет, только устанавливающий единообразие в сторонних научных пакетах интерфейс. Я сам с разбегу неразобравши заявил, чем дал этому чму возможность потанцевать на костях своей невнимательности.
>> То, что это никакое не матричное умножение, в стандартной библиотеке даже нет
>> реализации (принцип batteries included Гвидо тоже прос**л?). Синтаксически - это
>> просто "еще одно операция вроде умножения", не отличается от * __ничем__.
> Как нет, прямым текстом написано что есть.Где, пальцем покажи. Нет ни одного класса в стандартной библиотеке, где
метод __matmul__ реализован.>> Хоть __ncmul__ назвали бы, вроде как некоммутативное умножение.
> Ты такой умный.У тебя закончились аргументы?
>>> То, что это никакое не матричное умножение, в стандартной библиотеке даже нет
>>> реализации (принцип batteries included Гвидо тоже прос**л?). Синтаксически - это
>>> просто "еще одно операция вроде умножения", не отличается от * __ничем__.
>> Как нет, прямым текстом написано что есть.
> Где, пальцем покажи. Нет ни одного класса в стандартной библиотеке, гдеPython 3.5 скачай для начала.
> метод __matmul__ реализован.
>>> Хоть __ncmul__ назвали бы, вроде как некоммутативное умножение.
>> Ты такой умный.
> У тебя закончились аргументы?Должны быть аргументы на очевидное идиотское высказывание?
>>>> То, что это никакое не матричное умножение, в стандартной библиотеке даже нет
>>>> реализации (принцип batteries included Гвидо тоже прос**л?). Синтаксически - это
>>>> просто "еще одно операция вроде умножения", не отличается от * __ничем__.
>>> Как нет, прямым текстом написано что есть.
>> Где, пальцем покажи. Нет ни одного класса в стандартной библиотеке, где
> Python 3.5 скачай для начала.Скачал, собрал, особо самоуверенных ткнул в TypeError. Дурачки ничему
не учатся, ты это хочешь мне доказать?>>>> Хоть __ncmul__ назвали бы, вроде как некоммутативное умножение.
>>> Ты такой умный.
>> У тебя закончились аргументы?
> Должны быть аргументы на очевидное идиотское высказывание?Ну, у тебя же нет монополии на очевидность.
Осталось гевент в стандартную библиотеку добавить и другие языки будут не нужны.
> Осталось гевент в стандартную библиотеку добавить и другие языки будут не нужны.Уж сто лет в обед.
asyncio asynchttp и прочие async *
А что разве из std асинки всякие могут gevent.spawn()?
А зачем вам gevent если есть стандарт и стандартные библиотеки делающие ровно то же самое? Да лет 5 назад gevent был актуален, сейчас нет.
В пятницу на работе решил обновить убунту, и не обновил. Все компоненты скачались за час, а питон выкачивался весь рабочий день и выкачивается до сих пор. Ладно, думаю, говорят третий будет не такой убогий тормоз как второй, и полез с этой светлой мыслью на таймус ( http://acm.timus.ru/problemset.aspx?space=1&page=all&skipac=... ). Взял первые топовые по количеству решений 5 задач. И среднее по ним оказалось: Python 2 медленнее с++ не менее чем в 18 раз, а Python 3 не менее чем в 32 раза! При этом у с++ точность замера времени ограничена 3-мя знаками и у всех задач стоит 0.001, понятно что реальные значения могут быть значительно меньше. А в коде на питоне применяются убойные костыли, которые в реальности никто не применяет. Видимо питонисты считают тормознутость своего произведения его сильнейшей стороной, которую безусловно необходимо развивать.
>втирает про тормознутость числодробилок на питонеБратец троллик, рекомендую в следующий раз что-то поновее придумать. А так же подумать на досуге об адекватности инструментов поставленным задачам.
Писать на питоне всё, включая сложные gui приложения - результат деятельности питонистов-извращенцев. Более того, непрерывная пропаганда привела к том, что сейчас вообще никто не использует питон по назначению. Т.ч. тесты объективнее некуда.
> Писать на питоне всё, включая сложные gui приложения - результат деятельности питонистов-извращенцев.А ты из каких извращенцев? Почему сложное GUI не может быть написано на Python?
> Более того, непрерывная пропаганда привела к том, что сейчас вообще никто
> не использует питон по назначению. Т.ч. тесты объективнее некуда.То есть ты знаешь лучше чем вся индустрия информационных технологий, куда и что пихать?
Наверное ты гений, впиши сюда своё имя золотыми буквами
Бомбануло... это был всего лишь ответ товарищу Undefined. А почему сложное GUI не может быть написано на Python? Может конечно же. Просто это извращение. Как выше написано, нужно выбирать адекватные поставленным целям инструменты. А результат на питоне - это огромное потребление памяти, зависания, тормоза и падения, с коими сейчас сталкиваются миллионы пользователей убунты.
> То есть ты знаешь лучше чем вся индустрия информационных технологий, куда и что пихать?Нет, я никакой не гений, и не эксперт. Я знаю одно, убогим технологиям не место в продакшине.
> Бомбануло... это был всего лишь ответ товарищу Undefined. А почему сложное GUI
> не может быть написано на Python? Может конечно же. Просто это
> извращение. Как выше написано, нужно выбирать адекватные поставленным целям инструменты.
> А результат на питоне - это огромное потребление памяти, зависания, тормоза
> и падения, с коими сейчас сталкиваются миллионы пользователей убунты.
>> То есть ты знаешь лучше чем вся индустрия информационных технологий, куда и что пихать?
> Нет, я никакой не гений, и не эксперт. Я знаю одно, убогим
> технологиям не место в продакшине.О великий, на чем писать сложные GUI приложения?
Brainfuck. В крайнем случае машинные коды, но это уже не спортивно ))))
Как много патчей, ускоряющих хоть что-то из этой мегатонны рутины, происходящей в недрах CPython, закоммитили, сударь? Или ты только по части ныть?
Этому мостру нужны еще и патчи чтобы что-то выполнять с приемлемой скоростью?
Пакеты питона и так уже больше 300 мегабайт весят. Все дистрибутивы linux сплошной питон.
зачем нужны аннотации типов в языке с динамической типизацией? Какие-то полумеры непонятные.
Предполагается, что для инструментов разработки, для IDE.
> Предполагается, что для инструментов разработки, для IDE.я могу ошибаться, но для этого IDE используют live интерпретацию вводимого кода. Типы проверяются в живую.
>> Предполагается, что для инструментов разработки, для IDE.
> я могу ошибаться, но для этого IDE используют live интерпретацию вводимого кода.
> Типы проверяются в живую.IDE ничего не могут сделать с динамической компоновкой, которая может зависеть, хоть от конфигов, хоть от запросов к серверу, хоть от погоды на Марсе.
Подсказки типов в данном случае вводят некоторое ограничение и по сути ближе к синтаксическому сахару над `assert isinstance(x, InterfaceName)`.
Когда уже будет компилятор питона в натив? Cython не всё может cython'изировать.
"def greeting(name: str) -> str";отлично, прям как в RUST!
Python прибит гвоздями и его либа может быть установлена только в lib (не lib64) - никакой поддержки multilib там и не пахнет. 19 числа баге будет 10 лет https://bugs.python.org/issue1294959python-config - выдаёт не те параметры, которые указывались при конфигурировании, а тянет какую-то отсебятину.. https://bugs.python.org/issue22140
а вот тут - легитимизированный code injection: https://bugs.python.org/issue17124
> а вот тут - легитимизированный code injection: https://bugs.python.org/issue17124FWIW, I do not see the problem when using python3... Используй Python 3, Люк.
> 19 числа баге будет 10 лет https://bugs.python.org/issue1294959
Первое исправление python-2.3.4-lib64-regex.patch jafo, 2005-09-19 03:05 Что не так?
> python-config - выдаёт не те параметры, которые указывались при конфигурировании, а тянет какую-то отсебятину.. https://bugs.python.org/issue22140
Ничего такого криминального, трабла в процессе решения.
> Python прибит гвоздями и его либа может быть установлена только в lib (не lib64) - никакой поддержки multilib там и не пахнетЭэээ
$ rpm -ql python-libs.x86_64|head -n 7
/usr/include/python2.7
/usr/include/python2.7/pyconfig-64.h
/usr/lib/python2.7
/usr/lib/python2.7/site-packages
/usr/lib64/libpython2.7.so.1.0
/usr/lib64/python2.7
/usr/lib64/python2.7/BaseHTTPServer.py$ rpm -ql python-libs.i686|head -n 7
/usr/include/python2.7
/usr/include/python2.7/pyconfig-32.h
/usr/lib/libpython2.7.so.1.0
/usr/lib/python2.7
/usr/lib/python2.7/BaseHTTPServer.py
/usr/lib/python2.7/BaseHTTPServer.pyc
/usr/lib/python2.7/BaseHTTPServer.pyoИ так по-моему было всегда после появления multilib вобще.
я про это: /usr/lib/python2.7/site-packages
Так /usr/lib64/python2.7/site-packages/ тоже есть. Туда автоматически попадает 64-х битная версия модулей, использующие платформо-зависимый код (т.е. если есть .so'шка в комплекте). А в lib - 32-х битная версия и платформо-независимые модули.Некий бардак в этом, безусловно, есть: если в lib 32-х битный код, а в lib64 64-х битный, то почему платформо-независимый в lib? Но тут уж ммм не особо что придумать можно. Или дублировать его (нехорошо), или выносить из lib (java, к примеру, кладет переносимые jar'ники в /usr/share, тут можно также), или оставить, как есть..
>Используй Python 3, Люк.речь именно о 3, Бастила
>python-2.3.4-lib64-regex.patch jafo
протухший патч. "очень умно"
это всё только при поверхностном взгляде
> речь именно о 3, БастилаЛокатор нигде не обнаруживает, что речь там идет именно о 3. Это проделки ситтхов.
> протухший патч. "очень умно"
Я о "баге будет 10 лет", всемудрый падаван. Как видно в ней нет универсального решения. Патчи выпускаются, это видно.
> это всё только при поверхностном взгляде
Хз, хз. Type: behavior.
GIL, GIL победили уже?
Выбор GIL это своеобразный трейд-ин, в сегодняшней ситуации не стоит выставлять его как безусловное зло.
> GIL, GIL победили уже?Зачем?
>> GIL, GIL победили уже?
> Зачем?Lock free
более понятное представление "S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)"Во, уже почти хуже Перла.
from tkinter import *
from time import *
window = Tk()
window.title('Gonka')
time = 0
c = Canvas(window, height=100, width=700, bg='white')
c.pack()
circle = c.create_oval(10,10,100,50, fill="blue")
while True:
while True:
shama = input()
if shama == 't':
s = int(input('s='))
v = int(input('v='))
t = s/v
while True:
c.move(circle, v, 0)
while True:
sleep(1)
time = time + 1
if t == time:
break
print(t)
elif shama == 'v':
s = int(input('s='))
t = int(input('t='))
v = s/t
while True:
c.move(circle, v, 0)
if v*t == s:
break
print(v)
elif shama == 's':
t = int(input('t='))
v = int(input('v='))
s = t*v
while True:
c.move(circle, v, 0)
if v*t == s:
break
print(s)
else:
print('ERROR')
break
Помогитеб пожалуйста, не работает