>Да, печальная ситуация с базами для Python вырисовывается
Да почему же,
я вообще-то DBA,
честно говоря я и питон то пользую в основном
с Oracle,
очень комфортно и портатил я всего пару часов на разборку
с драйверами, а дальше работаю и не жужжу

а какие проблемы собственно?

Netcraft: Top providers running FreeBSD

В perl есть механизм, который делит данные на чистые и грязные, Это как?

perl -T

Ну если данные пришли например из окружения, то некоторые

вызовы типа exec, system, rm, mkdir с ними запрещены,

Их нужно сначала очистить через regexp

>а какие проблемы собственно?
Когда только с Oracle работать, так вопросов нет. Вон сколько возможностей.
Хуже, когда надо более универсальное решение (ODBC, ADO, JDBC, в конце концов) под любую платформу. В таких случаях печально узнавать, что все внешние модули - сторонние, часто - беты, и иногда надо деньги платить (особенно под линухом).
Лучше бы в питон была штатно встроена хотя бы поддержка ODBC или JDBC или "PyDBC" с возможностью использования существющих драйверов.
Как, например, в Delphi. Есть BDE и в принципе в общем случае этого достаточно (хотя в дальнейшем часто приходится переходить на специально заточенные драйвера)

2 anonymous (*) (2003-07-16 14:24:18.208832)

Есть java-версия питона -- Jython -- которая работает поверх jvm; туда можно прозрачно импортировать java-классы, в том числе все что касается jdbc. Если вам требуется именно jdbc имхо идеальный вариант.

А по большому счету действительно, поддержка современных "enterprise" технологий в питоне не самое сильное место, так как если соответствующие пакеты есть, то поддерживаются отдельными разработчиками, а не крупными огранизациями. В полной мере ощутил это на своей шкуре, когда искал средства WSDL/SOAP -- что-то есть, как-то работает, но реализация не полная и разные части от разных разработчиков объединить тяжело.

Хотя казалось бы в этих технологиях свойства питон рулят.

> Блин, ну ребята, вы хоть думайте когда пишите! Стыдно за вас, честное слово. _Изначально_ мною было сказанно, что именно такой: >perl -e 'my %a=();while(<>){$a{$_}++;}print sort keys %a;'

Основные ошибки этого решения: _весь_ файл загоняется в хэш в памяти, _весь_ файл тут же загоняется в массив в памяти и тут же сортируется. Перерасход памяти дикий: тот, кто так обрабатывает файл длиннее 1000 строк - на perl программировать _не_умеет_.

Правильное решение - связать хэш с DB_File в варианте BTREE, засунуть в него данные (модуль DB_File озаботится о _разумном_ кешировании) и вывести хэш _перебором_ (each) безо всяких keys (сортировка не нужна, т.к. ключи в BTREE уже отсортированы).

> А sort | uniq сделал свою работу примерно за 20 сек. без нагрузки на память и CPU. и никакой DB_File не спасет Perl, курите доку на DB_File.

Курите книги по perl. Для начала рекомендую "Perl Cookbook"

XFree86 for FreeBSD/amd64

Курите книги по perl. Для начала рекомендую "Perl Cookbook"

Перерасход памяти дикий: тот, кто так обрабатывает файл длиннее 1000 строк - на perl программировать _не_умеет_.

Поучи отца еб..cя

Решение с tie было предложено с самого начала.

Покажи код с DB_File в одну строчку :)

А затем time твой код на файле 162 метра

Извините отец sun-ch, но это сообщение было не вам, а Korwin'у.

> Покажи код с DB_File в одну строчку :)

Не могу :)

> А затем time твой код на файле 162 метра

Ты видел мой код? Где?

Ну и time _твой_ код на файле в 162 метра на машине с 32 метрами мозгов.

>>Хуже, когда надо более универсальное решение (ODBC, ADO, JDBC, в >>конце концов) под любую платформу.
Под win32 есть ODBC и ADO.
>>В таких случаях печально >>узнавать, что все внешние модули - >>сторонние, часто - беты, и иногда надо деньги платить
>> (особенно под линухом).
Ну за DELPHI тоже вроде бы надо платить

