Python-сообщество

Думаю, у тебя идёт смесь разных тем при изучении. Это якобы экономит время обучения и тому подобное. Из-за этого ты не можешь ни одну из них полностью изучить, так как другие темы мешают. Это вредно потому, что будешь изучать всё и будешь знать всё это поверхностно. Тебя спросят Гит, ты его функции поверхностно назовёшь, а глубже ты не знаешь. Тебя спросят IDE, ты её функции поверхностно назовёшь, а глубже ты её не знаешь. Тебя спросят про тесты, ты их поверхностно назовёшь, а глубже ты их не знаешь. Тут понятие “спросят” означает, что они тебе понадобятся где-то, а понятие “не знаешь” означает, что ты не сможешь продвинуться в каком-то деле. Это как знать половину таблицы умножения только. Это нормально и экономит память и время изучения очень классно на первый взгляд, но когда сталкиваешься с примерами в старших классах, молишься, чтобы там сложных цифр не было из той части таблицы умножения. И когда они там появляются, ты пример решить не можешь, хотя знаешь, как он решается вообще. А проблема в том, что ты не можешь перемножить числа, а калькулятор сломался или забыт дома. Вот какая-нибудь мелочь затормозит тебе весь процесс.
Пример:
Не знаешь, как какие-то ветки слить в Гите - и придётся весь проект многогодичный выбрасывать, придётся его превращать в сегодняшний, сделанный за один день. Естественно, вся история улетела, все многостраничные описания в коммитах улетели. Вот Линус Торвальдс любит по несколько страниц в одном коммите написать ценной информации всякой. Сидишь, читаешь один коммит полдня. Вот это всё может пропасть только из-за незнания того, как в Гите что-то там выдрать из проекта. Мне так пришлось один проект переначинать свой. По неопытности туда пароль занёс и вырезать его так и не смог из структуры репозитория через пару прошедших лет. Гит просто отказывался выполнять операцию по переделке этих деревьев. Там нужно было сам коммит раскладывать на части, так как он таким, собранным объектом является из разных кусочков, потом переделывать содержимое, а потом это обратно собирать и закоммичивать этот видоизменённый коммит заново. А чтобы выполнить эту операцию, нужно было более глубокое понимание Гита, которого у меня не было тогда, больше всяких знаний. И времени на это не было, чтобы всё это изучать сидеть. Пришлось всю эту историю проекта коммитов на триста со всеми объяснениями в коммитах (где, что и почему делал) удалить, а потом создавать проект типа “здрасьти, я проект, сделанный за один день”. Просто историю проекта не проследишь. А в коммитах бывают многие мысли про плюсы и минусы решений.
Почитай просто какой-нибуд репозиторий типа линуксового ядра, там много всякой инфы в коммитах. Там же и учишься их писать правильно , потому что многие ребятки ничего умного выдавить из себя не могут, только “пофиксил баг” или “добавил файл”. Очень часто такие говнорепозитории можно увидеть на GitHub'е. Человек пишет библиотеку или ещё что-нибудь, а работать с ним вместе бессмысленно, так как у него мозгов нет, чтобы просто объяснить, что он делает, и по коммитам его это очень хорошо видно. Так он и заканчивает обычно - с дохлым проектом, который никому не нужен, потому что никто не будет разбираться, как он там работает.

Ocean
Я хочу для практики тесты и к простым писать сейчас, чтобы навык до автоматизма довести и библиотеку освоить хорошо, и кейсы уметь годные.

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

Ocean
Я сначала писала ну как давно на паскале учили, не вникая особо в нейминги

Ocean
Тут сразу спрошу, раз речь про доки зашла: я уже тренируюсь докстринги писать. Чтобы нарабатывать навык, а не потом страдать, как с именами. Это рано еще?
Примерно в таком духе:

  
def cube_lateral_area(edge):
    """Calculate area of a cube lateral surface using cube's edge size
 
    :argument: edge(int): size of cube edge
    :return: (int): a cube lateral surface area
    """
    return 4 * edge **2

Ocean
Вот когда нет определенного имени переменной у того, что функция возвращает, но я хочу тип возвращаемого указать как правильно это сделать?

  
import math
help(math.cos)

