Какой там самый безболезненный способ получить питон в винде?

Anaconda?

Я тут вспомнил, что есть же волшебный CodingGame!

и там можно порешать задачки с помощью F#

Например

https://www.codingame.com/ide/puzzle/the-descent

дай подумать... как насчёт, чтобы СКОЧАТЬ и УСТОНОВИТЬ?

Какой там самый безболезненный способ получить питон в винде?

choco install python

Давайте я поясню тогда.

Только без с вертушки в ши!

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

Ну будет у тебя папочка c:\python27\

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

чем это он может гадить?

Вообще, если я линуксами обмазываться собираюсь, я делаю vagrantfile и пишу vagrant up

поставишь через chocolatey даже PATH не тронет

А куда pip будет либы ставить? Они system-wide будут? Как менеджить версии питона и библиотек?

Я тут вспомнил, что есть же волшебный CodingGame!

добавляйтесь в друзяшки https://www.codingame.com/profile/7a6ff61528d7feecf19ec8b56fb158d29932511

А куда pip будет либы ставить? Они system-wide будут? Как менеджить версии питона и библиотек?

слуш, ты хотел попробовать тензор. попробуешь и снесешь, зачем тебе pip?

и тем более менеджить версии

Там вроде можно сделать комнату. Что очень поможет попробовать F# в действии тем кто не хочет писать либы например)

Ну, тензор ставится через pip.

Ну, тензор ставится через pip.

только для python api же, нет?

На сайте тензора написано, что обязательно нужен питон и пип.

Отчего я и жалуюсь.

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

Мне не кажется, что это хорошая практика.

добавил в Coding games комнату /join fsharp_ru

Спасибо, чуваки, но кажется, лучший способ управляться с питоном -- это conda.

Ещё вроде из сторонних либ была Ionic gzip, или как-то так, которой насколько я знаю под кор нет

Есть замена.

чем это он может гадить?

Питон гадит своими либами себе в C:\Python2\SitePackages, и у тебя будут проблемы при несовместимости установленных либ с какими-нибудь новыми пакетами, например. Хотелось бы локально для каждого проекта каталог с либами, как в NuGet.

Спасибо, чуваки, но кажется, лучший способ управляться с питоном -- это conda.

Интересно, расскажи больше. Лучше в привате :)

Давайте не будем тут оффтопить, товарищи. Питон это отдельная история.

(да-да, я тоже наоффтопил, простите, больше не буду, сам виноват)

А замену для IonicZip я вам щас найду.

Ещё вроде из сторонних либ была Ionic gzip, или как-то так, которой насколько я знаю под кор нет

https://github.com/ForNeVeR/Jabber-Net/pull/84/files#diff-6774c1d2b732f0d43bb0de75d6d02c95R20

Я вот это юзал.

Ну ок

Но сам понимаешь, это всё тестить надо

Согласен.

Кстати, как тестить библиотеки, которые завязаны на API?

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

Ну, это для юнит-тестов.

Если хочешь тестировать интеграцию с API — ну, надо в нём искать опции по тестовой интеграции.

Для примера могу рассказать, как тестировал Trello-адаптер на Java. Просто завёл отдельного юзера и проект в настоящем Trello, и туда его натравливаю во время тестов.

На реальном апи не уверен, что хорошая идея тестить

С одной стороны да, ты будешь уверен, что у тебя всё ок проходит

ну это интеграционные тесты и будут в любом случае

С другой стороны, тесты у тебя будут затягиваться

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

В F# тогда не получится модули использовать

С другой стороны, тесты у тебя будут затягиваться

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

Да, это реальная проблема.

Телеграму бы тестовый сервер сделать)

В F# тогда не получится модули использовать

Как говаривает старина @gsomix, не нужно стремиться использовать F#-only штуки для всего. Если тебе не хватает функциональных абстракций, ты _можешь_ использовать ООП, если это уместно.

В F# тогда не получится модули использовать

А ещё, если ты грамотно архитектурируешь проект, то тебе это может и не пригодиться!

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

А потом их обернуть в класс + интерфейс?

А тестирование интеграций со внешними API, СУБД и пр. — это чёткие техничские задачи, для которых можно писать интеграционные тесты.

Я просто хз, мб это в ФП как-то по другому решается

Вот например Haskell, там же нет таких штук

А потом их обернуть в класс + интерфейс?

Ты можешь делать в ООП-стиле, а можешь в стиле "dependency rejection". Внешние API будут сами просовывать данные в твоё чисто функциональное ядро, т.е. у ядра не будет зависимости от API.

Да, над такой архитектурой надо думать, и она не будет похожа на ООП. Но сделать так можно.

Серьёзно, послушай доклад Симана про Dependency Rejection, он полезный, правда-правда.

Ну или статьи почитай.

Да забываю вечно)

Да и боюсь уровень не мой)

А вот зря боишься. Раз начал задавать вопросы такого уровня — значит, уровень твой.

Вот кстати в Go интересный подход, там неявные интерфейсы

И это было бы удобно

Это не вопросы особенностей F#, а именно вопросы архитектурные. Любой, кто делает архитектуру приложений, может их понимать и осмысливать.

В Go ты просто создаёшь интерфейс, и например указываешь его в аргументе функции, и при передаче какого-нибудь объекта в эту функцию, компилятор просто проверяет наличие методов, которые указаны в интерфейсе, у этого объекта

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

Я правда сначала плевался, но потом понял, что это удобно)

У этого есть какое-то научное название, но я его забыл. Типа "номинальная типизация" чтоли?

В тайпскрипте такая же.

Я правда сначала плевался, но потом понял, что это удобно)

это называется утинная типизация и это во многих языках есть

не, duck typing - это про динамические языки

в go это типа структурная типизация

В целом в f# можно так же констрейнты написать

В C# через dynamic :)

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

Vasily неудобно.

Подтверждаю, неудобно. Но можно.

Писанины очень много выходит с этими статическими констрейнтами.

Я, вон, выше показывал пример, как я пытался достать ^t.MaxValue, и не смог :(

Я бы не стал использовать SRTP в реальном коде.

А я использую!

Ну, самую малость.

Страшно и непонятно.

А ты понятно используй!

https://github.com/ForNeVeR/Tesla.Csxcad/blob/d83753307f653751c986c799c60c81b7da0bb6f4/Tesla.Csxcad/Utils.fs#L11-L24

Или это уже даже не считается за SRTP?

У меня сначала был этот код написан с ^TEnum, но потом на SO подсказали, что крышечка там вовсе и не нужна :)

Считается. Но я именно про констрейнты, имитации тайпклассов и прочую хурму.

Эта "хурма" на любом языке выглядит страшно. Вот в Scala посмотри на адептов scalaz или cats, и увидишь такое же мутное марево в коде :)

И при этом у них-то это куда получше выглядит, чем на F#.

Ну, я человек простой и глупый.

Все люди такие.