>>Лучше бы в питон была штатно встроена хотя бы поддержка ODBC или >>JDBC или "PyDBC" с возможностью использования существющих драйверов.
>>Как, например, в Delphi. Есть BDE
BDE уже нет так, как он поставляется только для обратной
совместимости со старыми версиями и там скорее всего уже никогда не будет поддержки например Oracle 9 release 2. Так что код, написанный для BDE уже начал стремительно устаревать.
>> и в принципе в общем случае этого >>достаточно (хотя в дальнейшем часто приходится переходить на >>специально заточенные драйвера)

Я очень далек от шапкозакидательства по поводу применимости питона в неизвестном мне проекте.
Я могу отделаться только общими фразами про
риски и инвестиции в IT проектах.
Они существуют и при покупке(и даже воровстве) программных продуктов.
Вы становитесь заложником политики тех компаний, у которых вы купили
(или украли) технологии.
Некоторые исследования показывают, что при грамотном менеджементе,
и правильном инвестировании риски при использовании Open Source
могут быть существенно снижены.

Пример для вас специально. Вы нуждаетесь в драйверах для доступа к
БД. Исходные тексты вам доступны, скорее всего доступны и разработчики.
Сложность этих драйверов крайне незначительна, и они могут быть
в короткий срок доведены до ваших требований.
1)вы можете получить бесплатный support у автора кода,
2)вы можете заплатить автору кода,
3)вы можете вести свою ветку драйверов и даже брать за нее деньги .

Я очень сильно сомневаюсь, что вам действительно нужна поддержка
более чем 1-2 СУБД.
Если она Вам нужна, то у вашей компании должны быть
колоссальные денежные и интеллектуальные ресурсы на паралллельную разработку.

"К сожалению сам стандарт(как в свое время и cпецификация на ODBC) не может учесть все специфические особенности конкретной СУБД, так как фирмы-производители СУБД, используют свои фирменные расширения как средство в конкурентной борьбе. Поэтому перенос кода с одной платформы на другую все-таки очень трудно сделать безболезненным, если только перед разработчиками не ставилась задача писать приложения, предназначенное для работы с различными SQL серверами."
Это цитата из меня.

"Несмотря на существавание стандартов на язык SQL, реальные потребности часто требуют использования нестандартных средств
сервера(более того, написать приложение, работающее с сервером на стандартном SQL возможно только для весьма тривиальных приложений )"
Это вторая цитата из меня.

>>>А что такое корпоративный кодинг

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

>>>и чего тут питон не может, а java может?

С Java процесс описанный выше происходит УСТОЙСЧИВЕЕ. В частности из-за возможности разделить роли разработчиков: одни делают core, другие - используют его для решения частно-конкретных задач. Управление видимостью-наследуемостью в коде очень помогает в таких (больших) проектах.

>>>Типизация и статичность классов не являются гарантией правильности прикладного кода. все равно тестировать надо,

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

>>>все-таки есть возможность сокрытия имен в модуле или классе,но это не замок,а скорее щеколда от случайной порчи.

В Питоне её нет принципиально. То что есть, годится как раз для мелкого скриптига в условиях полного доверия.

>>>системы безопасности [в Java]

Позволено использовать открытые методы-классы и не дать доступа к закрытым не только в рантайме и не только юзерам, но и ПРОГРАММЕРАМ, которые делают свою часть работы в рамках совместного девелоппинга. В Java это делается начиная с уровне исх. кода, а не только административными методами.

>> Java процесс описанный выше происходит УСТОЙСЧИВЕЕ.
>> В частности из-за возможности разделить роли разработчиков: одни >>делают core,...
imho, а так ли это важно, практика показывает, что
на java получаются(и довольно часто не получаются вообще) очень раздутые, дорогие для разработки и сопровождения системы(из-за сложности и существенных недостатков языка).
Как там IBM San Francisco чем закончился?
Это при том, что у IBM довольно хорошие корпоративные традиции
написания софта.
К тому же java также разрабатывалась как "язык для бытовой техники"


