Здравствуйте, vdimas, Вы писали:
F>>только ты облажался с понтами, и на VBA это заметно больше. V>С учётом раскрытия кода кучи библиотек, использованных в питоновском варианте? V>Боюсь, Питон будет одним из самых многословных языков.
боюсь, что питона ты не знаешь, поэтому твоё мнение стоит чуть менее, чем нифига.
иначе бы ты смог прочитать и понять, к чему там это.
T>>хотя народ не унывает и пытается даже сам build написать в каком-нибудь Cake на C#, опять же мне лично проще плыть по течению, и я думаю, что таких, как я — большинство
V>Но под VS2017 уже не получится, увы. V>Если MsBuild до версии 14.0 жил по известному пути, то с приходом VS2017 появилась возможность ставить несколько версий студий в параллель, и обнаружить MsBuild для запуска автоматизированной сборки уже непросто. Однако же, сия функциональность живёт в CMake, поэтому, его порой используют хотя бы просто для того, чтобы узнать, где же живёт нужный инстанс MsBuild. )))
фиг его знает, я Cake не пользую, но народ пишет, что
Здравствуйте, netch80, Вы писали:
V>>>>А так-то сам по себе PHP очень даже неплох, местами на голову выше Питона, разумеется. N>Начни с обоснования этого тезиса, безаргументный ты наш...
— Меньше неявных соглашений.
— Возможность строгой типизации.
— Поддержка абстрактных классов и интерфейсов. Для абстрактного класса можно задать сигнатуру конструктора.
— Абстрактный итератор в языке, возможность описания собственных/произвольных итераторов (не путать с генераторами).
— "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await.
— Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов.
— Декомпозиция элементов языка (можно property описать как объект-шаблон).
— Более последовательная и удобная работа с метаинформацией.
— Константы в языке.
— Явное наличие неймспейсов, операторы области видимости '::'.
— Строгие замыкания, возможность управления замыканием по имени или по-значению, а так же "уровнем" захвата переменной (вот эта вечная боль в JS — когда же надо создавать промежуточную переменную для вложенной иерархии анонимных ф-ий, а когда нет, вся эта боль решается, при надобности, явным use в PHP и указанием типа индирекции).
— Анонимные классы.
— Карринг и частичное применение в явном виде.
— Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов).
— Миксины, трейты, явное управление конфликтами:
class Aliased_Talker {
use A, B {
B::smallTalk insteadof A;
A::bigTalk insteadof B;
B::bigTalk as talk;
}
}
— Туда же ключевое слово final;
— Управление уровнем ссылочности, разыменование ссылок.
— Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах.
— Легкое расширение языка, см. модули паттерн-матчинга, модуля-аналога LINQ, модуль PHP-COM, модуль PHP-.Net, обертки над нейтивом и т.д.
— Наличие позднего статического связывания позволяет разрабатывать абсолютно-достоверную диагностику для кода, т.е. не нужны никакие среды-утилиты, это всё можно делать через встроенные ср-ва языка.
— Легкое подключение нейтивных ф-ий.
Про синтаксису Питона не проходился только ленивый, это объект нескончаемого флейма.
Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально.
Взять даже хотя бы определение статических ф-ий и св-в.
Я не перечислял равные возможности, навроде генераторов yield и т.д., так шта, просьба не пытаться отвечать "а вот у Питона зато есть то-то и то-то" не проверив сначала, в каком виде "оно же" есть в PHP.
PHP рвёт Python как тузик грелку по скорости исполнения кода.
Причём, кто тут попытается что-то говорить (орать?) про CPython и Ко, пытаясь сравнивать их с референсной скриптовой реализацией PHP — лучше сравните их с любым популярным ускорителем PHP, все вопросы отпадут моментально.
===============
В целом и общем Питон более простой язык. Местами вовсе ущербный.
Однако, ввиду своей простоты и спровоцированной этим популярности, накопил довольно много оберток на ведущие нейтивные библиотеки, ввиду чего решение на Питоне может быть достаточно быстрым в целом (где неэффективность его интерпретатора уже не критична).
Язык PHP, ИМХО, стал жертвой доткомовского хайпа конца 90-х, когда этому языку обучали домохозяек. И это не для красного словца, в США популярны были одно время курсы по PHP именно для домохозяек. )) В итоге язык пал первой жертвой "низкой планки входа". Опыт этот был новый, ему никто не противостоял, а когда спохватились — было уже поздно. Слишком много мусорного кода накопилось в PHP, превратив его в экосистему-помойку. Дополнительным усиливающим фактором было то, что фокус тогда был не на самом языке и последовательности его библиотек, а на PHP-страницах, т.е. язык тут был сходу на ролях "чернорабочего".
Очистить всё это можно, конечно, за какие-нить большие вложения, только а смысл? ))
Вот и выходит, что PHP охотно используют относительно большие компании, которые могут позволить себе чуток вложиться в допиливание инфраструктуры самого PHP, взять даже VK или Yandex.
Бо в базе самого языка там всё очень даже ОК.
Сравнивать с ним убогие JS или Python можно лишь от упёртой агнажированности, т.е. поправ всякую объективность.
Здравствуйте, neFormal, Вы писали:
F>Здравствуйте, vdimas, Вы писали:
F>>>ты утверждал, тебе и карты в руки V>>Неоднозначностей в Lua и VB нет.
F>вера — это хорошо, когда вера в добро. F>https://repl.it/repls/LustrousFluffyLocks
И?
Это предопределённое поведение:
function unpack (t, i)
i = i or 1
if t[i] ~= nil then
return t[i], unpack(t, i + 1)
end
end
Не используй nil, какие проблемы?
F>>>у разных библиотек разные подходы. их нельзя сравнивать. V>>Можно сравнивать внешний АПИ зато. F>нельзя.
У тебя забыли спросить.
F>вот где-где а в плюсах это очень заметно, когда язык позволяет сделать ну очень много вариантов апи.
Речь не о разных парадигмах.
А о том, что даже в рамках одной парадигмы устоявшегося подхода нет.
V>>Нифига не встроенный тип, а обычный. V>>namedtuple — тоже. F>начнём с того, что это вообще ф-ция.
Ага. Тут можно начать с того, что создания объекта — это тоже вызов ф-ии.
Так что помешало в стандартной библиотеке принять единообразное решение — контейнеры будут создавать через вызов конструктора или через вызов ф-ии — фабрики?
F>всё с семантикой ф-ции пишется в одном стиле.
Не проканало. ))
F>>>про _TemplateMetaclass очень смешно. показывает твой уровень понимания V>>Так ты бы сходники посмотрел, в этом модуле использутся явное описание экспорта. F>ты не можешь его экспортить
Эта фича была придумана для дефлотного экспорта, но в том модуле используется явный.
Поэтому, не надо отмазок.
Здравствуйте, netch80, Вы писали:
N>Потому что список операций показывает только то, насколько была востребована поддержка. И твоё "даже" для C++ показывает это значительно ярче. N>Не надо мне рассказывать, как рефакторинг усложняется при отсутствии статической типизации — эта тема уже активно отрабатывается (аннотации типов в >=3.6, хотя бы). N>А вот критерий мог бы показать принципиальную возможность или невозможность какого-то вида рефакторинга, но даже тебе должно быть очевидно, что он весь возможен вопрос в цене поддержки и в её востребованности.
Вопрос в модели ООП.
В PHP эта модель явная.
Для типов не "аннотации", а просто указаны типы.
Так же явное наличие абстрактных классов, интерфейсов, трайтов и final.
N>И это я ещё не вспоминаю, зачем тут вообще категорически хотеть сложный рефакторинг для языка прототипирования, если в прототипе некуда те сложные методы применять.
В прототипе можно и нужно не только функциональность прототипировать, но обязательно "играть" с внешним АПИ и основными сценариями.
Разработка АПИ и сценариев его применения — это тоже важная часть разработки, ес-но.
V>>Верно, не отличается. V>>Та же хрень, вид сбоку. V>>Прототипировать на ём можно только от невладения другими ср-вам прототипирования. N>Которые ты, разумеется, никому не покажешь.
Ну а смысл тебе показывать, бо ты не раз проявлял себя как классический хейтер того же дотнета, т.е. не раз занимал позицию отрицания ради отрицания.
И что характерно, что я часто прототипировал на дотнете, а целевые проекты — плюсовые для линухов.
Лично меня это не смущает, я ХЗ почему смущает некоторых. ))
Хотя, с выходом C++17 и точного рефакторинга для С++ от JetBrains особого смысла прототипировать на дотнете уже практически нет.
V>>"По сумме факторов". V>>Я отвечал на конкретные абзацы. N>И неконкретно рубанул с размаху упоминанием этих трёх языков.
Я указал на твой мухлёж.
Надо было прямо писать "он середнячок в разных дисциплинах, но в сумме набирает больше баллов".
Итого, ключевое тут — использование одного и того же языка для всего.
Последние 25+ лет я считаю такой подход ущербным.
V>>Здечь я отвечал на использование в кач-ве языка для высокоуровневой "склейки" в реальных боевых проектах. Питон опять сливает в этом месте. N>Твои глюки другим не видны. Ты бы их хотя бы описал подробно...
Почему мои?
Я отвечал на конкретный твой абзац, контекст там задан.
Питон не очень удобно сопрягать с нейтивом, в отличие от того же VB/VBA/VBS, Lua или дотнета.
Поэтому, "клей" из него откровенно никудышный.
Есть целая охрененейшая библиотека Boost.Python, и даже с её помощью остаётся достаточно траха.
Само наличие такой либы уже много о чём говорит, что задача не из тривиальных.
V>>Кароч, в любой области, где популярны те самые "языки для быстрого написания несложного кода", Питон сливает. V>>Но он сливает РАЗНЫМ языкам в каждой из областей. И сей незамысловатый факт ты решил замылить через образное "по сумме факторов". N>Естественно, есть задачи, где VBS или JS лучше. И что? Это не аргумент использовать их за пределами этих задач
А у меня НЕТ такого аргумента.
Я, наоборот, рекомендую использовать языки, наиболее пригодные для каждого конкретного случая.
JS тоже не люблю, но тоже часто использую.
Потому что шат ап и арбайтен, а не "люблю/не люблю". ))
N>Есть и другая инженерная база, которая говорит, что не надо без совсем уж безысходности требовать гайки на M3.1415926 или напильник с поперечным профилем циклоиды и разными насечками с разных сторон.
Но закручивать гайки, всё же, лучше гаечным ключом, а не плоскогубцами.
Пусть даже это очень клёвые плоскогубцы и вообще ты к ним привык как к родным.
N>Но ты эту инженерную базу почему-то игнорируешь в одном конкретном случае.
Наоборот, я утверждаю, что никакого одного конкретного случая не существует.
Питоноводы доказывают мне обратное — что любой случай сводится к одному. ))
V>>>>Вкусовщина. N>>>Просто сводный результат работы на всех них. В питоне меньше всего тупых граблей, через которые надо продираться, чтобы просто получить результат, посмотреть, как он добывался... V>>Меньше всего тупых граблей в этом смысле в Lua и VBS. V>>Это достаточно синтаксически строгие языки, в сравнении с JS/Ruby/Python. N>Как ты замечательно передёрнул, вдруг заменив тему на "синтаксически" строгие языки.
Ну ты же про "грабли".
В Lua и VB вообще никаких граблей прямо бай дизайн.
В VB и JS можно запретить использование необъявленных переменных.
Ну так-то потихоньку ковыряю Dart на досуге — он в этой дисциплине на голову выше всех и вся, должен признать.
Потихоньку, потому что он пока не кросссплатформенный.
В принципе, как только (когда и если) TS порвёт со своим JS бэкендом и станет самостоятельным языком c собственной ВМ, тоже будет крутой язык.
N>Хотя я вообще ни слова про синтаксис не говорил.
При чём тут ты?
N>Начинаю сомневаться, что ты на Питоне вообще что-то писал больше двух страниц
А надо писать больше на самом скриптовом из всех языков?
Рилли? ))
V>>Но в отсутствии систематизации и единообразия АПИ оно всё представляет из себя информационный мусор. N>И опять, разумеется, у тебя есть не менее 3 примеров конкретных областей. Но которые ты не покажешь.
Я покажу стандартную библиотеку Dart.
Вот где радующая глаз продуманность всего и вся.
Там учтены ошибки проектирования даже таких более-менее современных (в сравнении с Питоном) платформ, как дотнета.
На сегодня в природе нет скриптового языка чище, во всех смыслах.
N>>>>>Аналоги для компилируемых языков в виде мер "выгрузить целиком classloader или assembly, сериализовав состояние" не дают плавный незаметный переход. V>>>>Зато нейтивная COM-технология даёт. )) N>>>Кто тебе такое сказал? V>>Я тебе такое сказал и могу показать в трёх строчках на VB, не то что С++. N>Не можешь.
Легко.
Dim obj as SomeType = CreateObject(id, server)
Set obj = Nothing
...
Set obj = CreateObject(id, server)
Между второй и последней строчкой можно "на лету" заменить бинарник COM-объекта.
Причём, физически на диске подменять не надо, просто зарегить в реестре класс с тем же CLSID.
Ты просил — я показал.
Во второй строчке моего примера, еcли это была последняя ссылка, то бинарная либа выгрузится.
Если использована строгая типизация, то тут ограничение на сохранение интерфейса подменяемой на лету реализации.
А если использовать просто Object, то даже такого ограничения не будет.
N>Иначе сложно объяснить, почему ты даже в моём укороченном описании пропустил всё, кроме упоминания выгрузки.
Я не пропустил, я как раз показал, что "горячая замена кода" легко делается даже на нейтиве, т.е. не аргумент ни в одном из мест.
N>Ты же вместо этого предложил посмотреть на функцию, которая делает проверки типа "я ещё нужна?" изнутри библиотеки.
Потому что я верил, что ты, скорее всего, хотя бы краем уха слышал о такой функциональности, просто забыл в пылу спора — иначе бы не потребовал ссылок.
Но ты потребовал ссылки, чем и спалился, собсно. Вот я тебе и намекнул. ))
Здравствуйте, takTak, Вы писали:
T>фиг его знает, я Cake не пользую, но народ пишет, что
VSWhere надо ставить отдельно и прописывать path к нему.
Именно из-за этого в своих сборочных скриптах для дотнета я отказался от VSWhere, потому что тут не работает сценарий, когда другой разработчик "просто забрал код" с систеы контроля версий и тут же "просто запустил скрипт билда".
ага, а задокументированная бага становится фичей
V>Не используй nil, какие проблемы?
в том, что ты отмазываешься от очевидных фактов.
F>>>>у разных библиотек разные подходы. их нельзя сравнивать. V>>>Можно сравнивать внешний АПИ зато. F>>нельзя. V>У тебя забыли спросить.
а это ты с логикой поспорь.
впрочем, ладно. ты ж ней не в ладах
F>>вот где-где а в плюсах это очень заметно, когда язык позволяет сделать ну очень много вариантов апи. V>Речь не о разных парадигмах. V>А о том, что даже в рамках одной парадигмы устоявшегося подхода нет.
потому что ты его сделать не сможешь.
V>Ага. Тут можно начать с того, что создания объекта — это тоже вызов ф-ии.
нет. ты б хоть туториал посмотрел, не знаю...
за время твоего унижения питон можно выучить вдоль и поперёк.
V>Так что помешало в стандартной библиотеке принять единообразное решение — контейнеры будут создавать через вызов конструктора или через вызов ф-ии — фабрики?
удобство использования. ты когда про специальный синтаксис для создания списков и словарей узнаешь, наверное заплачешь
V>Эта фича была придумана для дефлотного экспорта, но в том модуле используется явный. V>Поэтому, не надо отмазок.
pip8 читай, там это и написано. плюс написано, что это значит.
про какой модуль ты тут распинаешься, я не в курсе.
Здравствуйте, vdimas, Вы писали:
V>- Возможность строгой типизации. V>- "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await. V>- Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов. V>- Явное наличие неймспейсов, операторы области видимости '::'. V>- Анонимные классы. V>- Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов). V>- Миксины, трейты, явное управление конфликтами: V>- Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах. V>Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально. V>PHP рвёт Python как тузик грелку по скорости исполнения кода. V>Причём, кто тут попытается что-то говорить (орать?) про CPython и Ко, пытаясь сравнивать их с референсной скриптовой реализацией PHP — лучше сравните их с любым популярным ускорителем PHP, все вопросы отпадут моментально.
схоронил в мемориз. выделю самое ржачное.
когда будет не хватать смеха, буду открывать этот пост и хохотать с эпичной глупости.
fail года
Здравствуйте, neFormal, Вы писали:
V>>- Возможность строгой типизации. V>>- "чистая" реализация генераторов в виде корутин, что этот механизм применяется напрямую как для итерации, так и для задач, где в C# или Питоне 3.6 используют костыли async/await. V>>- Абстрактный функциональный тип в языке, возможность описания произвольных своих функторов. V>>- Явное наличие неймспейсов, операторы области видимости '::'. V>>- Анонимные классы. V>>- Набор аргументов ф-ий можно рассматривать как один именованный тупл, т.е. оперировать им как единой сущностью (привет теориям типов). V>>- Миксины, трейты, явное управление конфликтами: V>>- Т.е. фактически прямой выход скриптового исходника на возможность его "честной" компиляции в нейтив, в отличие от полукомпиляции в проекте CPython и других уже умерших проектах-экспериментах. V>>Напротив, синтаксис PHP никакого флейма не вызывает, там всё чисто изначально. V>>PHP рвёт Python как тузик грелку по скорости исполнения кода. V>>Причём, кто тут попытается что-то говорить (орать?) про CPython и Ко, пытаясь сравнивать их с референсной скриптовой реализацией PHP — лучше сравните их с любым популярным ускорителем PHP, все вопросы отпадут моментально.
F>схоронил в мемориз. выделю самое ржачное. F>когда будет не хватать смеха, буду открывать этот пост и хохотать с эпичной глупости.
Хохотать тут можно только с неучей, дальше своего носа ничего не видевших.
Здравствуйте, vdimas, Вы писали:
F>>схоронил в мемориз. выделю самое ржачное. F>>когда будет не хватать смеха, буду открывать этот пост и хохотать с эпичной глупости. V>Хохотать тут можно только с неучей, дальше своего носа ничего не видевших.
Здравствуйте, neFormal, Вы писали:
V>>Это предопределённое поведение: F>ага, а задокументированная бага становится фичей
Не вижу баги.
Ты в своём питоне запиши в середину строки символ с кодом 0, подай такую строку в разные ф-ии — тоже получишь светошумовые эффекты.
V>>Не используй nil, какие проблемы? F>в том, что ты отмазываешься от очевидных фактов.
Ну вот я привёл тебе пример для Питона, начинай отмазываться.
Причём, отмазки я заранее знаю: "а зачем ты нарушил спецификацию строки"?
Тут аналогично — была нарушена спецификация списка.
F>>>вот где-где а в плюсах это очень заметно, когда язык позволяет сделать ну очень много вариантов апи. V>>Речь не о разных парадигмах. V>>А о том, что даже в рамках одной парадигмы устоявшегося подхода нет. F>потому что ты его сделать не сможешь.
Не я, а сообщество Питона.
Ввиду своего невысокого среднего уровня.
V>>Ага. Тут можно начать с того, что создания объекта — это тоже вызов ф-ии. F>нет.
Садись, два.
F>ты б хоть туториал посмотрел, не знаю...
Туториал по new?
Совсем за соломинку решил схватиться? ))
F>за время твоего унижения питон можно выучить вдоль и поперёк.
А толку, если тебе аргументировать всё-равно нечем?
Тебе задали конкретный вопрос:
Так что помешало в стандартной библиотеке принять единообразное решение — контейнеры будут создавать через вызов конструктора или через вызов ф-ии — фабрики?
А ты слил:
удобство использования
Хотя в реальности — по тем самым "по историческим причинам".
F>ты когда про специальный синтаксис для создания списков и словарей узнаешь, наверное заплачешь
На конкретный вопрос ответить не смог и быстренько побежал переводить стрелки подальше от неудобных вопросов.
V>>Эта фича была придумана для дефлотного экспорта, но в том модуле используется явный. V>>Поэтому, не надо отмазок. F>pip8 читай, там это и написано.
Букварь иди читай.
5-й раз не можешь понять, в чём было дело конкретно в том идентификаторе. ))
Т.е., про отличия дефолтного экспорта от явного ты не в курсе, получается.
RTFM!
F>про какой модуль ты тут распинаешься, я не в курсе.
Дык, открой соответствующий исходник на гит и ознакомься.
Здравствуйте, neFormal, Вы писали:
F>>>схоронил в мемориз. выделю самое ржачное. F>>>когда будет не хватать смеха, буду открывать этот пост и хохотать с эпичной глупости. V>>Хохотать тут можно только с неучей, дальше своего носа ничего не видевших. F>именно так!
Итого, подытожим.
В этой теме ты пытался отвечать десятки раз нескольким оппонентам, но не смог ответить ни на один конкретный вопрос.
От тебя исходят только междометия на фоне звуков полыхающего ануса.
Тут самое время сказать, что Питон, судя по всему, отупляет, но не буду, бо обобщать нехорошо.
Похоже, сей эффект случился только с тобой.
Здравствуйте, vdimas, Вы писали:
V>Ты в своём питоне запиши в середину строки символ с кодом 0, подай такую строку в разные ф-ии — тоже получишь светошумовые эффекты.
tst = "This is a \0 zero-\0containing\0\0 string"
print(tst)
print('\0' in tst)
print(tst.replace('\0', '!'))
Вывод:
This is a zero-containing string
True
This is a ! zero-!containing!! string
Здравствуйте, Cyberax, Вы писали:
V>>Ты в своём питоне запиши в середину строки символ с кодом 0, подай такую строку в разные ф-ии — тоже получишь светошумовые эффекты. C>
C>tst = "This is a \0 zero-\0containing\0\0 string"
C>print(tst)
C>print('\0' in tst)
C>print(tst.replace('\0', '!'))
C>
Здравствуйте, vdimas, Вы писали:
V>Ты пока подал в одну и ту же ф-ию.
def somebody_here_is_an_idiot(param):
res = ""
for s in param:
if s == '\0':
res += 'K'
else:
res += s
return res
tst = "This is a \0 zero-\0containing\0\0 string"
tst2 = somebody_here_is_an_idiot(tst)
print(tst2)
import re
print(re.split('\0', tst))
Вывод:
This is a K zero-KcontainingKK string
['This is a ', ' zero-', 'containing', '', ' string']
Здравствуйте, novitk, Вы писали:
T>>главный и единственный аргумент в пользу питона, который только все и называли — якобы скорость написания N>Вот 3 варианта на питоне:
Скорость разработки примерами показать сложно. Это не то же самое, что количество строк кода. Оно в некоторой степени кореллирует, но не линейно и не всегда. Перл, к примеру, очень лаконичный язык, позволяющий довольно много действий запихнуть в минимум строк кода. Но практически нечитаемый. "Write-Only" язык. Когда проще переписать, чем отрефакторить.
N>def f1(): N> counts = dict() N> for r in csv.reader(sys.stdin): N> counts[r[1]] = counts.get(r[1], 0) + 1 N> return counts.items()
Первый пример — самый читабельный. При минимуме знаний питона (а то и вообще без них) можно понять, что делает этот кусок кода. Конструкция "for ... in ..." любым опытным программером читается как одна логическая единица, усилий на разбор этой конструкции практически не требуется.
N>def f2(): N> return [(k, sum(1 for _ in v)) for k, v in groupby(sorted(r[1] for r in csv.reader(sys.stdin)))] N>def f3(): N> return Counter([r[1] for r in csv.reader(sys.stdin)]).items()
А вот эти две конструкции читаются хуже. Особенно f2(). Тут уже нужно знать особенности питоновских кортежей, чтоб понять, как оно там данные разбрасывает. И сходу можно и не заметить, что вы там на ровном месте сделали, как минимум, O(n log n) в алгоритме, который должен выполняться за O(n).
I was experimenting with the sqlite3 library and noticed that using certain strings as identifiers cause bus errors or segfaults.
...
the bug was only fixed in Python 3.2 and 3.3
Although VTK's Python wrappers do make the necessary methods available to Python scripts, they are not usable in their current form. This is because embedded NULL characters in input/output strings aren't correctly handled
И т.д. до бесконечности.
Багтрекеры сети завалены под завязку багами подобного рода.
И да. Обтекайте тщательнее, плиз, а то мне уже как-то с этим детским лепетом и спорить-то не спортивно. Задалбывает весь этот детсад на эмоциях.
Здравствуйте, vdimas, Вы писали:
V>И что тут именно питоновского, присущего ему как языку? V>Это просто либы, коих под другие языки тоже хоть попой ешь.
Задача абсолютно типичная, я ее специально под Питон не подбирал, решается за 2 минуты из коробки.
Какие библиотеки? csvparser? Ты хочешь сказать что в "суперпродуктивной" 4GL нет csv парсера и его надо делать из говна и палок?
В общем, когда-то, когда я еще давал Питону шанс для себя, вот как раз тогда появился string.Template, который выглядел интересно...
Так он у меня сразу же на этом и поломался.
Понятно, что потом пофиксили, но в Питоне вот так всегда.
Раком, боком, кое-как "доталкивают" мяч до ворот.
Выглядит это забавно, конечно.
Но в целом ущербно.
Здравствуйте, novitk, Вы писали:
V>>И что тут именно питоновского, присущего ему как языку? V>>Это просто либы, коих под другие языки тоже хоть попой ешь. N>Задача абсолютно типичная, я ее специально под Питон не подбирал, решается за 2 минуты из коробки.
Не из каробки, либы надо устанавливать.
Т.е. из целевой задачи мы переползаем на обсуждение удобства пакетных менеджеров.
N>Какие библиотеки?
Да любые.
В сети хватает решений на любые задачи в готовом для использования виде.
И разница тут опять и снова в "опакечивании" и ни в чём более.
===============
Для описанного достаточно однажды написать из нескольких строчек какой-нить import-хелпер, навскидку:
[Guid("AAAAAAAA-AAAA-AAAA-AAAA-AAAAAAAAAAAA")]
[ComVisible(true)]
public class Dotnet {
private readonly Assembly _assembly;
private Dotnet(string assemblyNameOrPath) { _assembly = Assembly.LoadFrom(assemblyNameOrPath); }
public static Import(string assemblyNameOrPath) { return new Dotnet(assemblyNameOrPath); }
[DispId(1)]
public object CreateObject(string type, object[] args = null) { return _assembly.CreateInstance(type, ..., args, ...); }
}
Использовать как-то так:
set ParserLib = Dotnet.Import("CsvParser")
...
set parser = ParserLib.CreateObject("CsvParser", "|")
for each s in parser.Parse("aaa|bbb")
WScript.StdOut.WriteLine s
next
