PEP 0448 — Additional Unpacking Generalizations

Кому надо все перешли.
Имхо продакшн пока на втором сидит, но все равно подтянуться со временем.

Имхо продакшн пока на втором сидит, но все равно подтянуться со временем.

Уже не весь, но многие будут сидеть на втором ещё очень долго.

А какой профит от этого?

Да и зачем вообще жить?

эмокид спалился

Нормального паттерн-матчинга до сих пор нет.

кто-то ещё противится переходу на Python 3?

в 2015-году уже найти можно лишь только — кого-нибудь адепта из радикальной секты обратной совместимости

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

function(**kwargs, **more_kwargs)

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

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

Питон умеет в произвольное количество аргументов

Ну, а что означают звездочки?

Тупой анонiмус такой тупой.

Не нужно. Нужен паттерн матчинг.

Вот сколько я не интересовался этим вопросом (емнип, даже на лоре тему создавал), никогда ничего внятного не слышал. Твой ответ — только подтверждение правила. Ты можешь четко ответить на вопрос? То есть, понятно, что там другой, чуть более короткий синтаксис. А семантическое то отличие от ифов, кондов свитчей и прочего в чем?

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

Ну, а что означают звездочки?

аргумнты, которые идентифицируются по названию ключа (а не по своему порядку)

> в 2015-году уже найти можно лишь только — кого-нибудь адепта из радикальной секты обратной совместимости

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

ну тыг это же и есть более радикальное ответвление от радикальной секты обратной совместимости :-)

у них там автоматы калашникова, и чистый разум, незамутнённый новым синтаксисом :-D

аргумнты, которые идентифицируются по названию ключа (а не по своему порядку)

В JS это тривиально делается передачей объекта в качестве аргумента. Соответственно, отпадает надобность в введение отдельного синтаксиса. Почему такое решение не подходит для питона?

В JS это тривиально делается передачей объекта в качестве аргумента. Соответственно, отпадает надобность в введение отдельного синтаксиса. Почему такое решение не подходит для питона?

зачем делать отдельный синтаксис?

ответ:

для того чтобы не пришлось писать лишнии строчки кода?

пример на Python:

def my_print(str, end='\n'):
  sys.stdout.write(str + end)

тот же пример на JS

function my_print(str, options) {
  if (options === undefined) { options = {} } // вот эта лишняя строчка.. как её убрать?!
  
  if (options.end === undefined) {
    options.end = '\n'
  }
  
  console.log(str + options.end)
}

паттерн манкинг

петросян.жпг

Понапридумывают всякую левую ересь

Для вас, Козлов, придуман ассемблер. Или брейнфак, если вы эстет

Это, конечно, не настолько бесполезная «фича» как аннотации, но всё равно голимая минорщина.

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

function my_print(str, options) {
  if (options === undefined) { options = {} } // вот эта лишняя строчка.. как её убрать?!
  
  if (options.end === undefined) {
    options.end = '\n'
  }
  
  console.log(str + options.end)
}

Кстати, драматизировать тоже не надо, этот код пишется вот так

function my_print(str, o) {
 console.log(str+(o&&o.end||"\n"))
}

Ну так что, ответ про «нужность» паттерн-матчинга будет? Приведи код, который заметно выигрывает по сравнению условными ветвлениями, который выглядит не как легкая косметика, а действительно впечатляет. А пока Петросяном в этом треде выглядишь только ты.

Да, и вот еще что. К сожалению, эту фичу, которую ты показал, которая, кстати, тривиально выражается замыканием, например,

;(function(){
 var end="\n"
 my_print=function(str){
   console.log(str+(arguments[1]||end))
 }
}())

Пишу в удаленный тред.

Как по мне — какая-то перловка и гогно.

Раньше вот всякие Санычи жгли, но я их не застал, а теперь приходится анонiмусов терпеть, например. Раньше и трава, говорят, зеленее была...

PEP написал, кстати, некто Ландау. Ландау!)

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

Сделай на if-ax аналогичный разбор пакета протокола bittorrent.

%% Packet types
-define(CHOKE, 0:8).
-define(UNCHOKE, 1:8).
-define(INTERESTED, 2:8).
-define(NOT_INTERESTED, 3:8).
-define(HAVE, 4:8).
-define(BITFIELD, 5:8).
-define(REQUEST, 6:8).
-define(PIECE, 7:8).
-define(CANCEL, 8:8).
-define(PORT, 9:8).