>>>все-таки есть возможность сокрытия имен в модуле или классе,но это не замок,а скорее щеколда от случайной порчи.
>>В Питоне её нет принципиально. То что есть, годится как раз для >>мелкого скриптига в условиях полного доверия.
А это что?:

>>> class myclass:
... def __print_hello(self):
... print "hello"
... def print_again(self):
... print "hello again"
...
>>> a=myclass()
...
>>> a
<__main__.myclass instance at 0x016497B0>
>>> a.__printhello()
Traceback (most recent call last):
File "<interactive input>", line 1, in ?
AttributeError: myclass instance has no attribute '__printhello'
>>> a.print_again()
hello again

IMHO вполне достаточно для надежного кодирования.
То же самое можно сделать и с переменными,
причем и на уровне описания класса и на уровне модуля.
А реализация всяких private methods насколько я помню объяснялась как
желание скрыть детали реализации при продаже компонентов .

>>Насчет тестирования нет никаких возражений, а вот типизация >>позволяет приводить к недопупщения определенного класса ошибок ещё >>при компиляции.
На slashdot были интервью с Гослингом и Ван Россумом,
у них там разные точки зрения на это дело,
я бы сказал так:
что возможность снизить издержки на кодирование,тестирование и сопровождение,
может оказаться важнее типизации,ведь объем исходного кода
сократится в 2-3 раза, его ведь проще оттестировать будет.
К тому же обработка ошибок в python, очень надежная и почти всегда
можно получить довольно подорбную информацию при exception.

наверное нужно было вызвать __print_hello?:

>>> a.__print_hello()
Traceback (most recent call last):
  File "<pyshell#18>", line 1, in ?
    a.__print_hello()
AttributeError: myclass instance has no attribute '__print_hello'
>>> a.print_again()
again
>>> dir(a)
['__doc__', '__module__', '_myclass__print_hello', 'print_again']
>>> 

>>>на java получаются(и довольно часто не получаются вообще) очень раздутые, дорогие для разработки и сопровождения системы

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

>>>(из-за сложности и существенных недостатков языка)

Java - простой язык, специально задуманный для написания приложений, в том числе и встраиваемых (но это касается не ЯЗЫКА, а его RUNTIME - то есть JVM), несмотя на разные маркетинговые вихляния. Байки про кофеварки вообще недостойны серьёзного рассмотрения - см. проект "Oak". А на сегодняшний день устройств с JVM внутри уже продано не менее 100 000 000 штук.

Сложным же является процесс ПРОЕКТИРОВАНИЯ жизнеспособных решений. Насчет "cущественных недостатков" флеймы закончились года четыре назад - за отсутствием аргументов у противных сторон. Может появились новые недостатки за это время - дайте посмотреть :)))

Насчет примера - попробуй сделать так:

a._myclass__print_hello()

и увидишь своё hello...

Для некоторых случаев такого (визуального) сокрытия достаточно - для остальных НЕТ. Тем более что нужно не только сокрытие, но и управление видимостью. Да и секурити в java этим далеко не исчерпывается...

Питон - очень хороший язык и явщикам он очень нравится. А если питонисту не подходит ява - то он скорее всего чего-то ещё не понял.

И все-таки, мне не совсем ясно, когда наличие private является жизненно необходимым? Для защиты архитектуры от кодеров? При разумном проектировании проиллюстрированного выше механизма python достаточно для инкапсуляции реализации внутри класса. При работе нескольких кодеров его должно быть также достаточно, плюс описание интерфейсов и запрет на вызов методов _myclass__print_hello (имхо проверку отсутствия таких вызовов можно реализовать даже в виде скрипта на том же питоне)

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

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