cos(...)
    cos(x)
    
    Return the cosine of x (measured in radians).

  
import re
help(re.search)

search(pattern, string, flags=0)
    Scan through string looking for a match to the pattern, returning
    a match object, or None if no match was found.

Ocean
в задании коварно дан коэф с именем l, который я не восприняла проблемой, глядя на само задание, но в процессе решения IDE мне напомнила, что это же ambiguous variable и нарушает договоренности о стиле кода! Теперь я это запомню осознанно

Ocean
мне пришлось вспомнить и проверить встроенные функции python и осознанно импортировать нужные логарифмы из math

  
>>> import math
>>> import cmath
>>> 
>>> math.cos
<built-in function cos>
>>> cmath.cos
<built-in function cos>
>>> 
>>> math.sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> cmath.sqrt(-1)
1j
>>>

Ocean
У меня была еще одна группа “нелюбимых” задач: про побитовые операторы и переводы из одной системы счисления в другую.

Ocean
Я год не могла понять в чем проблема с Pycharm

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

Отредактировано py.user.next (Май 9, 2021 01:36:08)

py.user.next
Ну, неправильно решено.

Ocean
так озадачилась
Еще не вижу ошибки, но найду ее.

Отредактировано py.user.next (Май 9, 2021 01:22:05)

py.user.next
Кажется нашла и надеюсь, что все!)

Ошибки нашла в вычислении b.
а) Мой код находил l в -1 степени, потом делил полученное на 3
б) был неправильный знак степени х/6
в) вместо х/6 в степени -2, сперва 6 возводилась в степень, а потом х делился на 36. Для частного случая, когда х = 1 , а степень четная ответ случайно получается правильный просто добавлением пропущенного минуса. Но при смене набора исходных данных программа печатать ответы не перестанет, но будет выдавать говно.

Еще подумала, что ошибка что в натуральном логарифме не указала явно базу base = math.e, но проверила справку посмотрела и там четко указано, что: If the base not specified, returns the natural logarithm (base e) of x. Так что тут теперь уверена, на 100 процентов, что ошибки нет)

Нашла свой пробел в понимании как работают синусы / косинусы
В задаче градусы не указаны в условии, значит я решила, что х задан в радианах и дальше работала с радианами, не задумываясь. Но когда ты сказал об ошибках, то тут то и прилетело в голову, а надо ли мне было это переводить в градусы или нет для вычисления?
math.sin(math.degrees(x)) и math.sin(x) - это разные ответы. Как правильно, я не знаю С косинусом та же петрушка.
я понимаю, что math.sin и math.cos берут че угодно и ответ возвращают в радианах, но не понимаю что от меня ждут в этой задаче До этого я была уверена что радианы ок.


Что имеем в итоге: импортирование модуля math поменяла, найденные ошибки исправила. C sin/cos в непонятках

  
# Calculate y1 and y2 if x = 1, K=3, L=0.027
import math
x = 1
k = 3
el = 0.027
def calculate_a(x, k):
    a = k * math.sin(x) + math.cos(x)
    return a
def calculate_b(x, k, el):
    b = (el ** (-1/3) - (x/6) ** -2) * math.log(k)
    return b
def calculate_y1(a, b):
    y1 = math.log10(abs(a - 2 * b))
    return y1
def calculate_y2(a, b):
    y2 = math.log10(abs(a - b * a))
    return y2
coefficient_a = calculate_a(x, k)
coefficient_b = calculate_b(x, k, el)
root_y1 = calculate_y1(coefficient_a, coefficient_b)
root_y2 = calculate_y2(coefficient_a, coefficient_b)
print(f'a = {coefficient_a}')
print(f'b = {coefficient_b}')
print(f'y1 = {root_y1}')
print(f'y2 = {root_y2}')

