Технічні статті й дайджести

\ та / є спеціальними символами, що розділяють директорії у шляху до файла, тому ім’я файлу не може їх містити. Чому не можуть, хтось забороняє?

купою ложних висновків. яких саме?

Бачив я таких відмінників, developer.mozilla.org/...​ssary/Idempotent#see_also, які вважають, що конвенції то для слабаків.

Ви праві, це більше як моя звичка, бо брав приклад зі старого проєкту . from pathlib import Path CUR_DIR = Path(__file__).resolve().parent APP_PATH = CUR_DIR / ’YourApp.app.zip’

\ та / є спеціальними символами, що розділяють директорії у шляху до файла, тому ім’я файлу не може їх містити. На Windows використовують \, а на Linux — /, але MSBuild на обох платформах розуміє і /, і \.

От саме до цього імпорту і питання чому ос, а не from pathlib import Path

Вітаю) from os import path

Вітаю Чому саме модуль ОС обрали а не більш узагальнюючий Path? Pep 428 ніби його рекомендує

“..\Service1.Contracts\Service1.Contracts.csproj” C:/Program Files/dotnet/packs/Microsoft.NETCore.App.Ref/7.0.14/ref/net7.0/System.Console.dll" Є якісь плавила, як писати шляхи? Як воно обробляє \ та . у імені файла/директорії?

ну я не згоден з тим, що це неважливо. є багато сценаріїв коли це буде працювати. але ж автор не зміг показати нащо він потрібен взагалі.

що сам тут вогонь?

саме так. огляд автора дуже однобічний з купою ложних висновків.

ага, тобто проблеми для випадків, коли виконання одного графкульного запиту виходить за межі одного серверу. Зрозумів. дякую.

graphQl по дефолту закривається одним POST API, можна його ділити і трохи намагатися в раціональність, але це все спроби повернути плюси REST. Обслуговувати не однаково, справа в тому, що запт від графу може містити декілька додаткових запитів.

хм. завжди думав, що graphQl відрізняється від ресту чи грпц в основному системою запитів.