>>> Java - простой язык, Уж слишком простой... Не намного сложнее VB. Нету ни деструкторов, ни шаблонов (только не надо мне приводить ссылок на их реализацию, я их знаю - это хаки, а не языковая архитектура), нету типов данных высокого уровня, нету функционального программирования. Нету ничего, чего имеют современные языки. Java - попытка масштабировать байткод для кофеварки на весь реальный мир. Причем, архитектурная убогость Java, как мне кажется, идет не от некомпетентности Гослинга, как инженера, а от попыток снизить кривую языка до уровня ОЧЕНЬ среднего программера (где вы найдете столько гениев бизнес-приложения писать???).

>>>специально задуманный для написания приложений, в том числе и встраиваемых

Вы MIDP видели? Я - видел. И писал. Редкосная убогость. И это при том, что Pippy преспокойно крутится на том же девайсе без всяких ограничений.

>>>А на сегодняшний день устройств с JVM внутри уже продано не менее 100 000 000 штук.

Это одна из немногих его достоинств.

>>>Сложным же является процесс ПРОЕКТИРОВАНИЯ жизнеспособных решений. Во-во, это точно. Особенно сложным является попытка улететь в открытый космос на кукурузнике 50-летней давности. Жизнеспособные решения работают только на жизнеспособной базе. Я понимаю, Java - жизнеспособное решение, поскольку на него завязан крутой бизнес, но если бы в SUN работал не Гослинг, а Гвидо, то неизвестно что бы еще произошло.

>>> Насчет "cущественных недостатков" флеймы закончились года четыре назад - за отсутствием аргументов у противных сторон. Вы думаете? Может быть просто люди устали играть в донкихотов и воевать с кофеварками?

>>>Может появились новые недостатки за это время - дайте посмотреть :)))

Так еще старые не пофиксили...

>>>Насчет примера - попробуй сделать так: >>>a._myclass__print_hello() >>>и увидишь своё hello...

И чего?

>>>Для некоторых случаев такого (визуального) сокрытия достаточно - для остальных НЕТ.

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

>>>А если питонисту не подходит ява - то он скорее всего чего-то ещё не понял.

Согласен. Питонист никак не может понять, нахрена попу гормонь (языковой downgrade).

>>>А если питонисту не подходит ява - то он скорее всего чего-то ещё не понял.

последнее время ява вызывает странное ощущуение, что вроде это хороший грамотный язык, только писать надо не на нем, а на каком-то другом языке из которого потом генерится java-код. впрочем лучше даже не писать, а именно проектировать. хороший пример - jsp. или beans - глупо ведь писать все эти getXXX setXXX вручную, это должен желать робот.

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

В java-application ни пользователь, ни (что важно) другой программист не могут вызвать-перегрузить-унаследовать приватные классы (или их закрытые методы) обеспечивающие безопасность в приложении, а значит не могут и обойти предписанную процедуру. При этом не надо прятать сам код секурной части от другого кодера (или бояться его декомпиляции) - взлом или случайное нарушение возможны только путем _подмены_ класса в рантайме - а это уже другая история...

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

а как можно использовать возможность наследования какого-либо критичного класса? пусть скажем у меня спрашивают пароль:

....
login,password = get_user_credentials()
if not check_auth(login,password):
   print "denied"
   raise AuthError
else:
   print "helo"
....

что я получу, перегрузив check_auth,
ведь класс с перегруженным методом еще нужно будет как-то передать в рантайм?

>Уж слишком простой... Не намного сложнее VB.

Java даже намного проще чем VB ;) Но позволяет решать такие задачи, которые пользователям васиков умственно непосильны. И кстати, VB надо сравнивать не с явой, а с Питоном - у них больше область сравнимых характеристик.

>Нету ни деструкторов, ни шаблонов

Первое - by design, почему так сделано - многократно объяснено, если непонятно - то это конкретные мозговые трудности.

Второе появилось по просьбам общественности и отнюдь не как хак - пользоваться можно уже сейчас, официально в спецификацию и jvm войдет с 1.5.

>нету типов данных высокого уровня, нету функционального программирования

