Пока изучил либу поверхностно. Восторг! Теперь буду мечтать, чтобы - Либо такое встроили в штатный itertools. - Либо кто-то сделал низкоуровневую реализацию, как для numpy. Тогда скорость операций вырастет на порядки.
Спасибо, отлично разложили по полочкам. Будет удобно использовать такой взгляд для преподавания. Либу DecPy (фактически один модуль) интересно поизучать.
До этого они балуются в автоматическом тренажере - решают крохотные задачки на создание отдельных функций или даже кусков кода.
Так что "да" - это их первый реальный код. Им почти бесконечно сложно все сразу: и Питон, и ООП, и Гитхаб, и IDE - а еще и над логикой и дизайном игры нужно думать.
Это будет уже не "оверхед", а чистый "кыш отсюда" для большей части студентов. Ведь многие приходят совсем зеленые (вот как Марина в статье).
Курс рассчитан на постепенное погружение в настоящую разработку - после года обучения они уже все перечисленное: requirements.txt, ридми, линтеры и даже больше - понимают и применяют.
А в первом проекте это не нужно. Лучше не пугать, а мотивировать на обучение.
Если бы мне доверили - я точно бы заставлял делать Пентамино. Сам на разных языках писал - очень помогает понимать где в языке засада по нагрузочным вычислениям.
Есть примитивное дерево из классов для фигур, которые можно показывать: общий базовый, наследник Яблоко, наследник Змея. Метод для отрисовки фигуры лежит в базовом, а реализован в каждом из наследников.
ложная идея, что CudaText это Sublime, только лучше
Я каждый день пользуюсь CudaText и вижу, что для меня он лучше Sublime. Несколько раз пробовал пересесть и ни разу не получилось улучшить рабочую среду. И, что важно, я не пытаюсь утверждать, что Sublime и vim не нужны.
В статье нет посыла "CudaText лучше Sublime". Лишь перечислены идеи для улучшения Sublime. Да, идеи опробованы внутри CudaText, это лишь придает им больше веса и рекламирует CudaText на фоне Sublime.
Полностью согласен. Но нигде не вижу, чтобы в комментариях это кто-то оспаривал. Вы пытаетесь жестко доказать, что идеи из статьи вам не подходят. А никто их вам и не пытается навязать. Речь была, про то, что «скорее всего, найдется много пользователей, кому это будет удобно».
Про «мышь только мешает». Вы не угадали. Такого предположения мы с Алексеем не делали.
Про «инструмент для юникод-символов». Спасибо за ссылку, поизучаем.
Про «в этом вашем». Постарайтесь избегать подобного тона.
Про «vim». В Cuda нет такого, и много еще чего нет. Это не мешает его пользователям.
Да, замечательная вещь — доп.потоки у файлов. Давно на них облизываюсь. Например, удобно хранить в них всю историю изменений файла, то есть данные для undo/redo. Но теги — нет, так как к ним имхо нужен ручной простой независимый доступ.
(Учтите, что я тут про теги пишу как диванный аналитик. Это не у меня, а у ovsale есть программа для работы с тегами)
Мягкие и жесткие ссылки в Файловой Системе дают для некоторых файлов альтернативные пути хранения. Дерево превращается в Сеть. Но, насколько я знаю, у пользователя нет простого способа увидеть и использовать все эти альтернативы, если он видит конкретный файл. Если в пути к файлу одна из промежуточных папок (в том числе и последняя) станет результатом новой ссылки, описание файла никак не изменится.
То есть ссылки — это исключительно про папки.
А теги — это про свойства файлов.
Пока изучил либу поверхностно. Восторг!
Теперь буду мечтать, чтобы
- Либо такое встроили в штатный
itertools.- Либо кто-то сделал низкоуровневую реализацию, как для
numpy.Тогда скорость операций вырастет на порядки.
Спасибо, отлично разложили по полочкам. Будет удобно использовать такой взгляд для преподавания.
Либу
DecPy(фактически один модуль) интересно поизучать.Отличная подборка. Буду рекомендовать студентам.
До этого они балуются в автоматическом тренажере - решают крохотные задачки на создание отдельных функций или даже кусков кода.
Так что "да" - это их первый реальный код. Им почти бесконечно сложно все сразу: и Питон, и ООП, и Гитхаб, и IDE - а еще и над логикой и дизайном игры нужно думать.
Это будет уже не "оверхед", а чистый "кыш отсюда" для большей части студентов. Ведь многие приходят совсем зеленые (вот как Марина в статье).
Курс рассчитан на постепенное погружение в настоящую разработку - после года обучения они уже все перечисленное: requirements.txt, ридми, линтеры и даже больше - понимают и применяют.
А в первом проекте это не нужно. Лучше не пугать, а мотивировать на обучение.
Если бы мне доверили - я точно бы заставлял делать Пентамино.
Сам на разных языках писал - очень помогает понимать где в языке засада по нагрузочным вычислениям.
И еще алгоритмические скилы прокачивает.
Ага. Так и происходит
Ох! Десятки их!
Чего только не выдумывают. Хорошо известно, что новички выдумывают такое, что опытным никогда в голову не придет.
Но если змея бегает и ест яблоки, то все это считается правильным.
Есть примитивное дерево из классов для фигур, которые можно показывать: общий базовый, наследник Яблоко, наследник Змея. Метод для отрисовки фигуры лежит в базовом, а реализован в каждом из наследников.
На Win-ноуте не видит штатную клавиатуру после скачивания портабельной версии. Это нормально?
Полностью согласен. Но нигде не вижу, чтобы в комментариях это кто-то оспаривал. Вы пытаетесь жестко доказать, что идеи из статьи вам не подходят. А никто их вам и не пытается навязать. Речь была, про то, что «скорее всего, найдется много пользователей, кому это будет удобно».
Это многое проясняет — вы не попадаете в целевую группу. У тех, кто не может пользоваться vim, отношения с Cuda/Sublime складываются удачнее.
Про «инструмент для юникод-символов». Спасибо за ссылку, поизучаем.
Про «в этом вашем». Постарайтесь избегать подобного тона.
Про «vim». В Cuda нет такого, и много еще чего нет. Это не мешает его пользователям.
Да, можно завести свои спецподстановки в регулярки. Теперь голова начнет переваривать эту идею.
Но ваш пример мне не понятен. Что можно упростить, в какой регулярке?
Нигде в основном тексте явно не было указано — имейте ввиду, что мой плагин ищет только внутри отдельных строк.
Да, замечательная вещь — доп.потоки у файлов. Давно на них облизываюсь. Например, удобно хранить в них всю историю изменений файла, то есть данные для undo/redo. Но теги — нет, так как к ним имхо нужен ручной простой независимый доступ.
(Учтите, что я тут про теги пишу как диванный аналитик. Это не у меня, а у ovsale есть программа для работы с тегами)
Мягкие и жесткие ссылки в Файловой Системе дают для некоторых файлов альтернативные пути хранения. Дерево превращается в Сеть. Но, насколько я знаю, у пользователя нет простого способа увидеть и использовать все эти альтернативы, если он видит конкретный файл. Если в пути к файлу одна из промежуточных папок (в том числе и последняя) станет результатом новой ссылки, описание файла никак не изменится.
То есть ссылки — это исключительно про папки.
А теги — это про свойства файлов.
ovsale Правильно я понял, что у вас теги имеют не более одного родителя? (смотрите мой пост "Обычная иерархия файлов — это...")