py.user.next
Ну да, я указывать не стал их. Я-то их вижу, мне учиться находить их не надо. А тебе надо научиться. Вот ты написала её неправильно и тебе показалось, что она правильно написана. Так что надо определить: 1) откуда они возникли, как ты их допустила; 2) почему они остались незамеченными, как ты проверяешь работу свою. Вот эти вещи надо скорректировать. И вот для этого эта задача тупая и нужна. Полезного-то она ничего не вычисляет, она просто тебя учит вот этим базовым вещам.

py.user.next
Так что надо определить: 1) откуда они возникли, как ты их допустила; 2) почему они остались незамеченными, как ты проверяешь работу свою. Вот эти вещи надо скорректировать.

Отредактировано Ocean (Май 9, 2021 14:32:51)

py.user.next
Да, вот она как раз показывает тебе же самой, что ты не умеешь делать. Так ты узнаёшь, что ты не умеешь делать. Пока ты не делаешь, тебе кажется, что ты умеешь делать. Это вот разница между ожиданиями и реальностью. Поэтому и нужно их все прорешивать, чтобы банально свои пробелы знать, которые скрыты от тебя. Потому что из-за когнитивных искажений мозгу кажется, что он всё знает и всё умеет.

py.user.next
А когда ты узнаёшь, что не умеешь, тебе, конечно, неприятно от этого, но при этом ты попадаешь в состояние “мне придётся научиться”. И тогда начинается старт обучения. Потом это неприятное состояние проходит - злость эта всякая, материть перестаёшь этот язык, эти примеры дурацкие. И потом в спокойном и чистом, просветлённом состоянии ты начинаешь учиться делать. И у тебя появляется шанс действительно научиться это делать,а не в фантазиях своих уметь это делать.

py.user.next
Радость от решённой задачки и написанной программки пройдёт, а останется вот эта программа с ошибками. И их надо будет исправлять потом, так как никто их не будет исправлять и сами они тоже не исправятся. Вот такие программки у тебя накопятся и нужно будет исправлять уже не одну, а сто таких программок. Это называется технический долг. И он будет только расти и давить на тебя. Тебе будет хотеться всё бросить. Поэтому с него надо заранее снимать слои, чтобы он как можно меньше был по весу. Чем меньше он весит, тем меньше он на тебя давит. Чем меньше он на тебя давит, тем больше у тебя сил на разработку остаётся. Тебе легче. А когда тебе легко, ты легко всё делаешь. Всё делается и тебе легко.

py.user.next
Думаю, у тебя идёт смесь разных тем при изучении. Это якобы экономит время обучения и тому подобное. Из-за этого ты не можешь ни одну из них полностью изучить, так как другие темы мешают. Это вредно потому, что будешь изучать всё и будешь знать всё это поверхностно. …. Вот какая-нибудь мелочь затормозит тебе весь процесс.

py.user.next
Вот Линус Торвальдс любит по несколько страниц в одном коммите написать ценной информации всякой.

py.user.next
А чтобы выполнить эту операцию, нужно было более глубокое понимание Гита, которого у меня не было тогда, больше всяких знаний. И времени на это не было, чтобы всё это изучать сидеть. Пришлось всю эту историю проекта коммитов на триста со всеми объяснениями в коммитах (где, что и почему делал) удалить, а потом создавать проект типа “здрасьти, я проект, сделанный за один день”. Просто историю проекта не проследишь. А в коммитах бывают многие мысли про плюсы и минусы решений.

py.user.next
Да хочется всё и сразу. Не, может показаться, что это простая тема. Но это не простая тема. Там за этим стоит математика. И чем лучше ты видишь эту математику за тестами, тем чище у тебя тесты. Тесты тоже можно дерьмово написать. Наличие тестов ни о чём не говорит. Они банально могут нихера не проверять. Тесты есть, они пишут, что всё окей, а там дрова. Мало ли что они пишут.

py.user.next
Гит - вообще сложнейшая тема. Его за секунду так просто не изучишь. Его надо изучать послойно, много слоёв в нём.

py.user.next
Короче, это туфта всё. Ты ничего уметь не будешь. И эта экономия времени, ради которой этой всё делается, в итоге выльется в большие затраты времени. Потому что научиться надо будет этому всему, а учиться этому придётся с нуля или с одной тысячной.