Уровень типов соответсвует уровню языка - существует ведь и сверхвысокий уровень, а мы ведь о банальном - midware, enterprise apps :) FP тоже не отностся к мейн-стриму в данной области, может оно и плохо, но это так.

>Нету ничего, чего имеют современные языки.

Надо сравнивать с подобным. А что такое "современный" - ЧТО было изобретено ПОСЛЕ Oak?

>Java - попытка масштабировать байткод для кофеварки на весь реальный мир... архитектурная убогость Java

Скока нервов... Это всего-лишь программирование. Вам не нравится ява - пользуйте аду или хаскель или что-то ещё. Мы же вообще-то про Питон здесь толковали.

>снизить кривую языка до уровня ОЧЕНЬ среднего программера (где вы найдете столько гениев бизнес-приложения писать???)

"Кривую языка" - это надо будет запомнить... Декларируемой целью некоторых решений в яве было создание инструмента повышенной надежности, а не средства для дебилов. Ясно, что в программировании это является только идеалом и поэтому инструмент таки вышел кораздо сложнее отвертки (ВизальВасика, к примеру)

>И это при том, что Pippy преспокойно крутится на том же девайсе без всяких ограничений.

А forth будет еще спОкойнее крутиться... ну и шо? Исчо можно в кодах писать ...

>Это одна из немногих его достоинств.

Это серьезное достижение. И маркетинговое, и техническое-технологическое. Ничего сравнимого больше ведь и нет.

>Java - жизнеспособное решение, поскольку на него завязан крутой бизнес

Ну да. Причем число открытых явских решений и возможностей для собственной профессиональной или бизнесовой деятельности просто несоразмеримо с тем, что дают "технологии M$" - даже те, что растут от явского корня. Это плохо?

>Может быть просто люди устали играть в донкихотов и воевать с кофеварками?

Те кто воевал с кофеварками так с ними и воюют, дурачки. Остальные зарабатывают с JBoss и Compiere (и на остальном с jakarta.apache.org - это только открытая часть айсберга ;)

>>Насчет примера - попробуй сделать так: a._myclass__print_hello() >>>и увидишь своё hello...

>И чего?

Полагаю, тот, кому отвечалось, понял "чего"...

>Привидите пример, плз.

См. в моём предыдущем посте.

>Питонист никак не может понять, нахрена попу гормонь (языковой downgrade).

Умный поймет. Объяснять дураку - только время тратить.

>>>что я получу, перегрузив check_auth,

Переопределение check_auth(...) позволяет выполнить код в "защищаемой" ветке без всякой аутентификации.

> Переопределение check_auth(...) позволяет выполнить код в "защищаемой" ветке без всякой аутентификации.

вы о джаве или о питоне?

в питоне -- согласен, если я у данного экземпляра заменю метод проверки пароля, так и будет. но это несколько отличается от наследования/перегрузки.

в джаве -- подменить метод данного instance на ходу нельзя, и мне не понятно что делать с унаследованным исправленным классом. Или речь идет о том, что все приложение и есть этот самый класс, и я сам его создаю? Тогда что мне мешает вместо наследования декомпилоировать/исправить?

короче, нужно более полно описать задачу, так все это неочевидно.

>>>последнее время ява вызывает странное ощущуение, что вроде это хороший грамотный язык, только писать надо не на нем, а на каком-то другом языке из которого потом генерится java-код. впрочем лучше даже не писать, а именно проектировать. хороший пример - jsp. или beans - глупо ведь писать все эти getXXX setXXX вручную, это должен желать робот.

Правильно. Только в этом нет ничего странного - приложения и нужно _проектировать_ а не кодить, начиная от Тьюринга!

Язык программирования Java описывается в документике страниц на 150 (с примерами и рассуждениями). А дальше - начинаются Технологии, в том числе и такие, где существенные части приложения можно не программировать, а просто описывать.

Пытливому уму здесь есть над чем подумать - почему такое оказалось возможно и получилось с Явой, а не с Питоном, например...

>>>вы о джаве или о питоне?

А по синтаксису не видно?

