>del array[123]
array.pop(123)

Мнде. У нормальных людей pop - это pop, и идет с хвоста. А у питонистов pop - это delete, и идет из любого места.

StragaSevera
array.pop() - с хвоста
array.pop(i) - по индексу

днище_ыыыы
Я и говорю. У нормальных людей pop - это pop. А у вас pop - это хз что.

StragaSevera
шо то хуйня, шо это

днище_ыыыы
Хуйня, когда язык с одной стороны заявляет, что есть один и желательно только один способ, а с другой, врубает хуйню про pop, который юзают вместо delete - хуйнистее.

...

А што, простите, не так? В каждом языке для этого свои способы записи, но всё работает жи.

MonkAlex
Непоследовательность.

Значит, ты слишком lawful для питона:)

Но вообще если юзать NumPy, то там есть numpy.delete(array, [i1,i2..])

Но если не по форме, но по духу, то полностью поддерживаю.

> Для того, чтобы добавить значение в массив

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

Байтоёбство и ручное управление памятью нормальностью называть... если только в статистическом смысле.

Вот тебе нужен быстрый доступ по индексу в каком-нибудь большом массиве. Но тут вдруг понадобилось дописать элемент в конец. Переделаешь всё в список? Случаи ведь разные бывают.

> Вот тебе нужен быстрый доступ по индексу в каком-нибудь большом массиве. Но тут вдруг понадобилось дописать элемент в конец. Переделаешь всё в список? Случаи ведь разные бывают.

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

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

Facensearo
Если что, называть "нормальными языками" Си и ЦПП в 2016 году - моветон.

Mikie
Блеать. В Питоне надо еще юзать какую-то библиотеку для работы с числами?
Пиздец, нафиг, нафиг.

StragaSevera
> Блеать. В Питоне надо еще юзать какую-то библиотеку для работы с числами?
Вы понимаете, что есть разница между просто числами и системой компьютерной алгебры?

По дефолту пайтон умеет в длинные и комплексные числа.

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

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

> системой компьютерной алгебры
CAS - это что-то типа матлаба или вольфрама, а NumPy - это просто библиотека.

Mikie
Ок, действительно, немного некорректно выразился.

StragaSevera
> как вы с этим живете!

Мы живём с Python3, где подобные стилистические несообразности выпилены принудительно, с умышленным сломом обратной совместимости.

> В Питоне надо еще юзать какую-то библиотеку для работы с числами?

Для «простой» работы с числами есть изкоробочная math. А NumPy — он для векторизованных вычислений на n-мерных массивах.

StragaSevera
> врубает хуйню про pop, который юзают вместо delete

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

> чтобы отсортировать массив in place, нужно написать array.sort(), а для того, чтобы не in place - sorted(array)

Аналогично, первое даёт принудительную переиндексацию списка в памяти, второе — сортировка на лету без перезаписи исходного списка. Юзкейсы опять же разные by design.

> Нет, не переделаешь, потому что у тебя этот массив имеет размер на 10е6 по одному измерению и там дальше по коду десяток обращений по индексу происходит внутри трёх вложенных циклов, а аппендить тебе нужно пару-тройку раз на весь проект.

и как мне это помешает? вообще-то список (который массив с удобной оберткой для добавления) и связный список (который элементы с указателями друг на друга) - это разные структуры.

> Мы живём с Python3, где подобные стилистические несообразности выпилены принудительно, с умышленным сломом обратной совместимости.
Книга, по которой я учу язык, написана как раз под Py3. Такшта...

> В частном случае применения результат может быть одинаков, но предназначение у них разное, а не вместо.
А мне выше заливали, что отсутствие нормального синтаксиса для delete - не баг, а фича, ибо можно юзать pop.

> Аналогично, первое даёт принудительную переиндексацию списка в памяти, второе — сортировка на лету без перезаписи исходного списка. Юзкейсы опять же разные by design.
И? У любых двух методов юзкейсы разные, иначе они были бы одним методом.
С какого перепуга sorted пишется до массива, а sort - после? Почему нельзя как в нормальном Руби, с .sort как сортировкой копии и .sort! как сортировкой оригинала? Где ваша хваленая лаконичность?

StragaSevera
а с чего питон должен быть как руби то? У питона свои разработчики. Всегда есть конструкции хуже и лучше.

MonkAlex
С того, что на словах - лаконичность и простота, а на деле - херня и отсутствие унификации. Две схожие операции делаются по-разному - одно методом, другое стандартной функцией. Нафига???

