Здесь можно увидеть, что на оси Y расположены значения от 0 до 40
Как я могу получить их позицию по оси ординат, зная позиции точек, что изображены на оси Y?
$ git config -l | grep url
remote.origin.url=https://github.com/forthy42/gforth
$
$ grep -r -F "fthird" .
./doc/gforth.texi.in:doc-fthird
./doc/words/1.0-words:lib-sym2 lib-sym open-lib2 open-lib ffourth fthird fpick f>l >l lp! lp+2 lp+
./fold.fs: 2 of postpone fthird drop exit endof
./minos2/widgets.fs:: gdup ( glue -- glue glue ) fthird fthird fthird ;
./prim:fthird ( r1 r2 r3 -- r1 r2 r3 r1 ) gforth
Когда ты будешь изучать ООП, которое за собой тащит SOLID, Design Patterns и тому подобное ты просто увидешь что некоторые языки сознательно вводят много ограничений (в т.ч и типизация) и это в будущем помогает читать код когда он разраставется до сотен модулей и десятков тысяч классов.
Читать Python код сложнее т.к. в нем нет ПРАКТИКИ применения типов. Это часто ставит разработчика-читающего в затруднительное положение. Получается что ему недостаточно видеть сигнатуру метода а ему надо вычитать все uses и returns чтобы понять контракт.
И хотя начиная с некоторого релиза аннотации типов введены, сообщество пока не приняло эту практику и можно сказать что % использования практически равен нулю.
Я пересекаюсь с Python мало. Лишь в части Spark/PySpark. И в тех случаях когда надо по "быстрячку наговнячить" запросов к датафреймам. Но самые вкусные фичи (например DataSet) и строгий контроль типов по прежнему PySpark недоступны. И чтобы их потрогать - нужно брать Scala.
В остальном Python - хороший язык и вы можете его смело брать для украшения резюме. Но если вы хотите знать тонкости ООП то вам будет НЕДОСТАТОЧНО использовать Python. Берите специальные языки C++/C#/Java вот шаблоны проектирования как раз писались про них и тестовые примеры как раз тоже с этими языками.