>>>в питоне -- согласен, если я у данного экземпляра заменю метод проверки пароля, так и будет. но это несколько отличается от наследования/перегрузки.

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

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

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

>во-первых синтаксис был мой, и я написал тем синтаксисом каким короче.

Вопрос с примером был не твой, пример был на питоне, отвечалось на него и тоже про питон и в питоновском синтаксисе. Где не понятно?

>где все это возникает... когда реализация части кода в виде private метода не позволяет эту функцию обойти.

Приведи пример обхода для Java :)

>во-первых синтаксис был мой, и я написал тем синтаксисом каким короче.

> Вопрос с примером был не твой, пример был на питоне, отвечалось на него > и тоже про питон и в питоновском синтаксисе. Где не понятно?

я о своем посте (2003-07-18 18:35:58.922272).

про то как обойти питоновскное сокрытие "__"-методов мне совершенно не интересно, и я нигде не утверждал что __ это аналог private.

>где все это возникает... когда реализация части кода в виде private метода не позволяет эту функцию обойти.

> Приведи пример обхода для Java :)

декомпилирую все, правлю что нужно, собираю обратно. обошел?

или давай пример кода на java + условия выполнения + что будет плохо если private сменить на public. до сих пор я не вижу приверов кроме глупого кодера который вместо person.getAge() пишет person.age

Про _аналог_ private в pythone. А что, closures в нем разве нет?

>декомпилирую все, правлю что нужно, собираю обратно. обошел?

Нет. Потому как речь идет не о защите КОДА приложения, а о защите (корпоративных) ДАННЫХ, которые в приложении крутятся.

Декомпилировать не надо - исходный код всего ява-приложения от тебя никто не прячет (об этом упоминается здесь не в первых раз ;). Писать, деплоить и исполнять свои добавки к данному приложению тоже позволено, но вот если ты физически не можешь подменить код классов, отвечающих за безопасность _работающего_ приложения - то тебе не добраться до данных, доступ к которым БЕЗ процедуры авторизации скрыт в приватных методах.

в свою очередь и тоже не в певый раз повторюсь - опиши ситуацию подробно: приложение, данные до которых мы хотим добраться, код обеспечивающий безопасность, и наконец - каким образом можно получить защищенные данные если сменить private на public у одного-единственного метода!

или речь идет о вызове private методов, предоставляюющих доступ к данным, которые иначе вызываются только после аутентификации?
тогда при чем здесь наследование и переопределение метода аутентификации?

Сам же можешь понять - чего элементарные вопросы-то задавать?

Метод возвращающий искомые данные можно вызвать напрямую, если он открыт-известен, если нет - можно класс авторизации унаследовать и переопределить метод делающий проверку. Всё это возможно, когда они не строго приватные.

В питоне же ничего приватного объявить нельзя и всё всегда открыто - поэтому устроить ограничение доступа внутри одного приложения (точне - одного рантайма) принципиально невозможно - а это очень даже желательная фича при программировании бизнес-приложений, да и не только их. С этого утверждения всё и началось много постов назад.

speer, вместо private методов в Python можно пользоваться тем, что в Perl называют "closure". В ruby, кстати, та же ситуация.

Не очень понимаю как это сделать - очень бы хотелось пример...