Facensearo
А мы говорим про питон или вообще? Подразумевается, что мы говорим о связных списках и массивах с обёрткой: ты не будешь переделывать массив, который у тебя есть в список, ты скорее добавишь обертку добавления, но списком ты от этого массив не сделаешь. И да, что за странная терминология? Когда мы говорим о структурах данных, массив - это массив, а список - это связный список.

StragaSevera
>Почему нельзя как в нормальном Руби, с .sort как сортировкой копии и .sort! как сортировкой оригинала?
>Две схожие операции делаются по-разному - одно методом, другое стандартной функцией.
Сортировка объекта и сортировка в копию - разные операции. В шарпе, к примеру, изменение коллекций через OrderBy для копий и Sort для самой коллекции. Только, как бы сказать, они и применяются в абсолютно разных ситуациях. Я не согласен с вами в том, что это схожие операции в плане применения.

> А мы говорим про питон или вообще?
Вообще.

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

Вот есть конкретный пример.
Есть жирный массив, который используется и в легаси он именно массив, array.
Нужно пришить к нему редкое добавление элементов.
Соответственно я либо буду использовать какой-нибудь условный array.resize/realloc (C), либо заменю array на list (С#)/arraylist(Java)
ну или вообще it depends, может быть, выгоднее будет накостылить постоянный массив с переменным хвостом (array+list) и обернуть это все в, чтобы не дрочить страницы памяти пересозданием многомегабайтного массива.

> И да, что за странная терминология? Когда мы говорим о структурах данных, массив - это массив, а список - это связный список.

нормальная терминология.
в шарпе List на основе массива, LinkedList - двусвязный, первый называется списком, второй - связным списком
в яве ArrayList, который тоже называется просто списком и LinkedList - связным списком
даже в сишке, где структуры данных собирай сам на аллоках и указателях, одно/двусвязные списки просто списками, кажется, не называются почти никогда, из-за вот этой вот двусмысленности

> Сортировка объекта и сортировка в копию - разные операции. В шарпе, к примеру, изменение коллекций через OrderBy для копий и Sort для самой коллекции. Только, как бы сказать, они и применяются в абсолютно разных ситуациях. Я не согласен с вами в том, что это схожие операции в плане применения.
В каких разных-то?
Написал ты array.sort!, затем понял, что во имя святой иммутабельности красивше будет new_array = array.sort . Это в Руби. В питоне же идет какая-то херня и танцы с превращением метода в функцию. Нахрена?

StragaSevera
> во имя святой иммутабельности

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

k338914
А теперь переведи свое сообщение на русский.

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

> вообще it depends, может быть, выгоднее будет накостылить постоянный массив с переменным хвостом
Суть. И нафига нужен был тот фанатизм?..

StragaSevera
>затем понял...
Так пишется то всегда одинаково. Или у вас каждый проект отдельно решает, в каком стиле будет писаться код? Я вот всегда пишу работу с коллекциями пришедшими снаружи - как с ридонли, со своими внутренними - как с изменяемыми.

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

Контексты разные, привычки разные, методы разные и в разных местах. Имхо - вполне нормальное поведение. Было бы хуже, будь у меня 4 метода sort, какой то из них меняет коллекцию, какой то нет.

> Так пишется то всегда одинаково. Или у вас каждый проект отдельно решает, в каком стиле будет писаться код? Я вот всегда пишу работу с коллекциями пришедшими снаружи - как с ридонли, со своими внутренними - как с изменяемыми.
Выразительность for the win. В одном случае выразительнее написать так, в другом - этак.

И да, это не оправдание разноса одинаковой функции по разным синтаксисам.

> Было бы хуже, будь у меня 4 метода sort, какой то из них меняет коллекцию, какой то нет.
В нормальном языке (т.е. Ruby), если в методе есть знак !, то он изменяет коллекцию, если нет - то не изменяет. У всех методов есть парные им !-методы.

StragaSevera
> переведи свое сообщение на русский

«Почему? Да потому что мы решили: так надо.»

> разноса одинаковой функции

Так суть в том, что это разные функции с разным назначением. И то обстоятельство, что в некоторых юзкейсах они приводят к одинаковому (либо взаимно сводимому) результату — не отменяет их разности.

StragaSevera
восклицательный знак - забавное решение. К сожалению, оно подойдет только платформе, а то поседеешь же создавать по два метода на каждый чих.

> Так суть в том, что это разные функции с разным назначением. И то обстоятельство, что в некоторых юзкейсах они приводят к одинаковому (либо взаимно сводимому) результату — не отменяет их разности.
Да, ты совершенно прав. Сортировка и сортировка - абсолютно разные функции!

> К сожалению, оно подойдет только платформе, а то поседеешь же создавать по два метода на каждый чих.
Э-м-м, почему? Потратил 30 секунд на метод с !, и потом все его используют и няшатся.

StragaSevera
у кошелька метод снять_деньги может снимать деньги, а метод снять_деньги! возвращает новый кошелек!

MonkAlex
Не понял вашей метафоры. ORM - это вообще другое, а если мы не о персистентности, то порой так и надо.

StragaSevera
так и коллекции разные бывают. Некоторым сортировка - нужна, некоторые неизменяемые и потому сортировка только в новую коллекцию. А ещё бывают обобщенные реализации со своими тараканами.

ПС: и я ни слова не писал об ORM. Это просто предметная логика. Только в платформе выглядят красиво такие вещи, на деле они далеко не всегда работают.

MonkAlex
Не нужен метод - не реализуешь. В чем проблема?

StragaSevera
вот и ответ на вопрос в шапке. Реализуй себе методы сам, раз не устраивают из коропки.

Авторы так видят, очевидно же.

MonkAlex
А в питоне разве есть манкипатчинг? И даже если есть - разве это нормально, манкипатчить идиотизмы языка?

Есть.

StragaSevera
есть.

А нормально это или нет - так это ваше дело. В этом же соль любого хорошего языка - дать возможность написать себе велосипед.

MonkAlex
ВОзможность написания велосипеда не отменяет нужности наличия готовых и встроенных.

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

> так раз их нет в коропке - значит они не нужны не только разработчикам питона, но и пользователям.
Что весьма характеризует и пользователей, готовых юзать pop вместо delete и мириться с .sort и sorted( .
Об том и офигевание.

> Я на питоне только скрипты пишу в пару сотен строчек кода, хз как можно писать, когда не знаешь, какой тип объекта может придти в любой момент.
Duck typing ftw.

StragaSevera
> Duck typing ftw.
А потом TypeError: 'type' object is not iterable

MonkAlex
А тесты писать Пушкин будет, чтобы не было method_missing?

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

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

StragaSevera
дерьмо в каком плане? Большинство, имхо, просто нахер никому не нужны. А нужные всё равно вылизывают до рабочего состояния.

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

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

MonkAlex
> то кроме юнит тестов всегда баги будут находить пользователи.
Собственно, поэтому 99% программ и дерьмо.

StragaSevera
всмысле, почему? потому что у них есть пользователи?

MonkAlex
Потому что они считают пользователей бета-тестерами, вместо того, чтобы просто написать юнит-тесты.

StragaSevera
так пользователи - не юнит тесты. Они то работают с жизненным циклом ваших сущностей, у которых по несколько точек входа в изменяющие их кейсы. Чтобы это покрыть тестами - надо покрывать прям абсолютно все состояния, без исключений. Кто это писать и поддерживать будет, спортлото?

MonkAlex
Лучшее - враг хорошего. Тот факт, что ты не можешь покрыть абсолютно все кейсы, никоим образом не разрешает тебе писать код без юнит-тестов.

StragaSevera
тот факт, что ты пишешь юнит тесты, не делает твой продукт полезным или рабочим. Не надо кидаться в крайности.

MonkAlex
Факт. А Волга впадает в Каспийское море, а лошади кушают овес и сено.
Что сказать-то хотел? Что т.к. юнит-тесты - не гарантия, то их писать не надо?

StragaSevera
вы как то упорно в тесты вцепились. Ещё раз - то, что может проверить компилятор в C#, проверять приходится тестами в python. Зачем писать тесты, когда можно оставить проверки компилятору. Он то явно лучше меня это сделает.

MonkAlex
Затем, что в C# ТОЖЕ необходимо писать тесты. Но средний программист - лентяй и гонит пургу типа вашей. Поэтому язык, в котором писать тесты напрямую требуется - благо.

StragaSevera
Ты подменяешь аргументацию MonkAlex
Он не говорил о том, что юнит-тесты не нужны.
Он говорил о том, что при статической типизации конкретное подмножество [юнит-]тестов не нужно.

днище_ыыыы
... что заставляет погромистов игнорировать и остальные юнит-тесты, из-за чего мы и имеет то, что имеем.

StragaSevera
>что заставляет погромистов игнорировать и остальные юнит-тесты
...Как ты это вывел? ELI5

днище_ыыыы
Простое знание человеческой природы.

Ладно, я умываю руки. Я пишу тесты, но аргументации StragaSevera просто не понимаю.

Относительно релевантный пост
https://habrahabr.ru/post/315152/
хотя там больше мелкиепридирки

днище_ыыыы
Как минимум, про Ruby - древний бред.
Всегда в miltiline? С каких пор? "nil.to_i.nil? #=> false"? А какое желаемое поведение, true, что-ли?