Ну а зачем добавлять? Тебе хочется вообще в принудительном порядке использовать эти методы извне? В случае со свободным ПО наглухо запретить вообще не получится. А нужно хочешь показать, что эти переменные/функции/свойства не нужно вызывать извне, т.к. это может привести к плохим результатам, то этого будет достаточно.

чем тебя gevent не устроил?

Нельзя использовать свой «реактор». Т.е. напрямую greenlet.Greenlet.switch() делать явно запрещено докой ибо чревато.

Другая проблема: есть проблемы с вызывом C API из-за манипуляций со стеком. Я пару месяцев назад писал что это брехня и проблема надуманная. Похоже что я был не прав. Не помню в какой момент я сел в лужу. Возможно, это было при попытке соединить cython-овые обвязки с gevenet.

Кстати, в py3k готовят закоммитить поддержку вложенных генераторов и куски twisted-подобного реактора. Только это всё полумеры которые ни разу не замена gevent.

Тыканьем пальцем наугад в один из хорошо известных программисту ЯП :)

Ну так это тот же самый «выбор ЯП», только с более «свободным, неформальным» критерием выбора. :)

Нужные библиотеки/расширения/фреймворки с большой вероятностью существуют.

Я бы даже сказал: точно существуют. И вот именно поэтому я продолжаю «выбирать ЯП под задачу».

И чем они помогут?

Тем что их случайно не переопределят. Для меня это пока самая большая проблема при глубоком и множественном наследовании (я знаю что это нехорошо).

Я согласен с тем что это не самое удачное решение и в рамках текущей реализации питона (когда виртмашина захардкодена) это невозможно.

Ну а зачем добавлять? Тебе хочется вообще в принудительном порядке использовать эти методы извне?

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

Вы такой умный мущщина.

> А те кто действительно поддерживают свои приложения уже портировали код на py3k.

Ну вот гугль только недавно с большим скрипом проапдейтил свой appengine до 2.7. А над ним, между прочим, сам Гвидо работает.

Самый популярный веб-фреймворк - джанга - твердо стоит на второй ветке, и никто не собирается в ближайшем будущем ее портировать на 3.

Это лишь два примера очень хорошо поддерживаемых и активно разрабатываемых фреймворка на питоне.

С графическими тулкитами как? qt вроде сделало биндинги для третьего питона, а другие как?

Кстати, тот же Дийкстра и о басике высказывался нелицеприятно, насчет безнадёжно испорченных мозгов студентов, его изучающих.

Спорно. Меня учили программированию впервые именно на Бейсике. Восьмилетнему пацану, впервые увидевшему PC, разобраться даже в Паскале будет трудно с непривычки.

А на Бейсике мне умудрились в короткий срок преподать основы алгоритмов, декомпозиции и пользования справочной системой. Достаточно, чтобы освоить самостоятельно Паскаль и Си, для начала.

И пока никто на мои безнадёжно испорченные Бейсиком мозги не жаловался.

Да, бейсик наше всё, сортировака пузырьком - основа.

И вот именно поэтому я продолжаю «выбирать ЯП под задачу».

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

очень хорошо поддерживаемых и активно разрабатываемых фреймворка на питоне.

Тут ты загнул. Я о джанге не по наслышке знаю и много ковырялся с ней и в ней. У проекта очень серьёзная нехватка рук итд итп. Баги годами висят.

и никто не собирается в ближайшем будущем ее портировать на 3.

Куча попыток была. И обсуждений тоже навалом. Как щас не знаю, но я учавствовал в этом обсуждении в списке рассылки. Потом забил потому что джанго прибитое гвоздями УГ и себе сайтик переделал на bottle.py. Только давай не будем это обсуждать, уже сто раз в Web Development с baverman и другими «альтернативщиками» (т.е. теми кто юзает pyramide, werkzeug, pylons, web.py итд итп) обсудили :)

с большим скрипом проапдейтил свой appengine до 2.7

А как же хвалёная совместимость со старым кодом? Ты же писал что всё легко поддерживается? Ох не зря я писал что даже с py2 кодом много возни.

Именно поэтому люди и пользуются более высокоуровневыми средствами когда можно поступиться с производительностью.

И почему тогда сложные программы не пишут на самом примитивном и простом диалекте басика?

потому что сложность и производительность - термины обозначающие разные понятие

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

та же фигня. Бейсик -> паскаль -> C -> дельфи -> кресты -> питон.

питона стало не хватать

O_o конкретнее можно, пожалуйста?

мифы про сложность работы с указателями и выделения/освобождения памяти в C/C++ несколько преувеличивают эти самые сложности