While Perl does not have a standard a way of making data private
(think of C++'s 'private'), there are other ways to achieve the same.
Some of them provide even stronger encapsulation than most other
languages.

The simplest way is using a closure. If you make the hash to store the
data a lexical variable in your module, it can't be accessed from
outside but only from those methods that happen to be within the same
scope. This however hash the drawback that the hash is static: Each
object shares the same hash which might not be acceptable for you.
Here's a small example of how to attached a protected hash to each
instance of an object:

    package Closure;

    sub new {
        my $class = shift;
        my $self = bless { } => $class;
        $self->create_closures;
        $self->store(shift);
        return $self;
    }

    sub create_closures {
        my $self = shift;
        {
            my %hash;
            $self->{ store } = sub {
                my ($key, $val) = @_;
                $hash{ $key } = $val;
            };
            $self->{ get } = sub {
                $hash{ +shift };
            };
        }
    }

    sub store {
        my ($self, $key, $val) = @_;
        $self->{ store }->($key, $val);
    }

    sub get {
        my ($self, $val) = @_;
        $self->{ get }->($val);
    }

Now everyone can add data into %hash only by issuing the store() method.
To prevent that the 'wrong people' call store and add whatever to the
hash, you could add a check for caller():

    sub store {
        my ($self, $key, $val) = @_;
        
        my ($pkg) = caller;
        die "Forbidden!" if $pkg->isa("Closure");
        ...
    }

Use 'caller EXPR' if you need even finer control. The above would
implement something on the level of 'protected': Sub-classes of your
class are allowed to call store(), anything else not.

Мдааа, Perl кaнешно форева (для тех кому он не Pathologically Eclectic Rubbish Listing), но требуется-то решение на Python'e! А в нем клозуриков как элемента нету... Да и зачем они там, где есть классы и есть callable объекты?

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

Возможности и использование указателей видимости non-public в Java гораздо более обширны и фундаментальны, чем применение для такого частного случая.

> Приведенное перловое решение касается только одной частной задачи - 
> реализации некоего кешевого хранилища данных. Но ведь их туда 
> сначала поместить надо, откуда-то доставив - при этом для этого надо
> защищать не только сами данные, а и процесс их извлечения.
----

#!/usr/bin/perl -w

sub makepoint
{
    # Очень приватные поля данных
    my ($x, $y) = @_;

    # Очень приватные методы
    my $set_x = sub { $x = shift };
    my $set_y = sub { $y = shift };

    my %methods = (
        as_string => sub { "($x, $y)" },
        moveto    => sub { my ($x, $y) = @_; $set_x->($x); $set_y->($y) }
    );

    return sub { my $op = shift; $methods{$op}->(@_) }
}

my $pt1 = makepoint(3, 4);
my $pt2 = makepoint(-3, -4);

print $pt1->('as_string'), "\n";
print $pt2->('as_string'), "\n";
$pt1->('moveto', 4, 5);
$pt2->('moveto', -4, -5);
print $pt1->('as_string'), "\n";
print $pt2->('as_string'), "\n";

-----

1. Это на Питоне?!!!!! Меня обещали closures на Питоне научить делать...

2. Классы хде? А если перловские (черезодноместные) классы сочетать с этим "кодом", то не слишком ли много загадок надо будет решать ежедневно мейнтейнерам такого проекта?

3. Недоступность локальных переменных функций и управление видимостью в пакетах и классах - это очень разные разности.

4. Создаваемые в рантайме вызываемые объекты - это сильно. Но чем больше на них сделано в приложении - тем трудее ему шагать по жизни. Недаром в Яве вместо них внутренние классы (которые там клозуровскую и колл-бековскую функциональность и обеспечивают без особых накладок)...

5. Наверное на перле можно написать некое подобие явы вместе с соответствующей ВМ. Но такое решение точно превзойдет прототип по "медленнодействию"... Стоит ли?

6. Или предлагается вообще яву перлом заменить?! Мысль не нова, но не получила поддержки широкой общественности :)))) Всё-таки теория и практика языков программирования на месте не стояла за те двадцать лет, что разделяют эти два инструмента.

1. Нет.

2. А надо? При живых-то клозурях? Вон гляньте примерчик: http://okmij.org/ftp/Scheme/index.html#pure-oo

3. Да ну? Список различий - в студию. Надо разобраться.

4. Подробнее пожалуйста.

5. Яву тут превзойти трудно, но perlу это под силу :)

6. Да вы правы - Ява явно устарела :)

speer, есть мнение, что perl, ruby & python - языки более высокого уровня, чем java, c++ и компания. Но вот оценить это, не попробовав, сложно :)

вот что по поводу perl думает Erik Naggum - http://www.underlevel.net/jordan/erik-perl.txt

Суровая правда о безопаснсти и питоне