py.user.next
Именование - это сложная тема. Там много всяких стилей. Где-то их нужно менять с одного на другой и обратно. Где-то их нужно склеивать вместе. Если тебе кажется, что это простая тема - прочитал статью или главу в книге и всё знаешь, - то не, оно так не работает. Там нужно много чего прочитать и прочитать одно и то же от нескольких разных авторов, потому что кто-то что-то да забудет упомянуть. И только потом ты будешь видеть, где вот нужно это сделать, а где не нужно вот это делать, а где нужно одно заменить на другое. Всё это нужно знать к этому моменту.

py.user.next
Этот стиль пришёл с Java. Java - это другой язык. Он по-другому сделан, поэтому тащить что-то из Java в Python не надо. В Java нужно всегда знать, какой у тебя тип там передаётся или возвращается. А в Python не надо никогда знать про то, какой тип передаётся или возвращается. Поэтому вот этот стиль сделан под IDE, под Java-программистов, которым без типов ничего не понятно, под что угодно. Но к питону он отношения не имеет.

py.user.next
Хочешь написать, что возвращается, - пишешь своими словами.
Например

py.user.next
Никаких типов тут нет, никаких маркеров идешных тут нет. Просто пишут понятно и всё. А вот эта хрень - пометь это, пометь то, уточни это, уточни то - это всё притащено снаружи, с других языков. Типа умные ребятки решили засрать питон своими умностями и превратить его в C++ очередной, в котором они сами уже сто раз потерялись из-за загрязнённого синтаксиса. Ещё соревнуются между собой, кто лучше эту синтаксическую помойку знает Не имея ни одной программы, сидят и соревнуются в знаниях синтаксиса годами.

py.user.next
Это нужно узнавать не из IDE, это нужно узнавать из PEP8 и подобных руководств (они в разных языках бывают, называются “стилевые руководства”). Его нужно заучивать и потом наизусть знать. Иначе IDE может тебе не показать, что там есть какая-то ошибка, а она там в это время будет. Тебе будет казаться просто, что там всё правильно. А IDE может вообще не обрабатывать какие-то случаи, потому что она не обязана их обрабатывать. Особенно какие-нибудь замороченные случаи, где глубокая семантика. Слишком дорого её бывает реализовывать по времени, поэтому идешники - разработчики IDE - её могут проигнорировать, причём она будет стоять в PEP или его аналоге чуть ли не на центральном месте

Ocean
Их не надо импортировать. Надо импортировать модуль, а потом обращаться к ним по имени модуля.
Есть несколько косинусов. Они все называются cos().

py.user.next
Ну, ты просто закоммитишь такие имена заимпортированные, а потом надо будет делать функцию какую-нибудь с таким же именем и придётся сначала всё переписывать по всему коду, а затем перекоммичивать эти переписанные имена в связи с импортом модуля и использованием его как пространства имён для этих функций или переменных. Фактически при импорте модуля тебя придётся отредактировать все функции, в которых эти заимпортированные функции используются. И после этого ты не сможешь откатывать коммиты в репозитории, потому что всё по десять раз переписано в одном месте.

py.user.next
Бывает, что переделываешь эти ветки сидишь, чтобы просто бардак убрать в репозитории, и не можешь этот один коммит перебросить из одной чистенькой ветки в другую, потому что он зацеплен за что-то. Короче, грязные репозитории, переполненные лишними коммитами, бывают. И это трэш полный, потому что это всё потом тянется и хранится. И ты не можешь почистить такие репозитории из-за кучи вот таких ненужных правок, которых можно было бы избежать, соблюдая просто все правила изначально. Про такие репозитории и говорят потом “ну, а что мы сделаем? вот эта грязная куча из коммитов не подлежит очистке, ещё сломается что-нибудь”. И потом тянут туда-сюда мегабайты, гигабайты всякой ненужной херни, копируя это по сто раз.