но сложности есть, тут нет возражений? и это сложности не с самими указателями, а сложности с возрастающей сложностью

Про басик - это моё личное, давно и глубоко укоренившееся мнение. С Дийкстрой полностью согласен. На басике ничего никогда не писал, но смотрел достаточно много исходников и один раз наблюдал (в течение двух месяцев), как на нём решается конкретная задача.

Я начинал с С. Теория и практика параллельно. В жёстком режиме.

И пока никто на мои безнадёжно испорченные Бейсиком мозги не жаловался.

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

Приватные данные нужны тогда, когда один программист предоставляет другому свои интерфейсы.

может не стоит лезть со своим уставом в чужой монастырь? просто почитайте как это делается в конкретном ЯП

Ну я уже писал что мне хотелось бы иметь gevent-like вичи в самом питоне вместе с доступом к «реактору».

Ну и ещё куча вещей которые я щас не вспомню потому что конкретно засел с AIO. Ну и не просто так в мире существует много языков программирования помимо питона. Не всё на питоне делается легко и красиво.

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

то есть если поля было бы нельзя переопределить - они были бы ненужны? :)

О боже, представляете, в Си вы можете напрямую обращаться к памяти!! МЫ ВСЕ УМРЕМ!!!

python ... ООП там IMHO, кривоватое

wat-wat-wat? мсье пуританин?

то есть если поля было бы нельзя переопределить - они были бы ненужны? :)

харош издеваться, ты всё понял :). Могу даже привести конкретный пример когда мне это понадобилось. В целях экспериментов я делал общую прослойку которая позволяла бы переключаться с gevent на threading или multiprocessing (не на лету конечно). Так вот было неприятно что многие имена типа start(), run() status() итд были уже заняты :(. Я понимаю что не бог весть какая проблема, но неприятненько. Вот если бы их можно было «скрыть»...

В Питоне нет контроля доступа к полям и методам.

можно подумать в «сишечке» нельзя полазать по всему чему только хочется

Выбор языка под задачу имеет смысл тогда, когда языки сильно различаются.

Да. Кто-то возражает?

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

Значит, я следую «желанию своей левой пятки». Для специфического поиска в своём барахле в home пишу скриптик на bash, для аналогичного поиска, но предназначенного для слабо подготовленного пользователя, пишу программку на питоне с гуем (или ещё на чём-то аналогичном), а сервер для локалки на 5-6 клиентов пишу на С. Вот такая у меня капризная левая пятка. :)

в Си вы можете напрямую обращаться к памяти

Это как однополый секс, некоторым, говорят, нравится.

потому что сложность и производительность - термины обозначающие разные понятие

За роль К.О. - 5 баллов.

Но по треду можно было бы и чуть повыше подняться.

можно подумать в «сишечке» нельзя полазать по всему чему только хочется

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

Ну я уже писал что мне хотелось бы иметь gevent-like вичи в самом питоне вместе с доступом к «реактору».

так, тебе шашечки или ехать? иди от задачи, а то сейчас - это выглядит - хочу в питоне синтаксис как в паскале

Могу даже привести конкретный пример когда мне это понадобилось. В целях экспериментов я делал общую прослойку которая позволяла бы переключаться с gevent на threading или multiprocessing (не на лету конечно). Так вот было неприятно что многие имена типа start(), run() status() итд были уже заняты :(. Я понимаю что не бог весть какая проблема, но неприятненько.

use dependency injection, Luke, not subclassing

так, тебе шашечки или ехать?

эм, кажется ты не понимаешь что я хочу. Я хочу reactor pattern заимплементить вместе с gevent (потому что этот паттерн чрезвычайно хорошо ложится на задачу (или наоборот?)). Прямых путей для этого я не вижу. В сторону twisted попрошу не посылать по причине того что в сравнении с gevent оно со своими коллбэками выглядит... ну как далёкий привет из прошлого, кмк. Хотя надо будет ещё раз по докам пройтись, ВДРУГ там всё совсем не так как я помню.

можно подумать в «сишечке» нельзя полазать по всему чему только хочется

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

конечно, но это для сирых рассудком, настоящих «хацкеров» такие мелочи не остановят

но сложности есть, тут нет возражений? и это сложности не с самими указателями, а сложности с возрастающей сложностью

Ну, разумеется же. Разве не очевидно?

Можно с указателями разумно работать, и сложностей практически не будет. При условии усвоения материала из K&R, о котором я уже говорил.

А можно наворочать и так:

[ 22:34:26 ]$ cat ptr_mix.c 
#include <stdio.h>

char *c[] = { "ENTER", "NEW", "POINT", "FIRST" };
char **cp[] = { c+3, c+2, c+1, c };
char ***cpp = cp;

int main()
{
  printf( "%s", **++cpp );
  printf( "%s ", *--*++cpp+3 );
  printf( "%s", *cpp[-2]+3 );
  printf( "%s\n", cpp[-1][-1]+1 );
  return 0;
}
[ 22:34:34 ]$ gcc -o ptr_mix ptr_mix.c 
[ 22:34:50 ]$ ./ptr_mix 
POINTER STEW
[ 22:34:56 ]$

и до-олго смеяться над теми, кто подобные кучи г@&на будет потом разгребать.

Это все равно не спасет от memcpy или memset :)