>>1. Это на Питоне?!!!!! Меня обещали closures на Питоне научить >>делать...
Научить конечно можно,но они ничем не помогут в свете вашего
(совершенно справедливого замечания) п.3

Чего сегодня мы имеем на эту тему в Питоне,
модули rexec,bastion,sandbox -это все среды ограниченного
исполнения классов- они все дырявые.
Так что если Вам крутая идентификация из программы нужна, тут
PYTHON наверно не очень годиться.(Кстати, а где такое нужно вообще?)
Теперь что касается обычных корпоративных приложений,
где маниакальная безопасность не требуется тут в принципе совсем
даже неплохо:
a)минимальную защиту (от порчи кода дураком)можно обеспечить так же как и в jave-
распространять байт-код.
При этом если человек взялся за дизассемблер тут скорее всего одинаково
будет -сломает(и успешно ломают) ваши классы и на питоне и на java.
так что protected method вам не замок.

б) можно упаковать байт код одной из утитлит(MCMillan installer или py2exe) в большой дистр.который будет состоять из какого-нибудь конгломерата кода.
тут уже трудность взлома будет сопоставима с трудностью взлома
незащищенной специальными методами программы написанной на C.

Ну и наконец самое главное-это защита приложения на уровне ОС.
Если здесь дыра, то все предудщее вообще не имеет смысла.

Любопытно что по поводу пользы protected,private...есть очень разные мнения.
Так вот Straustrup считает наличие таких конструкций стратегической
ошибкой спецификации на C++.
А вот разработчики java и ruby просто следовали С++.
В концентрированном виде это можно прочесть у Alex Martelli:
http://aspn.activestate.com/ASPN/Mail/Message/1601287

Java и python - вещи одного класса... Те же недостатки, та же
неповоротливость, то есть немерянные тормоза. А что народ скажет про php, как альтернативу двум предыдущим уродцам?
Я пишу довольно большие приложения на php, и никогда не
возникало желание податься в java или python. Писать удобно и
быстро, производительность - выше всяких похвал.

Java 2 for NetBSD/i386 binaries available

>А что народ скажет про php, как альтернативу двум предыдущим уродцам?

А народ скажет вот что:

Обход "Safe mode" ограничений в PHP 4.3.x.
Уязвимость обнаружена в PHP. Удаленный пользователь может обойти &#8220;Safe Mode&#8221; ограничения, вызывая внешние файлы в ограниченных каталогах, используя include() и require(). Удаленный пользователь может обойти ограничения Safe mode, когда не определена PHP директива safe_mode_include_dir. Проверки безопасности не срабатывают при попытке доступа к файлам, используя вызовы include() или require(). В результате возможен неавторизованный доступ или обход политики в среде, в которой используется Safe Mode. Уязвимость обнаружена в PHP 4.3-4.3.2.

Пример:

<?
echo("trying to read /etc/passwd");
include("/etc/passwd");
?>

> Обход "Safe mode" ограничений в PHP 4.3.x.

И чего дальше? Какие выводы? Я, например, никогда не использую
safe mode и в гробу видел твои проблемы с инклюдами. Кстати,
есть и еще лазейка - база данных. Load data infile '/etc/passwd'.

Эй, поцы, Питон используется во многих компаниях крупных.

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

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

> й, поцы, Питон используется во многих компаниях крупных.
в каких именно?

> Воп предствьте - ведете проект(около года) и вдруг чел(или не один)
> особенно важный свалил, заболел, умер и тд
хреновый аргумент. 1) это не главное при выборе языка, 2) на питоне можно написать очень по-разному. например, можно писать в ОО или ФП стиле, и человек не знающий ОО/ФП нихрена не поймет, даже изучив за неделю туториал и статьи Мертца.

> Пытливому уму здесь есть над чем подумать - почему такое оказалось
> возможно и получилось с Явой, а не с Питоном, например...

Потому что, на питоне сразу можно создавать программы.
А жабу используют как универсальный ассемблер, создавая
прогу на UML, EJB, XML, ёпрст...

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