Аналог режима PHP для Python/Ruby

И какой индекс будет у 'some'?

1

Еще примеры стройных языков - Lisp, Haskell, Smalltalk, Javascript - в них нет каких то исключений в синтаксисе, есть небольшой набор базовых правил. Javascript мне не слишком нравится, но стройность ортогональна моим вкусовым предпочтениям, это я не делю на «нравится-не нравится».

Не стройный: PHP, Delphi - порождения эволюции, когда в язык постепенно напихивали разных фич. Внезапный Reference Counting в Deliphi для объектов унаследованных от COM объектов - это нифига не стройно. Это может быть полезно в некоторых случаях (для того и впихнули) - но это делает язык не стройным.

не использую <> никогда не видел и не пользовался.

Судя по комментариям и «глубине знаний» — не видел и не пользовался. Только иногда на форумах читал отзывы других, таких же, как ты :)

Смолтокер смотрит на вас с непониманием.

И какой индекс будет у 'some'?

Array
(
    [0] => field1
    [fiel2] => name2
    [1] => some
    [some2] => 10
)

Если я правильно понянимаю PHP-конструкцию, это вполне обычный ассоциативный масив. В Python он есть.

P.S. согласен с maloi.

private и protected появится, тогда и можно будет рассуждать ;)

Я тебя разочарую - private и protected нету во многих стройных языках: JavaScript, SmallTalk - в нем все поля приватны а все методы публичны.

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

Просто в последнее время стало модным кричать «Похапэ гавно!», при этом совсем не зная его, а что ещё хуже - не зная ничего и о других ЯП.

Я тебя разочарую - private и protected нету во многих стройных языках

Стройность всё! ООП ничто! Оу йе!

при использовании nginx+passenger для мягкого рестарта используется «touch tmp/restart.txt» после чего passenger перезапускает все инстансы без отказа от приема запросов.

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

В Python он есть

Вопрос не в массиве. Вопрос в смешанной записи.

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

Я пишу:

    function table_fields()
    {
        return array(
            'id',
            'login' => 'username',
            'username',
            'user_nick',
            'group_id',
            'user_title' => 'title',
// ...
        );
    }

Как делать такую смешанную запись компактной на Питоне?

$x = array('field1', 'fiel2' => 'name2', 'some', 'some2' => 10);

Нет пути! Это же читать просто ад. Лучше уж вербозно писать x = {0:'field1', 'field2':'name2', 1:'some', 'some2':10) - не надо считать аргументы и выфильтровывать где ключ-значение, а где только значение. И несмотря на большую вербозность и большую читабельность это таки в питоне записалось короче чем в PHP ;)

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

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

Это же читать просто ад

Мне лениво было в LORCODE переключаться :) Вот в таком виде оно практически у меня используется: Аналог режима PHP для Python/Ruby (комментарий)

не надо считать аргументы

А оно и не предназначено для ручной «фильтрации». Машина должна работать, человек — думать (c) IBM :)

это таки в питоне записалось короче чем в PHP

Если бы я хотел краткости, я бы писал на Perl'е :) Краткость != не избыточность. Я легко терплю многословные языки (более того, в больших проектах я их предпочитаю), но я ненавижу избыточность.

Вопрос в смешанной записи.

На поверхности, вопрос в том, что в литеральных значениях типа «ассоциативный массив» ты не хочешь указывать ключи для некоторых элементов. Если чуть глубже, сама эта возможность является востребованной только в PHP (из известных мне языков). Так что...

Как делать такую смешанную запись компактной на Питоне?

Такой же компактной, как в PHP - никак. Но написать функцию php_array - дело несложное:

>>> php_array({'foo': 'bar', 'yuk': 'yuk'}, 3, 4)
{0: 3, 1: 4, 'yuk': 'yuk', 'foo': 'bar'}

Как делать такую смешанную запись компактной на Питоне?

Как то так:

def table_fields(): 
  return fields_mapping('id', ('login', 'username'), 'username', 'user_nick', 'group_id', ('user_title', 'title'))

def fields_mapping(*args):
  result = {}
  i = 0
  for arg in args:
    if isinstance(arg, str):
       result[i] = arg
       i += 1
    else:
      result[arg[0]] = arg[1]  

Я не лиспер, я фортер, ненавижу лишние скобочки. Они — избыточны :)

Мой предыдущий ответ :)

Вообще, написал большой ответ на удалённый (с ошибкой) коммент, но вкратце суть такая — такой вариант допустим, вполне короткий, но весьма избыточный.

Если буду свой фреймворк переводить на Питон, видимо, придётся реализовывать смешанные списки в таком стиле, но, надеюсь, в обозримом будущем не понадобится :D

Я не лиспер, я фортер, ненавижу лишние скобочки.

А я ненавижу невнятные структуры данных (и, судя по отношению к PHP, не я один).

А я ненавижу невнятные структуры данных (и, судя по отношению к PHP, не я один).

Боюсь, в формировании отношения к PHP, его структуры данных лежат на последнем месте :D

но весьма избыточный.

Тебе может быть несимпатичен такой синтаксис, по сравнению с php-шным (что я вполне могу понять), но избыточности там нет - отличия лишь синтаксические (если говорить о моем решении, а не tailgunner-a). Ничего считать самому не надо.

отличия лишь синтаксические

Я и имею в виду синтаксическую избыточность.

Ладно, это уже вопросы вкусов :)

Стройность всё! ООП ничто! Оу йе!