py.user.next
Битовые операции очень важны. Все устройства, порты, сетевые пакеты, заголовки файлов (архивы, экзешники, графика, базы данных, файловые системы) хранят и передают информацию в виде битов. Допустим, у тебя есть опции какой-то фигни в программе, хранить ты их будешь в одном числе в виде битовых флажков. Никто не делает 100500 переменных, чтобы все опции хранить в виде True/False. Просто в одном числе хранятся все опции и это число потом быстро везде передаётся, пересылается по сети, по кабелю и так далее.
Системы счисления просто учат тебя работать с числами, как и множество других задач числодробительных. Это даёт мышление алгоритмами. Это учит работать с полиномами как с массивами немножко. На полиномах вообще много чего построено. Вся эта графика ужатая - это всё полиномы.

py.user.next
Начинать надо с блокнота. А Pycharm может пропасть. Как только она пропадёт, ты останешься полностью без рук. Подключишься на сервер, там нужно будет с кодом поработать, а Pycharm не запускается, так как оконной системы нет. Зато куча блокнотов консольных доступна практически отовсюду, а ты в них работать не умеешь, потому что они там за тобой сопельки не подтирают, тут за тобой сопельки не подтирают и думать обо всём теперь нужно самому (раньше за тебя среда думала), а у тебя нет этих навыков. В итоге вся твоя работа разваливается. Как с невыученной таблицей умножения - стопор и всё.

py.user.next
То есть IDE после блокнота должна быть, а не вместо блокнота. Как и тесты должны быть после мозгового дебаггера, а не вместо мозгового дебаггера. Я вот твою программку тестами не обкладывал, я её просто в голове у себя запустил и всё - ошибки посыпались.

py.user.next
Не, тебе свои файлы надо заводить.

py.user.next
На каждую книжку - новую директорию с файлами, на каждый ресурс - новую директорию с файлами.

И там везде заметки оставлять. На книжку делается файл конспект книжки и файл прохождения книжки, также могут сохраняться какие-то картинки из книжки.

Для этого всего директория и нужна, которая объединит это всё, как модуль объединяет функции воедино вокруг чего-то общего. На ресурс делается файл заметок. В файле заметок идёт адрес и информация, которая лежит по этому адресу (сохранять информацию можно целиком, а можно только описание этой информации сохранять). Адрес этого топика, например, - это число 40288. Его легко сохранить, как и список таких адресов. Ты любой топик открываешь на форуме через год-два-три и там просто число в адресной строке заменяешь на 40288.

То есть это не напряжно. Можно и ссылки сразу сохранять, но они будут длиннее фигурировать и больше места занимать. И потом ты эти файлы конспектов, заметок, картинок, примеров можешь обвесить скриптами Эти скрипты могут транслировать эти файлы в HTML-страницы, которые можно в браузере просматривать. Также их можно выкачивать скриптами куда-то автоматом и там потом просматривать. Короче, не программистское у тебя мышление пока, поэтому у тебя и организация деятельности пользовательская. Ты пользуешься только тем, что тебе дали. А сама себе дать что-то ты пока не можешь. Но программист он вот так и делает - он создаёт себе инструменты и пользуется ими, и никто ему не нужен. Я себе просто на одном форуме расширение для браузера сделал и просто оно мне всё делает и меняет, как надо мне, а причуды тамошних админов, что они там напридумывали в очередной раз, мне побоку - моё расширение сделает всё, что нужно мне.

Вот для создания директорий для всяких ресурсов можешь на облаке https://drive.google.com создать документ xls и туда сохранять ссылки и информацию. На любые ресурсы. Обычно папку делаешь для ресурса и заполняешь её документами, HTML-страницами, текстовыми файлами, картинками. Картинки тоже изготавливаешь, потому что иногда лень перенабирать какую-то информацию, проще сфотографировать экран и соединить вместе несколько картинок с формулами. Так ты сможешь смотреть и с компа там инфу, и со смартфона. Иногда нужно быстро что-то вспомнить записанное, а комп выключен. Поэтому смартфон тоже должен доступ иметь к этим данным.

Главное, всё в одном место не писать. Как учиться нужно каждой теме по отдельности, так и сохранять информацию нужно тоже для каждого ресурса по отдельности и не скупиться ни на папки, ни на файлы. Лучше раздельно всё иметь, чем в виде такой “удобной” и “экономной” каши.