В свете намеченного на 2020 год прекращения поддержки языка программирования Python 2, разработчики Debian, выразили беспокойство, что большое число проектов Debian написано на Python 2 и выступили (https://lists.debian.org/debian-devel-announce/2015/04/msg00...) с инициативой создания команды для портирования привязанного к Python 2 кода на Python 3. Кроме портированая программ, используемых в разработке Debian (buildd, инструменты для подготовки релизов, утилиты для оценки качества, скрипты для обслуживания репозиториев), предлагается провести ревизию пакетов, имеющих Python 2 в зависимостях, оценив для каких из них upstream-проекты уже реализовали поддержку Python 3, а какие пока нет.URL: https://lists.debian.org/debian-devel-announce/2015/04/msg00...
Новость: https://www.opennet.ru/opennews/art.shtml?num=42057
Если до 2020 не найдут багов в языке, то смысла портировать не будет.
А после 2020, все баги будут документированными фичами реализации.
Так что, зря мозг себе сношают.
>so we don't have to rely on an old, deprecated and brokenPython 2
Ещё бы он показал, где он broken. Вот про 3 несколько статей есть, где это показано, а про 2 ни одной. Тот же pyston использует 2 версию.
Интересно, что он скажет про old, deprecated and broken С, которому сколько там лет уже, 40?
Си может и старый, но как он может быть deprecated если замены ему нет?
Впрочем если ты про C89, то да -- старый и устаревший.
Освободитете место для Go.
остановите землю, я сойду
Смешной чувак, ты еще на пистоне системные компоненты поделай, зато быстро чо.
Плюсы из-за шизоподхода с компилятором тоже не у дела, нам надо как можно проще.
> Python 2 Ещё бы он показал, где он broken.Да, блин, просто элементарно прочитайте What-s-new для 3.0.
> Интересно, что он скажет про old, deprecated and broken С, которому сколько там лет уже, 40?А зачем что то вообще говорить про язык на котором сейчас пишет только кучка маргиналов?
Вот так вот просто взял и перечеркнул и GNU и linux.
> Вот так вот просто взял и перечеркнул и GNU и linux.Не знаю при чем здесь GNU и linux в целом. Но ядро разрабатывается кучкой маргиналов на маргинальском языке, да.
Система GNU/Linux практически вся на C написана. Только на самом верхнем уровне C++ более-менее часто попадается, да и то в основном благодаря Qt/KDE.
> Но ядро разрабатывается кучкой маргиналов на маргинальском языке, да.Хорошо человеку понимать хотя бы границы своей некомпетентности. Заодно сильно помогает от подобных "оценок".
Понимаю, что провоцирую вброс, но не могу не спросить - какой ЯП по вашему не является маргинальным?
Любой. Абсолютное большинство землян - не желает программировать.
выпилил весь второй, теперь пишет
/usr/bin/env: python: Нет такого файла или каталога
пробовал скобок к принту прибавить в autostart-xdg-openbox но не вышло с подключением модулей. решил пофик, не критично вроде.
поддерживаю, понаписали скриптов которые гвоздями прибиты ко всяким питоноперлам, так что потом абсолютно непонятно, что откуда запускается, а теперь мучаются. Очень показательно на фоне внедрения системд, тоже потом будут голову ломать ,что там за версия бинаря и какого лешего она в сегфол подает.
> выпилил весь второй, теперь пишет
> /usr/bin/env: python: Нет такого файла или каталога
> пробовал скобок к принту прибавить в autostart-xdg-openbox но не вышло с подключением
> модулей. решил пофик, не критично вроде.А симлинк /usr/bin/python сделать, указывающий на установленную "трёшку"?
> А симлинк /usr/bin/python сделать, указывающий на установленную "трёшку"?пробовал ln -s /usr/bin/python3 /usr/local/bin/python/python чето не сработало
а если так ln -s /usr/bin/python3 /usr/bin/python пишет
Xsession: X session started
File "/usr/lib/x86_64-linux-gnu/openbox-xdg-autostart", line 54
print "Invalid .desktop file: " + path
^
SyntaxError: Missing parentheses in call to 'print'а если в этот файл лезу и все по третьему делаю, то дальше он с модулями начинает не стыковаться, в итоге придется все принты наверное и не только епереписывать, вот и думаю, сделали бы это лучше профи и сунули в репы openbox поддерживающий python3
перестало бы вылазить это (хотя может кому то нра, тогда действительно ни к чему переписывать)
/usr/bin/env: python: Нет такого файла или каталога
То, что ты написал - это код для Python2.
> То, что ты написал - это код для Python2.а как надо, чтобы правильно и для Python3?
Ваше приложение не смотрел, поэтому только на эксепшен который Вы привели, такое решение для работы на обоих версиях питона:ко всем питон файлам в Вашей либе добавить импорт нового принта:
from __future__ print_functionи все принты заменить на функцию (что бы были со скобками):
print( "Invalid .desktop file: " + path)
> ко всем питон файлам в Вашей либе добавить импорт нового принта:
> from __future__ print_function
> и все принты заменить на функцию (что бы были со скобками):
> print( "Invalid .desktop file: " + path)пробовал но замороч, решил оставить что есть, работает и ладно.
Есть такая хорошая вещь, называется 2to3. Работает, конечно, далеко не всегда, но иногда помогает. Найти информацию по использованию в интернете вовсе не сложно.
> Есть такая хорошая вещь, называется 2to3. Работает, конечно, далеко не всегда, но
> иногда помогает. Найти информацию по использованию в интернете вовсе не сложно.http://www.linuxfromscratch.org/blfs/view/svn/x/openbox.html
но это трудновато для меня, не особо силен в этом всем. но спасибо за участие, думаю переведут когда то, хотя с появлением вайланда или мира полноценного перейду на окружение, которое их поддерживает, лично мне гном шэл нра, но он еще не готов быть полностью на wayland.
Лучше бы они создали команду для портирования с Python 2 и с Python 3 на C++.
Во во, на тот же C++ QML, и тормозить бы перестало и памяти не жрало бы так много. Переход на Python 3 уже давно стал хронической головной болью для всех и по факту так и не состоится. А они слепо продолжают пропихивать...
господа предлагатели, начните с себя, возьмите определенные пакеты и перепишите их C/C++
> Переход на Python 3 уже давно стал хронической головной болью для всех и по факту так и не состоитсякому нужно было -- давно портировали всё что им нужно было -- на Python-3 ..
остальные либо плачут (даже не пытаясь попробовать), либо вообще издалека на Python смотрят, не разбираясь в вопросе..
по факту -- переход на Python3 уже успешно состоялся. (а мёртвые проекты -- остались на Python2.. земля им пухом)
А питон4 похоронит питон3, а на си как компилилось в 89 так и щас компилится, ну на куя ваш питон нужен ваще.
он нужен в том числе потому, чтоб не писать на Си.
Домашние костыли на питоны быстрее ваяются. А потом сливаются в гит и перетекают дистры, и так школьные поделия заполоняют мир. Это та жа история, что и с php. Весь интернет завален, потому что изучается реально быстро и просто. А как это всё работает, и как правильно на этом писать - знают единицы.
Молчел, где вы питон4 увидели?
По факту - питон сильно тормозит и загромождает систему. С Python 3 уже всех заколебали. Он никому не нужен. И все, кто хотел, уже давно свалили с этого языка на нормальные. Не надо поддерживать иллюзию что им пользуются все, язык уже давно в предсмертном состоянии.
Забавно. Язык/интерпретатор конечно не идеал, особенно когда уже знаешь/изучаешь всё большее количество языков, но точно один из удобнейших для определенных вещей.
И ещё забавнее то, что сейчас в разработке вижу множество крупных веб-проектов в сфере где работаю, которые отбирают определенные позиции у команд C#/JavaДа и Вы наверно не слышали про очень удобную систему управлению софтом Ansible, которая позволяет управлять заопарком серверов, без заранее предустановленных программ-агентов?! Так вот, её сейчас очень активно портируют под поддержку python3.
> Забавно. Язык/интерпретатор конечно не идеал, особенно когда уже знаешь/изучаешь всё большее
> количество языков, но точно один из удобнейших для определенных вещей.
> И ещё забавнее то, что сейчас в разработке вижу множество крупных веб-проектов
> в сфере где работаю, которые отбирают определенные позиции у команд C#/JavaМножество web-проектов, что касается клиентской части, ведутся на платформо-нейтральном HTML/JS/CSS. Остальные направления разработки клиентских программ на иных технологиях — заведомо тупиковые и/или нишевые.
Всё, что вы сказали об отбирании позиций у команд C#/Java относится, наверняка, либо к серверной части разработки софта, либо к той самой тупиковой/нишевой части, что я указал.
Так в какой части отбираются позиции у команд C#/Java, можете уточнить?> Да и Вы наверно не слышали про очень удобную систему управлению софтом
> Ansible, которая позволяет управлять заопарком серверов, без заранее предустановленных
> программ-агентов?! Так вот, её сейчас очень активно портируют под поддержку python3.Последнее упоминание этой системы датируется 2013 годом.
>> > И ещё забавнее то, что сейчас в разработке вижу множество крупных веб-проектов
> в сфере где работаю, которые отбирают определенные позиции у команд C#/JavaКонечно же я имел ввиду python в бэкэнде и в сервисах. Ни JAVA, ни С# с питоном в браузеры не идут(без трансляции).
Про Ansible, про какое именно упоминание ты имеешь виду?
Посмотри количество отметок(star) и форков самых популярных систем управления.конф. на гитхабе
Такое "цитирование" для тебя понятнее будет:https://github.com/chef/chef &n...
https://github.com/puppetlabs/puppet - Этим двум системам по 10лет, и ансибл, появившаяся в 2012, уже набирает юзербазу темпами большими чем эти.https://github.com/ansible/ansible
Вот ещё одна система на питоне, но сам её не использовал:
https://github.com/saltstack/saltПитон стоит по умолчанию на многих версиях линукс, либо идет с зависимостями, что не скажешь к примеру про руби.
> https://github.com/ansible/ansible
> https://github.com/saltstack/saltобе очень интересные. и, что характерно, python2-only.
C++98, C++11 или C++1z? Будьте специфичней.
У C++ обратная совместимость, т.ч. это не имеет абсолютно никакого значения
Обратная совместимость означает лишь, что вы соберете свой старый код не встречая серьезных проблем. Но вот с написанием нового возникает загвоздка - либо его делать с использованием C++98, либо мешать старый код с C++11.Вот еще:
// C++98
vector<LargeObject> v;
v.push_back(LargeObject(10)); // колирование, упсvector<LargeObject*> v2;
v2.push_back(new LargeObject(10)); // ОК// C++11
vector<LargeObject> v3;
v3.emplace_back(10); // ОКvector<unique_ptr<LargeObject>> v3;
v3.emplace_back(new LargeObject(10)); // NOOOO!Такое многообразие, как вы понимаете на качестве выходного кода не очень-то хорошо сказывается. Но да, обратная совместимость.
Не говорите ерунды, в c++ нет такой проблемы, проблема в вашей голове.
Вот так вот:
v3.emplace_back(new LargeObject(10)); // NOOOO!
считается писать, как минимум дурным тоном. Оператор new имеет смысл использовать в крайне редких, исключительных ситуациях. Современный c++ позволяет вовсе обходиться без него. А если Вы употребляете его вот так вот в контейнере, то, как минимум, Вы некомпетентны в вопросе и спорить с Вами не о чем.
> считается писать, как минимум дурным тоном.Ну вот и в Питоне 2 накопилось очень много потенциального "плохого тона". И дабы не провоцировать разработчиков, сомнительные возможности выбросили из языка, пожертвовав обратной совместимостью.
> А если Вы употребляете его вот так вот в контейнере, то, как минимум, Вы некомпетентны в вопросе и спорить с Вами не о чем.
Я - нет, но вопрос на StackOverflow где человек рьяно защищал такую постановку задачи попадался. Если аккуратно разложить грабли и наставить табличек "ходить запрещено", кто-нибудь обязательно наступит.
и как портировать скрипты на C++ ?
Если найтивно не устраивает, есть boost и Qt. Не знаю областей, которые бы каждая из этих библиотек не охватывала бы.
> Если найтивно не устраивает, есть boost и Qt. Не знаю областей, которые бы каждая из этих библиотек не охватывала бы.А еще есть ворд и эксел, да.
Qt и boost и множество других либ ускоряют разработку на c++ до уровня питона. А так да, есть дофига всего, в т.ч. и ворд и эксел. Только вот от этого питон не становится быстрее.
1. https://docs.python.org/2/library/2to3.html
2. ln -s `which python3` /usr/bin/python
- Port the project to a hybrid Python 2/3 codebaseВы понимаете что это значит, или новости читать не обучены перед публикацией своих "глубоких мыслей"?
У Python3 есть один серьезный недостаток - все строки внутри юникод.
Что увеличивает расход памяти в 2 раза, ухудшает обработку текста (приходится заворачивать в обертки из if sys.version==2 и т.д.). И регрессии в работе сетевых библиотек. Особенно неприятно при ручном формировании REST-запросов, встроенном IMAP-клиенте и прочих развлечениях старого интернета.
У Python2 есть фатальный недостаток - все строки внутри байтовых последовательностей, в то время как требуется нормальный Юникод
а какие они должны быть, ascii?
>> Особенно неприятно при ручном формировании REST-запросова что происходит когда вы получаете запрос с не входящими в ascii символами? и вы хотите, насколько, я понимаю с полученным работать ещё и как с байтовой последовательностью? срез например..
>увеличивает расход памяти в 2 разаman UTF-8
JFYI: в CPython python2 юникодные строки и в python3 строки используют не utf-8 в char, а в UCS2 или UCS4 в wchar_t - в зависимости от платформы.Пруф:
https://docs.python.org/2/c-api/unicode.html
https://docs.python.org/3/c-api/unicode.html
Убейте меня еще одни не видит разницы между Unicode и UTF-8
> все строки внутри юникод. Что увеличивает расход памяти в 2 разаМожно тесты?
> ухудшает обработку текста (приходится заворачивать
> в обертки из if sys.version==2 и т.д.).Вы слыхали о six?
Разве язык не должен предоставлять простой синтаксис работы с данными, без всяких "six"? Небось он пестрит подобного рода костылями?
> Разве язык не должен предоставлять простой синтаксис работы с данными, без всяких "six"?Вы хоть немного потрудитесь узнать о языке, прежде чем пороть чушь.
Причем тут "работа с данными"? six - библиотека для обеспечения переносимости между двойкой и тройкой. Надеюсь, все слова понятны?
six - это пакет для тех кто хочет что бы его софт работал как на python2, так и на python3. Если приложение под определенную версию питона, то он не нужен вообще.
Боюсь, это утверждение -- результат банального непонимания.И во втором, и в третьем есть два типа, юникод и последовательность байтов. И отличий только два. Во-первых, в том, какой из двух типов называется str. Во-вторых, какой тип имеет строковая константа в кавычках, если перед кавычками нет буквы.
Единственное сколько-то заметное увеличение расхода памяти, вызванное именно языком -- что название полей объектов стали именно юникодными. Но, уверяю, это крайне незначительный рост, несколько байтов на поле (при том, что структура объектов Python ест на порядок больше, т.к. имена полей коротки).
Увеличение потребления памяти -- в основном результат того, что в программах под Python 3 часто некритично используется строка там, где достаточно именно цепочки байтов. Иногда это даже разумно, но не всегда.
У питона есть фатальный недостаток - у него нет своей ниши. Всё, что на нем пишется, может быть гораздо проще, быстрее и качественнее реализовано на других языках. И в большинстве случаев выбор питона вообще ничем не оправдан. Перспективность языка до сих пор под большим вопросом. Посмотрим чего они добьются, но я сомневаюсь что чего-то существенного. Гораздо правильнее было бы сейчас его завернуть и не портить головы молодых разработчиков.
Получается, что его ниша -- возможность вместо этих всех языков писать на нем одном. :-)
Попытки делать гибрид самолета и подлодки показали: можно! Просто получается х..вый самолет и такая же подлодка.
а если помягче аналогию взять, например, вездеход и гоночный болид? получится внедорожник - вполне популярное решение
универсальность - тоже плюс, вон как раз недавно в парсере сайтов для Коди питон обнаружил, и ведь не единственный случай, когда так внезапно натыкался. и ведь приятно, что скрипт на знакомом языке, все ж сразу как на ладони
В большинстве случаев это временные тормозные решения. Питон никогда не будет легок и быстр. Насчет ниши - это "скрипты" для решения частных задач, не более.
> В большинстве случаев это временные тормозные решения.IPython, matplotlib, numpy, nipy...
Вы реально полагаете что здесь людям интересны "тормозные решения"?
> IPython, matplotlib, numpy, nipy...
> Вы реально полагаете что здесь людям интересны "тормозные решения"?Ну и чего? Тут как с матлабом, пока только вызываешь матричные библиотеки - все быстро, как что-то этим не ограничивается, то в 100 рах медленнее.
>> IPython, matplotlib, numpy, nipy...
>> Вы реально полагаете что здесь людям интересны "тормозные решения"?
> Ну и чего? Тут как с матлабомНу вас носом ткнули. Хотите - продолжайте верить что это "матлаб".
> то в 100 рах медленнее.
С двумя разами один анонимный крикун выше уже сел в лужу. И убежал, явно стесняясь.
Его лавры покоя не дают?
критические к производительности части пишут на том же си
и это не говорит о какой-то ущербности (как и не говорят об ущербности си ассемблерные вставки), так и задумывалось - питон легко готовит данные, си быстро считает
интеграции с другими языками с самого начала уделялось большое внимание
>> критические к производительности части пишут на том же сипарочка примеров:
https://github.com/scipy/scipy/tree/master/scipy/fftpack/src
https://github.com/numpy/numpy/tree/master/numpy/core/src
Здравствуйте дорогой теоретик.
https://github.com/search?utf8=%E2%9C%93&q=py... 159488 репозиториев на гитхабе с вами не согласны.
И сколько из них не тормозит и не может быть лучше реализовано на другом языке? Сколько из них не заброшено? Я сейчас не поленился и посмотрел - там одни поделия домохозяек
Дада... Надо писать на lisp! Ура lisp! Лучший язык! RMS одобряэ.
Всё правильно, Лисп лучше всех!
>>Всё, что на нем пишется, может быть гораздо проще, быстрее и качественнее реализовано на других языках.с чего бы это?
у питона вменяемый, лаконичный, логичный, легко запоминающийся синтаксис, поэтому писать на нем быстро и приятно
и при том куда побогаче выглядит (я про синтаксис), чем С или Джава например
и поддерживать проще, потому что простыни кода на нем внезапно становятся в 2 раза короче, чем где-то еще (отступы как элемент синтаксиса не напрягают совершенно, так как на других языках все равно их тоже всегда делаешь), согласитесь, это приятно, когда скроллить надо в 2 раза меньшев общем, покодируйте немного, и вы увидите, что языки - это не только набор библиотек или каких-то формальных характеристик, а-ля "юникод-не юникод", поддержка каких-нибудь многопоточностей и тп
понятно, что на роль ынтерпрайза питон не претендует, но если человеку надо наваять что-то средней сложности (к тому же переносимое), вполне пойму, почему выбором будет именно этот язык
и да, следует добавить, в языке реально широкие возможности (на уровне синтаксиса) по работе с коллекциями, последовательностями, строками и тп, после C/Java просто праздник какой-то
не зря в том же Machine Learning, так понимаю, Python - сейчас ведущий язык
Всё это есть и в C++. Не морочьте народу голову.
Есть нормальный синтаксис для работы со строками?C++:
#include <iostream>
#include <string>
int main( ) {
std::string greeting( "Hello" ) ;
greeting.append( " , world!" ) ;
std::cout << greeting << std::endl ;
return 0 ;
}
Pyhon:
str = "Hello";
str += " , world!";
print(str)http://rosettacode.org/wiki/String_append#C.2B.2B
Это конечно же не значит, что питон предел мечтаний. Но проблемы с переусложнением синтаксиса у C++ есть.
Мне лично больше D нравится - похож на C/C++, но с нормальным синтаксисом.
import std.stdio;
void main() {
string s = "Hello";
s ~= " world!";
writeln(s);
}
Я тоже могу всё упростить, тем же using namespace std:C++:
string greeting = "Hello";
greeting += " , world!";
cout << greeting;Pyhon:
str = "Hello";
str += " , world!";
print(str)Что ответите на это?
А вот что: ты сознательно не написал инклуды и мэйн, как минимум.
и, да: ты забыл написать свой using namespace std и фигурные скобки. Вот как напишешь все строчки как надо, тогда и сравнивай
using namespace std пишется один раз. Можно прописать в проекте, тогда в коде вообще не понадобится использовать эту строку.
Насчет написания всех строк - ты наверно забыл, что для работы питона в систему надо впихнуть огромный такой пакет - сам питон. И иногда и перл и уйму других неоправданных зависимостей.
> Насчет написания всех строк - ты наверно забыл, что для работы питона
> в систему надо впихнуть огромный такой пакет - сам питон. И
> иногда и перл и уйму других неоправданных зависимостей.Как не вспомнить glibc.
Если придираться - нет перевода на новую строку. Но в целом - согласен, такой синтаксис приемлем.Было бы интересно взглянуть на ваше решение другой задачи: убрать из строки 6 первых символов и 2 последних.
Пример на D:
import std.stdio;
void main() {
string s = "Hello World!!!";
s = s[6 .. $ - 2];
writeln(s);
}
> Мне лично больше D нравится - похож на C/C++, но с нормальным синтаксисом.
> s ~= " world!";И это бессмысленное называется - похож на C/C++, но с нормальным синтаксисом?
это 2 зайцев одним выстрелом - и не похоже и ненормально.
Ну в этом конкретном месте непохож ;)И на это есть веские основания: строки в D - массивы символов. '+' используется для сложения содержимого массивов, '~' используется для соединения массивов друг за другом. ИМХО вполне логично.
> Ну в этом конкретном месте непохож ;)
> И на это есть веские основания: строки в D - массивы символов. '+' используется для сложения содержимого массивов, '~' используется для соединения массивов друг за другом. ИМХО вполне логично.Начав сдирать работу с массивами с матлабоподобных языков логично было бы и остальное содрать как там 100 лет сделано. Но программистская логика, такая логика. Хуже женской. В итоге очередная сборная солянка - не ц, не матлаб, не жаба а очередная неведома зверюшка.
Зачем мне еще один matlab или C? Мне нужен язык который возьмет наиболее удачные решения из остальных.
> Зачем мне еще один matlab или C? Мне нужен язык который возьмет наиболее удачные решения из остальных.Я бы тоже не отказался. Так из какого языка взято это удачное решение s ~= " world!" ? Это даже не говоря о том, что сама группа операторов вида ~= это крайне неудачное решение времен компиляторов 1970-х, которые не могли сами понять что с обоих сторон присваивания одна и та же переменная. Сейчас в этом сбивающем с толку синтаксисе нужды вообще нет.
> Сейчас в этом сбивающем с толку синтаксисе нужды вообще нет.И какой по-вашему должен быть синтаксис для:
s ~= " world!";
string s2 = s ~ " anything ";
Тогда вам подойдет Rust
Смотрел, некоторые идеи понравились. Но как-то не почувствовал, что это именно то, чего хотелось бы именно мне. С D было наоборот - то что не нравилось в C++ переработали и добавили то, чего не хватало и именно так, как сделал бы я сам (не все конечно совпало, но пока D ближе всего к моему идеалу ЯП).
Тогда объясните, пожайлуста, почему именно на C\C++ пишут крупные проекты а Пайтон используют как скриптовой язык?
С D не сталкивался, но сюдя по вашему примеру он намного сложенее C++ по синтаксису.
> Тогда объясните, пожайлуста, почему именно на C\C++ пишут крупные проектыВысокая скорость и низкое потребление памяти.
> С D не сталкивался, но сюдя по вашему примеру он намного сложенее
> C++ по синтаксису.Не знаю что вас смутило в моем примере, но в целом D гораздо проще C++, при этом сохраняет все основные возможности С++, скорость также близка к C/C++ + удобная работа с массивами (строками) и простые шаблоны.
> Не знаю что вас смутило в моем примере, но в целом D гораздо проще C++ц++ конечно гуано, но довольно простой язык. просто надо выкинуть крайности его сумасшедших изобретателей. собственно на таком языке все и пишут, кому писать надо, а не ребусы решать. Тогда и шаблоны проше некуда, пишешь в начале template заменяешь конкретный параметр на Т и все, куда уж проще то. Угловые
>при этом сохраняет все основные возможности С++, скорость также близка к C/C++ + удобная работа с массивами (строками) и простые шаблоны.
Короче это (как обычно) еще один ц++ но еще + с собственными уникальными заморочками и несовместимостями и нераспространенный. жаба скажем хоть распространенный.
>> Не знаю что вас смутило в моем примере, но в целом D гораздо проще C++
> ц++ конечно гуано, но довольно простой язык. просто надо выкинуть крайности его
> сумасшедших изобретателей.Именно это в D и попытались сделать.
> собственно на таком языке все и пишут, кому писать
> надо, а не ребусы решать.
> Тогда и шаблоны проше некуда, пишешь
> в начале template заменяешь конкретный параметр на Т и все, куда
> уж проще то.Есть куда ;)
http://www.digitalmars.com/d/1.0/template-comparison.htmlЭто еще про D1, но в целом справедливо и для D2.
> Короче это (как обычно) еще один ц++ но еще + с собственными
> уникальными заморочками и несовместимостями и нераспространенный.Если думать только о распространенности и совместимости, то новых ЯП мы не увидим. В D и так почти полную совместимость с C оставили, вначале это меня подкупило, а теперь думаю что возможно нужно было уйти от С немного подальше. Например Rust отказался от скобок в if вокруг условия, но сделал обязательными фигурные скобки - ИМХО очень удачное решение.
> и да, следует добавить, в языке реально широкие возможности (на уровне синтаксиса)
> по работе с коллекциями, последовательностями, строками и тпSICP не читали часом?
Интересно, вспомнившие тут SICP - хоть знают насколько практические реализации Scheme отличаются от этого курса? Даже как-то неловко в такие штуки тыкать.Да, самые разные удобства можно прикрутить. Вот и делают это кто во что горазд. Ср. с "batteries included" в Python.
> Да, самые разные удобства можно прикрутить. Вот и делают это кто
> во что горазд. Ср. с "batteries included" в Python.Знаете, мне *на практике* гораздо удобней схемовые "прикрутки", чем самовзрывающиеся батарейки в комплекте -- которые, судя по вашему с netch давешнему обсуждению, самое позднее к четвёртому питону опять начнут напяливать на вешалку, потому что так жить нельзя.
Просто есть языки, над которыми думали изначально -- в т.ч. и над представлением структур данных; а есть паскали-переростки, у поклонников которых вечно дамоклова версия над башкой ("программист на дельфи пять" -- диагноз ровно из того же балагана).
> Просто есть языки, над которыми думали изначально -- в т.ч. и над
> представлением структур данных; а есть паскали-переростки, у поклонников которых вечно
> дамоклова версия над башкой ("программист на дельфи пять" -- диагноз ровно
> из того же балагана).Что вы имеете сказать против программистов на Delphi 5?
>> ("программист на дельфи пять" -- диагноз ровно из того же балагана).
> Что вы имеете сказать против программистов на Delphi 5?Люди со стажем поняли. :)
>>> ("программист на дельфи пять" -- диагноз ровно из того же балагана).
>> Что вы имеете сказать против программистов на Delphi 5?
> Люди со стажем поняли. :)Программы на Delphi 5 перестали запускаться в современных версиях Windows и WINE?
> Что вы имеете сказать против программистов на Delphi 5?Их главный недостаток в том что они могли сделать то же самое, что и он, но быстрее и без мозготраха. Ну понятно ведь что это совершенно невыносимо.
> Знаете, мне *на практике* гораздо удобней схемовые "прикрутки"Дак если практика ограничивается локалхостом - оно так. А вот если речь
идет о промышленном использовании... Либо ты понимаешь необходимость
стандартизации - либо профнепригоден тут.> чем самовзрывающиеся батарейки
> в комплекте -- которые, судя по вашему с netch давешнему обсуждениюНе напомнишь? Если я правильно помню, мы обсуждали спорные улучшения
в py3 (vs py2), а именно - деление целых. Плюс подход в питоне по отношению к
обратной совместимости (там таки удаляют вещи, объявленные устаревшими,
в отличие от некоторых).> Просто есть языки, над которыми думали изначально -- в т.ч. и над
> представлением структур данныхДа какие в Scheme "структуры данных"... Lisp он и есть Lisp - списки. А сверх
этого - разве вектора еще прикрутили в стандарт, вот и все. Брось эту рекламу.
Стандартизация Scheme - тот еще балаган, почище разных питонов.И на самом деле - нет языков, над которыми изначально не думали. Просто
в принципе. С разным успехом, понятное дело. Вот кто-то таки и решил признать
очевидное. Если факапы таки неизбежны - давайте признаем необходимость
эволюции языка и как-то ее упорядочим, и давате не тащить с собой бесконечно
разный хлам "для совместимости". Здравая мысль, нес па?
>> Знаете, мне *на практике* гораздо удобней схемовые "прикрутки"
> Дак если практика ограничивается локалхостом - оно так.Извините, но оправдываться перед людьми, величая "промышленными стандартами" гигантские костыли, всё так же не намерен. При этом мой код существует в миллионных, если не более, тиражах уже достаточно давно и над сопутствующими вопросами задумывался и задумываюсь.
>> -- которые, судя по вашему с netch давешнему обсуждению
> Не напомнишь?Обсуждение было в районе https://www.opennet.ru/openforum/vsluhforumID3/93345.html#321 (судя по моему архиву).
>> Просто есть языки, над которыми думали изначально -- в т.ч. и над
>> представлением структур данных
> Да какие в Scheme "структуры данных"...Вот такие -- простенькие, бедненькие, зато в них весь язык заодно укладывается и сам.
> Стандартизация Scheme - тот еще балаган, почище разных питонов.
http://www.schemers.org/Documents/Standards/R5RS/ чем именно не устроил?
> И на самом деле - нет языков, над которыми изначально не думали.
Да ладно, тот же фокал со своими 25+26 допустимыми функциями -- это "думали"?.. (хотя, пожалуй, это уже об определениях)
>>> Знаете, мне *на практике* гораздо удобней схемовые "прикрутки"
>> Дак если практика ограничивается локалхостом - оно так.
> Извините, но оправдываться перед людьми, величая "промышленными стандартами" гигантские
> костыли, всё так же не намерен.Ну костыли или нет - спорить не хочу за отсутствием у оппонента аргументов. Дело
вкуса. Однако "схемовыми прикрутками" мало кто пользуется, и это факт. Думаю,
отчасти и потому что стандартная библиотека - куцая, о переносимости кода - лучше
не думать.>>> -- которые, судя по вашему с netch давешнему обсуждению
>> Не напомнишь?
> Обсуждение было в районе https://www.opennet.ru/openforum/vsluhforumID3/93345.html#321Ну да, оно. Там еще спорили о тестах, показывающих регрессии производительности
в py3. 10-15% в случае "страшного" unicode (для bytes - разницы нет), возведение в степень для
малых чисел (для больших - наоборот, обратная картина). Разные языки. Что-то стало быстрее - что-то наоборот. И?>>> Просто есть языки, над которыми думали изначально -- в т.ч. и над
>>> представлением структур данных
>> Да какие в Scheme "структуры данных"...
> Вот такие -- простенькие, бедненькие, зато в них весь язык заодно укладывается и сам.Да это оно, конечно, дело нехитрое. После чего все начинает тупить, ибо
понятие "структуры данных" - списками Lisp не заканчивается. Все остальное,
конечно, можно тоже эмулировать списками. Но тогда школие будет тыкать
на тему производительности в твой лисп, вместо python (причем куда более обосновано).>> Стандартизация Scheme - тот еще балаган, почище разных питонов.
> http://www.schemers.org/Documents/Standards/R5RS/ чем именно не устроил?Ну, есть еще ISO, есть r6rs (после которого, по идее, r5 должен считаться устаревшим),
и уже скоро будет есть r7rs.Не устроил именно тем, что там ничего нет (что пробовали пофиксить в r6rs, но обломались).
>> И на самом деле - нет языков, над которыми изначально не думали.
> Да ладно, тот же фокал со своими 25+26 допустимыми функциями -- это
> "думали"?.. (хотя, пожалуй, это уже об определениях)Думали, конечно. Ну не верю я в то, что дизайнеры языка могут быть BDSM-щиками,
по крайней мере в переносном смысле. Тем более, если он оказался востребованным на практике.Brainfuck'и не предлагать - это все-таки случай особый.
> Ну костыли или нет - спорить не хочу за отсутствием у оппонента аргументов.А как ещё назвать six, 2to3 и подобное?
> Однако "схемовыми прикрутками" мало кто пользуется, и это факт.
Чем больше что-то требует мозгов в силу своей нетривиальности (и плодотворности именно потому), тем меньше пользуются, что закономерно. Но этотъ линуксоводъ и коммунистъ вовсю пользуется типично западной метрикой популярности и его ни разу не коробит, он честен и последователен в своих собственных глазах...
> Думаю, отчасти и потому что стандартная библиотека - куцая,
> о переносимости кода - лучше не думать.Смотрите, люди: когда надо макнуть -- вытаскивается из кармана "переносимость" (с которой применительно к схеме человек вряд ли сталкивался как раз)...
> Разные языки.
...а когда надо замазать -- вторая и третья версия языка объявляются разными языками. Вот так просто и элегантно "решаются" проблемы с переносимостью.
Дебианщикам-то, о которых новость, расскажите. Глядишь, и переписывать бросют.
> понятие "структуры данных" - списками Lisp не заканчивается. Все остальное
Знаете, я в курсе, а про "тормоза" можете рассказать тем древним железкам, на которых лиспы ворочались весьма шустро задолго до линукса -- вдруг что поведётся. Или в качестве упражнения на любопытство прикиньте, что получится с производительностью, если переписать AI той же abuse на каком угодно питоне.
> Не устроил именно тем, что там ничего нет (что пробовали пофиксить в
> r6rs, но обломались).Некоторым из нас хватает за глаза.
PS: впрочем, нет никакого настроения разводить на эту тему -- спор математика с разнорабочим получается, задано это языками, ничего тут не попишешь и никаким numpy не подопрёшь то, что некоторые умеют лямбда-исчисление, а некоторые не понимают, зачем такое вообще в языке. Так что предлагаю делать полезное каждому на своём месте и своими инструментами :)
>> Ну костыли или нет - спорить не хочу за отсутствием у оппонента аргументов.
> А как ещё назвать six, 2to3 и подобное?По разному.
2to3 - транслятор из py2 в другой язык.
А six - библиотека, эмулирующая обратную совместимость между py2 и py3.
>> Однако "схемовыми прикрутками" мало кто пользуется, и это факт.
> Чем больше что-то требует мозгов в силу своей нетривиальности (и плодотворности именно
> потому), тем меньше пользуются, что закономерно.И чего там нетривиального? Синтаксис прост как валенок, еще проще
Python. Школие-ж на нем учат (или учили, как минимум).> Но этотъ линуксоводъ и коммунистъ вовсю пользуется типично западной
> метрикой популярности и его ни разу не коробитПочему западной? Плохие технические решения, как правило, непопулярны. И наоборот.
Если б это был единственный аргумент в пользу проблем с данным языком - я бы
согласился покоробиться. Так нет, я привел и другие...>> Думаю, отчасти и потому что стандартная библиотека - куцая,
>> о переносимости кода - лучше не думать.
> Смотрите, люди: когда надо макнуть -- вытаскивается из кармана "переносимость" (с которой
> применительно к схеме человек вряд ли сталкивался как раз)...Человек, между прочим, даже интерпретатор схемы писал в свое время. А уж с
переносимостью... Ну вон, festival с собой почему-то свою схему тащит. Але, guile? Але,
rocket? Далее - везде.>> Разные языки.
> ...а когда надо замазать -- вторая и третья версия языка объявляются разными
> языками. Вот так просто и элегантно "решаются" проблемы с переносимостью.Переносимость - это когда вот есть CPython, а вот есть PyPy. А скриптам это - по барабану.
А py2 vs py3 - это про обратную совместимость. Которой в данном случае решили
пожертвовать. Такой момент, кстати, и в схеме есть (или лучше сказать - нет, в смысле
"нет совместимости"). Читать "Language Changes" в r7rs до просветления и
появления отчетливого чувства стыда.>> понятие "структуры данных" - списками Lisp не заканчивается. Все остальное
> Знаете, я в курсе, а про "тормоза" можете рассказать тем древним железкам,
> на которых лиспы ворочались весьма шустро задолго до линуксаТак а чего рассказывать? Все это дяди должны были тебе рассказать на
соответствующем курсе, это не формат форума.Ну - вперед. Покажи мне как ты будешь списками эмулировать массив. Без
качественных потерь на операциях. Реальные реализации схемы почему-то сдаются
и делают это на другом языке (C например). Может потому что авторы в школе учились?> задано это языками, ничего тут не попишешь и
> никаким numpy не подопрёшь то, что некоторые умеют лямбда-исчисление, а некоторые
> не понимают, зачем такое вообще в языке.Лямбда-исчесление, конечно, это круто. Но это не единственная модель вычисления, да
и не самая близкая физике реальных компьютеров, прямо скажем.Кстати, Python, естественно, *умеет* лямбда-исчисление. Как и любой язык
программирования. Полагаю, "разнорабочий" в твоем лице имел в виду таки что-то другое? ;)
> И чего там нетривиального?Состояние мозгов "в потоке", а не "набором инструкций". Гругря, тут и вспоминаешь оценки в считанные проценты "обладающих логическими способностями для работы с компьютером" полувековой давности -- когда отталкивались от математики, а не примерного ощущения, что "вот это можно пристыковать куда-то сюда".
> Синтаксис прост как валенок, еще проще Python.
> Школие-ж на нем учат (или учили, как минимум).Синтаксис беднее и другой (см. тж. порождение программ на языке при помощи программы на нём же).
А учить -- не значит выучить, увы. Думаю, Вы, как и я, многое из того, чему учили и будто даже научили, уже не помните и не умеете.
>> Но этотъ линуксоводъ и коммунистъ вовсю пользуется типично западной
>> метрикой популярности и его ни разу не коробит
> Почему западной? Плохие технические решения, как правило, непопулярны. И наоборот.Крайне сильно ошибаетесь, см. те же win95-vs-os2.
Уже упоминал в подобных контекстах, но всё так же искренне советую найти время на Пола Грэма и его не слишком объёмную статью "why nerds are unpopular" / "почему нерды непопулярны":
http://www.paulgraham.com/nerds.html
http://old.russ.ru/netcult/gateway/20030422-pr.html> Человек, между прочим, даже интерпретатор схемы писал в свое время.
А зачем, из интересу или лабораторка?
> А уж с переносимостью... Ну вон, festival с собой почему-то свою схему тащит.
Вот у них бы и спросить.
>> Вот так просто и элегантно "решаются" проблемы с переносимостью.
> Переносимость - это когда вот есть CPython, а вот есть PyPy.
> А скриптам это - по барабану.Даже с горячо любимым numpy? :)
> А py2 vs py3 - это про обратную совместимость. Которой в данном случае решили
> пожертвовать. Такой момент, кстати, и в схеме есть (или лучше сказать
> - нет, в смысле "нет совместимости"). Читать "Language Changes" в r7rs до
> просветления и появления отчетливого чувства стыда.И за что _мне_ должно быть в этом плане стыдно? Посмотрите в #66, кто вообще завёл речь о "переносимости" (я-то бы при желании обеспечить таковую для своего лиспообразного кода сидел бы на CL и не отсвечивал).
Так-то могу ещё про shim между ruby 1.6 и 1.8 напомнить, тоже костыль -- только поэлегантней, проблем не вызывал.
> Так а чего рассказывать? Все это дяди должны были тебе рассказать
> на соответствующем курсе, это не формат форума.Соответствующий -- это "лекарственные вещества" или кристалка? :)
> Ну - вперед. Покажи мне как ты будешь списками эмулировать массив.
> Без качественных потерь на операциях. Реальные реализации схемы почему-то сдаются
> и делают это на другом языке (C например). Может потому что авторы в школе учились?С другой стороны, в том же picolisp их даже эмулировать не стали: http://software-lab.de/doc/faq.html#arrays
> Лямбда-исчесление, конечно, это круто. Но это не единственная модель
> вычисления, да и не самая близкая физике реальных компьютеров, прямо скажем.Об этом предлагаю поговорить опять тогда, когда за бинарность начнут как минимум недолюбливать -- есть к тому основания. Но это совсем-совсем отдельная тема...
> Кстати, Python, естественно, *умеет* лямбда-исчисление.
> Как и любой язык программирования.Так-таки любой?
> Полагаю, "разнорабочий" в твоем лице имел в виду таки что-то другое? ;)
В Вашем, любезнейший, в Вашем. А я так, математик -- не чета структуральнейшим лингвистам вроде этого персонажа: http://www.artima.com/weblogs/viewpost.jsp?thread=98196
Причём это не оскорбление -- просто есть ремесло и ремесленники, они делают много полезного, но мастерство им ни к чему: всё же и так работает, а если не работает, то чичас подкувалдим. От мастера может и не быть столько пользы на месте, поскольку он, зараза, вместо кувалды будет долго и нудно возиться с каждой "незначащей" мелочью...
Мне учителя достались как раз такие -- въедливые, требовательные, любящие своё дело и держащие его куда выше ремесла. Ну а им достался уж какой есть материал, который теперь не даёт покоя любителям "быренько".
(А не взломали ли аккаунт Шигорина? Какая-то нехарактерная чушь.)>> И чего там нетривиального?
> Состояние мозгов "в потоке", а не "набором инструкций".Т.е. это сяо никак не формализуемо?
>> Синтаксис прост как валенок, еще проще Python.
>> Школие-ж на нем учат (или учили, как минимум).
> Синтаксис беднее и другой (см. тж. порождение программ на языке при помощи
> программы на нём же).Что значит "беднее"? Что значит "порождение программы на нем же" и почему
это мне нельзя в Python?> А учить -- не значит выучить, увы. Думаю, Вы, как и
> я, многое из того, чему учили и будто даже научили, уже
> не помните и не умеете.Я к тому, что для "педагогиццких целей" - инструменты выбирают, как правило,
непритязательные и простые. Вот и схема...>>> Но этотъ линуксоводъ и коммунистъ вовсю пользуется типично западной
>>> метрикой популярности и его ни разу не коробит
>> Почему западной? Плохие технические решения, как правило, непопулярны. И наоборот.
> Крайне сильно ошибаетесь, см. те же win95-vs-os2.А что не так с win95? Я не впадаю в истерику от умоминания Microsoft и более
чем готов признать технические достоинства win95. Отношение к обратной
совместимости (лагерь "Реймонда Чена"), как пример. Технические решения
нужно сравнивать по куче параметров а не по одной заоблачной крутости для
какой-то категории задротов.>> Человек, между прочим, даже интерпретатор схемы писал в свое время.
> А зачем, из интересу или лабораторка?Скорее, из интересу.
>> А уж с переносимостью... Ну вон, festival с собой почему-то свою схему тащит.
> Вот у них бы и спросить.Так спроси. Разработчиков Gimp тоже спроси, или Gnucash. Все что-то либо тащат
с собой свою собственную схему - либо требуют определенный интерпретатор (guile или
еще что). Собственно, в Debian я нашел ровно один пакет (jacal), который позволяет
использовать аж две реализации схемы (scm|guile-1.6). Впрочем, теперь уже одна...>>> Вот так просто и элегантно "решаются" проблемы с переносимостью.
>> Переносимость - это когда вот есть CPython, а вот есть PyPy.
>> А скриптам это - по барабану.
> Даже с горячо любимым numpy? :)C API - это ниже пояса...
А если я пальцем ткну как расширения guile переносимы? В схеме здесь совсем
караул, а в Python, например, вполне можно писать переносимые C расширения для
CPython и PyPy.>> А py2 vs py3 - это про обратную совместимость. Которой в данном случае решили
>> пожертвовать. Такой момент, кстати, и в схеме есть (или лучше сказать
>> - нет, в смысле "нет совместимости"). Читать "Language Changes" в r7rs до
>> просветления и появления отчетливого чувства стыда.
> И за что _мне_ должно быть в этом плане стыдно?То что Python реально поддерживает обратную совместимость (в 2-й и 3-й ветке,
соответственно). В отличие от. Каждый новый стандарт Scheme - это как переход от
py2 к py3.>> Так а чего рассказывать? Все это дяди должны были тебе рассказать
>> на соответствующем курсе, это не формат форума.
> Соответствующий -- это "лекарственные вещества" или кристалка? :)"Алгоритмы и структуры данных".
> С другой стороны, в том же picolisp их даже эмулировать не стали:
> http://software-lab.de/doc/faq.html#arraysТоже есть рациональное зерно. Если ты ковыряешься в носу - достаточно пальца,
а покупать зубочистку - будет излишним и даже, вероятно, вредным.Начнут считать - понадобятся массивы.
>> Кстати, Python, естественно, *умеет* лямбда-исчисление.
>> Как и любой язык программирования.
>
> Так-таки любой?Так-таки. За язык, естественно, понимаем нечто тьюринг-полное.
>> Полагаю, "разнорабочий" в твоем лице имел в виду таки что-то другое? ;)
> В Вашем, любезнейший, в Вашем. А я так, математик [...]-- не
> Причём это не оскорбление -- просто есть ремесло и ремесленникиНет, право, поломали аккаунт...
Окей, давайте и дальше писать бэкэнды сложных вебсайтов на PHP! Долой Питон!
на питон 4 лучше сразу правильно
Новость через 15 лет: Debian закончил формирование команды, можно начинать портирование.
Правда, пока только на python 3, хотя скоро ожидается выход 6й версии.
Толстовато.
Все, кто пользуется убунтой - знайте, тормозит она именно из-за питона, потому что в нем пишешь либо просто и выходит тормозное уг, либо наворачиваешь костылей, размером побольше, нежели вышло бы на том же asm, чтобы работало с приемлемой скоростью и потреблением памяти.
> либо наворачиваешь костылей, размером побольше, нежели вышло бы на том же asm,
> чтобы работало с приемлемой скоростью и потреблением памяти.Можно интересу ради примеры Вашего кода на питоне и ассемблере, которыми бы хорошо иллюстрировалось такое утверждение?
он таких слов не знает
В ubuntu много софта на нем, переписывать который некому. Питон ориентирован на повышение производительности разработчика и читаемости кода, и конечно повальное его применение везде - глубокое заблуждение в понимании его задач такими программистами. Высокая производительность и низкое потребление памяти ПО не являются целями данного языка. Если они вам нужны именно на питоне, разворачивайте велосипеды, в любом случае это ваша проблема. А так вам уже сказали, есть универсальные языки, типа C++. Изучайте и проблем не будет.
Подскажите, сколько место высвободится, если из убунты выпилить питон?
По весу выйдет как lubuntu