use dependency injection

К этому и прихожу. Только как это противоречит моим словам? Я сказал какой фичи мне не хватает. Костыли не вдохновляют.

настоящих «хацкеров» такие мелочи не остановят

Всем пох на настоящих хацкеров.

java-интерпретатор/компилятор(Jython). Благодаря использованию Jython вместо CPython удаётся достичь большей производительности, так как виртуальная машина Java (Hotspot JVM) выполняет динамическую компиляцию (JIT-compilation) байт-кода в исполняемой код целевой платформы, в отличии от CPython, который интерпретирует собственный байт-код. В результате чего появляется возможность одновременного использования классов и библиотек языков Java и Python.

Это все равно не спасет от memcpy или memset :)

ДА ТЫ ШТО?!!!111

В си бывает ошибешься на 1 индекс массива и получаешь сегфолт примерно на каждый 16й запуск в разных местах. А еще разница между отладочной и релизной сборкой может сюрпризы подкинуть, если где-то какая-то неточность с инициализацией полей. Может помочь статический анализатор, valgrind, но в java, например, эти ошибки просто невозможны.

Для себя мелкие инструменты на скале, использую как функциональную яву. Питон не нравится динамической типизацией (при быстрой разработке без проектирования это ужас). Но я 95% времени пишу под телефоны, там как раз акцент на скорость.

Я хочу reactal pattern заимплементить себе в gevent

fix

бедная бедная великая и могуча русская языка.

> так, тебе шашечки или ехать?

эм, кажется ты не понимаешь что я хочу.

не понимаю, по моему ты и сам не понимаешь

Я хочу reactor pattern заимплементить вместе с gevent (потому что этот паттерн чрезвычайно хорошо ложится на задачу (или наоборот?)).

это исследовательская задача, не практическая - исследуйте, но не жалуйтесь, что нет «кнопки»

и да, что в gevent не устроило?

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

> use dependency injection

К этому и прихожу.

ну вот, «отлична-отлична» (с) :)

Я сказал какой фичи мне не хватает. Костыли не вдохновляют.

you doing it wrong, делай правильно и проблем не будет

Всем пох на настоящих хацкеров.

это так вначале кажется, потом их код поддерживать - адъ и содомия

В си бывает ошибешься на 1 индекс массива и получаешь сегфолт примерно на каждый 16й запуск в разных местах. А еще разница между отладочной и релизной сборкой может сюрпризы подкинуть, если где-то какая-то неточность с инициализацией полей. Может помочь статический анализатор, valgrind, но в java, например, эти ошибки просто невозможны.

В целом всё верно. Java, конечно, более строго такие вещи контролирует. Нас, сишников, так не пасут. :) Но я от подобного рода ошибок избавился уже достаточно давно. Выработалась уже дисциплина в этих нюансах.

Но Java я знаю на уровне helloworld и tic-tac-toe. :) Поэтому пользоваться её достоинствами не могу.

> А как же хвалёная совместимость со старым кодом?

appengine очень замороченная штука сама по себе. Я не особо рад что с ней связался вообще.

выстрелить себе в ногу можно даже Аду упросить.

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

и да, что в gevent не устроило?

ты издеваешься? Я же написал что мне надо свой обработчик событий. Как мне ещё яснее написать? А писать «you're doing it wroing» или «это исследовательская задача» и я умею.

Покопаю в сторону расширения Hub()

Всё равно не понимаю в чём могли быть трудности портирования. Интересно посмотреть на изменения. Они публично доступны?

Логопед напоминает

Ученого зовут [ˈɛtsxər ˈwibə ˈdɛɪkstra], по-русски пишется Дейкстра.
Слушать здесь: http://upload.wikimedia.org/wikipedia/commons/8/85/Dijkstra.ogg

//Или это нынче шутят так, а я не знаю?

Си?