Не

В теории там с точки зрения execution flow лучше явный матч

Но я ленив :(

А чем тебе питон не нравится то?

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

Я не представляю, как это всё в совокупности может нравиться.

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

Я не представляю, как это всё в совокупности может нравиться.

Ещё скоуп отступами забыл!

Ещё скоуп отступами забыл!

Конкретно с этим у меня проблем не было. Но, таки да, волшебные ключевые слова global и nonlocal тоже позволяют супер запутать код со скоупами :)

Конкретно с этим у меня проблем не было. Но, таки да, волшебные ключевые слова global и nonlocal тоже позволяют супер запутать код со скоупами :)

Ну :) я намекал, что и у нас - тоже :)

Ну :) я намекал, что и у нас - тоже :)

У нас нету всех этих магических кейвордов, а всё из коробки работает ожидаемо. Благодаря статической типизации, да.

У нас нету всех этих магических кейвордов, а всё из коробки работает ожидаемо. Благодаря статической типизации, да.

вместо кейвордов куча непонятных стрелочек покруче кейвордов

и можно делать свои!

вместо кейвордов куча непонятных стрелочек покруче кейвордов

Да чота, вроде как, у нас только одна стрелочка в синтаксисе.

ой да ладно

Но свои можно наделать, да.

-> горизонтально |> вертикально » сломалась

тут кстати Википедия говорит, что поддержку F# выпилили из MSVS

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

ВРЕТИ

ВРЕТИ

Ё

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

Есть готовые сборки, типа anaconda, где все проблемы с разделением версий пофикшены. Я много работал с этим, и ни одной проблемы не заметил. Писал я тоже только на одной версии - 3.7, и всё ок. Лямбды да, стрёмные, в остальном жить можно, типизация в разы лучше чем у жс. Не нужно ставить 100500 пакетов, много всего есть в стандартной библиотеке.

маленький конечный автомат подойдёт, попробую придумать какой-то осмысленный

Conway's Game of Life

Там на 15-20 минут максимум надо задачку 🤔

Как вам название бренда?

Это английская корона?

В смысле?! Там ж всего то минут 5 работы

Как вам название бренда?

Задумка гуд, надо развить соответствующими деталями

Это английская корона?

Неважно, название смотри :)

k

Задумка гуд, надо развить соответствующими деталями

Ага, слоганом «злаки желают зла» 😂

Ага, слоганом «злаки желают зла» 😂

Черчилль, Рейган, Хрущев, железный занавес...

можно удачно кое-что закрыть или замазать

Есть готовые сборки, типа anaconda, где все проблемы с разделением версий пофикшены. Я много работал с этим, и ни одной проблемы не заметил. Писал я тоже только на одной версии - 3.7, и всё ок. Лямбды да, стрёмные, в остальном жить можно, типизация в разы лучше чем у жс. Не нужно ставить 100500 пакетов, много всего есть в стандартной библиотеке.

Анаконда — просто ещё один стандарт. Она не поможет тебе написать плагины для саблайма.

Анаконда — просто ещё один стандарт. Она не поможет тебе написать плагины для саблайма.

Так там же одна единственная версия питона, на ней и писать, не пойму, в чём сложности

Можно ли конвертнуть такую дичь: Expression<Func<T, LocalizableString>> propertyOrMethod В такую: Expression<Func<T, object>> propertyOrMethod ?

(object)

Такой вариант не прокатит: var compiled = exp.Compile(); Expression<Func<T, object>> e = (a) => compiled(a);

Явный каст сделай

Явный каст сделай

Нельзя говорит

Func контравариантен, Expression инвариантен - нельзя

Щас вот так попробую: var exp = Expression.Lambda<Func<T, object>>(propertyOrMethod);

Неа, не прокатывает

Заверни expression в expression

Такой вариант не прокатит: var compiled = exp.Compile(); Expression<Func<T, object>> e = (a) => compiled(a);