Так это, мы же говорили про стройность. Инкапсуляцию еще можно добавить в язык, а вот стройность в него уже не вернуть. А во вторых это ломает только инкапсуляцию - которая просто документация, и использование такого костыля как _ в начале имени (или просто комментом что оно private) что бы всем показать что это мое - не трожь я готов использовать. Тем более что ничего серьезного я на языках с динамической типизацией писать не буду :)

Так это, мы же говорили про стройность. Инкапсуляцию еще можно добавить в язык, а вот стройность в него уже не вернуть. А во вторых это ломает только инкапсуляцию - которая просто документация, и использование такого костыля как _ в начале имени (или просто комментом что оно private) что бы всем показать что это мое - не трожь я готов использовать. Тем более что ничего серьезного я на языках с динамической типизацией писать не буду :)

Это ломает накорню всю стройность, путём наращивания костылей в виде комментов или «_» символов.

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

Это не кусок орм это сдыдоба какая то, но

return Table('id',
          'username',
          'user_nick',
          'group_id',
          user_title= 'title',
          login='username',
);

Но обычно делают декларотивоту в виде:

class MyTable(Table):
 id = String()
 login = String(db_field='username')
 etc

Если буду свой фреймворк переводить на Питон

То что на питоне пишут как на жабе — встречал не раз, и, в принципе, терпеть можно. Но твой код точно заставит кровоточить глаза.

Но твой код точно заставит кровоточить глаза.

Уговорил, тебе я его не покажу :)

Избыточность, избыточность...

Избыточность, избыточность...

В каком месте? Аналог PHPшной записи с точностью до кавычек.

В каком месте?

id = String()
login = String(db_field='username')

Аналог PHPшной записи с точностью до кавычек.

'id',
'login' => 'username',

Я выше писал, что избыточность — это не касательно размера кода. Что за сущность String()? Нафиг мне синтаксический мусор?

В _редких_ случаях, когда не работает автоопределение типов, да, можно пойти и на усложнение синтаксиса:
'id' => array('type' => 'string'),

Но зачем такой мусор использовать постоянно, когда в 99% случаев он не нужен?

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

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

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

Ты прав. Я так в своё время, уже много лет тому назад и сделал. И, безусловно, использую метаданные. Типы полей, классы для их id, типы полей в форме редактора для автоадминки и т.п.

Но в 99% случаев эти параметры вычисляются. Зачем загружать код синтаксическим мусором?

А я не про класс говорил. Что не устраивает в записи

return php_array('id', 'name', title='my title')

?

очевидно чтобы человек который получил твой код без бд не терялся в догадках что тут происходит или не прыгал из кода в шел с дб клиентом

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

Да нередко и 50% бывает, вообще-то :) Хотя точно не считал, конечно. А процентов 10 кода — очень распространённое явление.

Плюс психологический момент. Обычно описание полей — это самая объёмная разовая работа над классом. Понятно, что есть автоматические описания, генерируемые из описания таблицы в SQL — но это годится только для SQL и только для созданных под ORM таблиц, что бывает не всегда. Понятно, можно использовать автоматическую генерилку классов из таблицы БД, но и тут лишних действий набегает немало.

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

Что не устраивает в записи

Не знаю. Надо будет вживую погонять :)

К такому формату записи претензий нет. Претензии именно к иным вариантам :)

тоесть ты серьзено считаеш что

 array('id', 'status', 'status2') 

class Status(Table)
   status = String(choices=['new', 'processed'])
   status2 = Int(min=1, max=3) 

очевидно чтобы человек который получил твой код без бд не терялся в догадках что тут происходит

А БД у меня от ORM оторвана двумя слоями абстрации. Так что в описании полей БД вообще никак не фигурирует (кроме случаев полной автогенерации полей — там, понятно, всё на БД. Но это редкий случай).

И замена бэкенда в общем случае никак со структурой класса не связана.

или не прыгал из кода в шел с дб клиентом

Не требуется :)

В эту запись не вкрячишь числовые (да и любые не-строчные) ключи.

Да. Намного. Но не в твоём варианте. Ты специально взял дефолтовый стиль моего варианта и с ограничениями в своём. Безусловно, в таком варианте мой код тоже будет достаточно многословен и будет содержать ограничения.

Вот только в 99% случаев это не нужно.

В эту запись не вкрячишь числовые (да и любые не-строчные) ключи.

В _моём_ варианте это не нужно. Имена методов не могут быть числовыми :)

я описал поля:

[code] function table_fields() { return array( 'id', 'login' => 'username', 'username', 'user_nick', 'group_id', 'user_title' => 'title', // ... ); } [/code]

потом делаю whatver.group_id = fopen('/dev/random'), что происходит?

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

В _моём_ варианте это не нужно

Тогда функцию нужно переименовать из php_array в somewhat_php_like_array_for_KRoN73.

Во-первых, у меня не свойства, а методы. Свойства в наследниках переопределять геттерами-сеттерами? Мусор же :)

Во-вторых, whatver.set_group_id(fopen('/dev/random')) при жёсткой проверке типов даст исключение, при мягкой — да, запишет мусор (хотя PHP наверняка выкинет NOTICE).

В-третьих, у меня есть голова и вместо того, чтобы считать лишние токены синтаксического мусора, мне просто в голову не придёт написать такой хлам :)

А еще ключи без значений можно указать только в начале

Тогда не годится :-/

Думаю, наш великий PHPшник это скоро поймет, если начнет работать с языком плотнее.

Возможно :) Вполне возможно, что даже взявшись за него плотнее, я с него сбегу на что-то более подходящее.

Тогда функцию нужно переименовать

Ну, это уже не ко мне.