recv_message(Rate, Message) ->
    MSize = size(Message),
    Decoded =
    case Message of
        <<>> ->
            keep_alive;
        <<?CHOKE>> ->
            choke;
        <<?UNCHOKE>> ->
            unchoke;
        <<?INTERESTED>> ->
            interested;
        <<?NOT_INTERESTED>> ->
            not_interested;
        <<?HAVE, PieceNum:32/big>> ->
            {have, PieceNum};
        <<?BITFIELD, BitField/binary>> ->
            {bitfield, BitField};
        <<?REQUEST, Index:32/big, Begin:32/big, Len:32/big>> ->
            {request, Index, Begin, Len};
        <<?PIECE, Index:32/big, Begin:32/big, Data/binary>> ->
            {piece, Index, Begin, Data};
        <<?CANCEL, Index:32/big, Begin:32/big, Len:32/big>> ->
            {cancel, Index, Begin, Len};
        <<?PORT, Port:16/big>> ->
            {port, Port};
    end,
{Decoded, etorrent_rate:update(Rate, MSize), MSize}.

А Бизли в трешке так и упарывается с форматирование чисел в байтовые строки. Еб-ый стыд.

Ну а что тут такого? Просто небольшой сахарок над теми же ифами.

...
var m=Message
var Decoded

if(m==INTERESTED) return Decoded=interested 
if(m==HAVE&&PieceNum==32/big) return Decoded=[have, PieceNum]
...

Очень сложно увидеть то, чего не понимаешь, это правда.

ну так объясни, чего я не понимяю. В той же википедии приведены убогие примеры, которые тривиально выражаются через if/cond/switch. Все кругом твердят о какой-то мифической мощности pattern-matching, но никакого кода, подтверждающего эту мощность, нигде нет. Одна банальщина. Покажи код.

Держи: Скриптовый функциональный язык (с иммутабельностью) (комментарий)

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

deleteFixup :: RBZip a -> RBZip a
deleteFixup (RBZip a@(Node Red _ _ _) path) = RBZip (setBlack a) path
deleteFixup (RBZip a ((Step cb vb ToLeft (Node Black vd c e@(Node Red _ _ _))):path)) = 
    deleteFixup . topMostZip $ RBZip (Node cb vd (Node Black vb a c) (setBlack e)) path
deleteFixup (RBZip a ((Step cb vb ToRight (Node Black vd e@(Node Red _ _ _) c)):path)) = 
    deleteFixup . topMostZip $ RBZip (Node cb vd (setBlack e) (Node Black vb c a)) path
deleteFixup (RBZip a ((Step cb vb ToLeft (Node Black vd (Node Red vc scl scr) e)):path)) = 
    deleteFixup $ RBZip a ((Step cb vb ToLeft (Node Black vc scl (Node Red vd scr e))):path)
deleteFixup (RBZip a ((Step cb vb ToRight (Node Black vd e (Node Red vc scl scr))):path)) = 
    deleteFixup $ RBZip a ((Step cb vb ToRight (Node Black vc (Node Red vd e scl) scr)):path)
deleteFixup (RBZip a path) = RBZip (setBlack a) path

Сейчас анонiмус выкатит реализацию несбалансированных деревьев на js в 20 строк и начнет боярского из себя строить. А мы как всегда будем тыкать пальцами и закрывать лица ладошками.

ну так объясни, чего я не понимяю

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

а так-то да - те же if/cond

а так-то да - те же if/cond

Да чо уж там, любой синтаксис — те же машинные коды.

Да чо уж там, любой синтаксис — те же машинные коды.

это был мой следующий ответ

Хрена себе, там и такое завезут. Что-то я отстал от жизни.
PEP 0465 — A dedicated infix operator for matrix multiplication
PEP 0492 — Coroutines with async and await syntax
PEP 0484 — Type Hints

Для вас, Козлов, придуман ассемблер. Или брейнфак, если вы эстет

Для вас, Баранов, нужно научиться видеть разницу где код читаем, а где излишне усложнен.

Ну уж нет, твой код не эквивалентен тому что я привел:

<<?REQUEST, Index:32/big, Begin:32/big, Len:32/big>> ->
    {request, Index, Begin, Len};

Этот код матчит блок байт размером строго 13 байт, создает переменные Index, Begin, End и зачитывает в них 3 big-endian числа и выплевывает кортеж.

Так что приведи аналогичный код который:

1. Может распарсить 11 типов сообщений

2. Проверяет корректность размера сообщения (на основе его тега)

3. Создает соответсвующие структуры данных (конвертируя при необходимости big-endian в little-endian)

Для вас, Баранов, нужно научиться видеть разницу где код читаем, а где излишне усложнен.

Если для вас, Козлов, паттерн матчинг - это излишнее усложнение, просто смените работу.

Ну так что, ответ про «нужность» паттерн-матчинга будет?

Ответ тебе? Нет, конечно. Объяснять тебе что-нибудь - бесполезная трата времени.

Нужен паттерн матчинг.

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

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

Да, Капитан. Конечно, Капитан. Я, правда, не вижу большой пользы в этой фиче (в отличие от extended iterable unpacking), но вы безусловно правы, Капитан.

Мы уже три года только Python 3 используем. Смысла в Python 2.7 ветке нет.

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

Ну как и в этом трэде...