.

Можно сделать return x => x;

Дичь какую- то пишешь

Там специфика такая, что указывается пропертя или поле

И если там будет не пропертя, или поле, тогда бросит эксепшн

Ну ты бы подробнее тогда рассказал, что за херь

СУдя по героическим попыткам, творится херня

Перегрузки не рассматриваются?

Ну я конечно могу сделать на входе Expression object, мне ничего не мешает, но хочется по правильному сделать, чтобы были ошибки в случае чего во время компиляции, а не в рантайме

Ничо не дичь

https://stackoverflow.com/questions/31328693/changing-the-return-type-of-an-expressionfunc

Вот есть такое решение

Если начать спрашивать - зачем вот это все, это будет сильно бестактно?

Есть такая библотека для GraphQL, называется HotChocolate. Там типы описываются таким образом: desc.Field(x => x.Features) .Description("List of features.") .Type<NonNullType<ItemFeatureType>>(); Для возвращаемых типов обычно отдельно описывается тип, но у меня возникла задача конвертирования типа в скалярный, по заданному условию. Чтобы одно и то же не писать по 100 раз, я сделал Extension метод: public static IObjectFieldDescriptor LocalizableString<T>( this IObjectTypeDescriptor<T> descriptor, Expression<Func<T, LocalizableString>> propertyOrMethod) { var compiled = propertyOrMethod.Compile(); var exp = (Expression<Func<T, object>>) new ReturnTypeVisitor<T, object>() .Visit(propertyOrMethod); return descriptor .Field(exp) .Resolver(x => { var context = x.Service<HttpContext>(); var value = compiled(x.Parent<T>()); var language = HttpContextUtility.ExtractLanguage(context); return value?.GetOrDefault(language) ?? string.Empty; }) .Type<StringType>(); } И вызываю его так: desc.LocalizableString(x => x.Name) Как ты видишь, метод Field принимает в качестве аргумента Expression<Func<T, object>>, а у меня тип Expression<Func<T, LocalizableString>>.

Как я уже сказал да, я могу в качестве аргумента использовать Expression<Func<T, object>>, но тогда похерится компайл тайм проверка, а это очень плохо.

Если кейсов всего 2, то почему бы вместо универсальных портянок не сделать две короткие перегрузки?

Если кейсов всего 2, то почему бы вместо универсальных портянок не сделать две короткие перегрузки?

Не совсем понял о каких кейсах бы

Ну, тебе нужно отдавать либо свойство, либо поле, верно?

Или я не так понял задачу?

Ну, тебе нужно отдавать либо свойство, либо поле, верно?

Да, могут быть любые свойства и поля, любых объектов

Но только с типом LocalizableString

Так там же одна единственная версия питона, на ней и писать, не пойму, в чём сложности

Ну сложность какая

У тебя единственная версия питона

У меня единственная версия питона

И вон у Василия тоже едиственная версия питона

Все три — разные

ebis

Ну сложность какая

Лучше скажи по экспрешны, можно ли проще сделать?)

Можно ли конвертнуть такую дичь: Expression<Func<T, LocalizableString>> propertyOrMethod В такую: Expression<Func<T, object>> propertyOrMethod ?

Да.

И вон у Василия тоже едиственная версия питона

Так саблайм тащит одну единственную версию и для меня, и для Василия

Такой вариант не прокатит: var compiled = exp.Compile(); Expression<Func<T, object>> e = (a) => compiled(a);

Не прокатит, конечно же, ну ты чо

Так саблайм тащит одну единственную версию и для меня, и для Василия

Я говорил про пыхотон вообще

Саблайм одну тащит, анаконда другую, вим третью

Wrap(FieldExpression<Func<T, F> > ) Wrap(PropertyExpression<Func<T, P> > ) я вот это имел в виду

Потом компилишь туда пакет, а он начинает посасывать

Я, честно говоря, вообще ценность graphql не понимаю