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

Слово лучше, бредовые это конечно круто, но давайте более аргументировано)

Видите ли это позиция. Понимаете? Подход. Он лучше потому что это базис, из-за которого создавался питон. Код читается чаще чем пишется. Следовательно, явное - лучше неявного, ибо более читабельно.

даже если скажем в той же джанге тысячу и один раз из проекта в проект повторять дикие импорты типа
from django.contrib.contenttypes.models import ContentType

Ну, я сейчас просто расплачусь.
1. Вы очевидно утрируете
2. Я сейчас посмотрел несколько своих проектов на джанге - не заметил такой тенденции.

а импорты это не дествующий код?

Нет. Это, фактически, ссылки на действующий код.

А в чем смысл?) в том что это “круто” или “лучше” ?)

Не надо троллить.
Смысл у него не в том что бы не писать одинаковые строчки, а в том, что бы
“Каждый фрагмент знания должен иметь единственное, однозначное, надёжное представление в системе”
Импорты - по сути ссылки на это представление.

Скрытые импорты - плохо для читабельности и ясности в анализе кода.

Мне интересно - вы сознательно “клеете дурака”, делая вид, что не понимаете о чём я?

Отредактировано (Дек. 26, 2009 20:34:51)

Ferroman
Код читается чаще чем пишется. Следовательно, явное - лучше неявного, ибо более читабельно.

Ну и чем так сложнее читать информацию не из верха файла, а из другого места, причем я не понимаю почему если человек увидит в коде проекта джанги ContentType ему может понадобится вот это - from django.contrib.contenttypes.models import ContentType это что так неоднозначно? ContentType имеет кучи разных значений чтобы постоянно это иметь рядом полный путь к нему? в 99% случаев это никому не надо. следовательно это информация только осложняет чтение)

Ferroman
Нет. Это, фактически, ссылки на действующий код.

Для интерпретатора это обычная директива сделать определенное действие - точно такой же выполняющийся код, который создает объект модуля, не надо приписывать тут что-то особенное этому фрагменту. Это никакая не ‘ссылка’ это точно такой же выполняющийся код.

Ferroman
Смысл у него не в том что бы не писать одинаковые строчки, а в том, что бы
“Каждый фрагмент знания должен иметь единственное, однозначное, надёжное представление в системе”
Импорты - по сути ссылки на это представление.

И при чем тут это? в чем тут неоднозначность моего варианта? читаете его из другого места он там однозначно надежно, четко и единственно определен.

Ferroman
Скрытые импорты - плохо для читабельности и ясности в анализе кода.

В 99% случаев само имя много говорит а сущности - если нет значит оно плохо подобрано. Весь путь до этого излишен. И по сути это детали реализации которые можно и спрятать. клиентскому коду не обязательно знать что есть куча вложеных модулей в которых расположено описание какой то сущности - ему нужна сущность в нужный момент и все, а не весь путь до нее. Вспомните IOC и подобные вещи когда все зависимости максимально прячутся и доставляются по требованию. В случае импортов все сверху жестко захардкорено в файл, вам почему-то такой подход по душе)

Ferroman
Мне интересно - вы сознательно “клеете дурака”, делая вид, что не понимаете о чём я?

Я понимаю о чем вы. И то что по сути это мелочь и не так уж сложно и напряжно явно все определить, но не надо выворачивать что если есть такая ‘позиция’ то это значит что все остальное ‘хуже и бредово’ приводя какие то аргументы о читаемости, это не читаемость это избыточность читаемости.

перед тем как опровергать подумайте головой, и конкретными аргументами а не фразами ‘хуже’, хотя можете молится на какую то там свою (или не свою) позицию.

Отредактировано (Дек. 26, 2009 21:40:37)

в 99% случаев это никому не надо. следовательно это информация только осложняет чтение)

Это вы так решили. Вам так удобно. Мне это нужно, и мне гораздо более удобно смотреть что откуда импортируется в файле, в котором я непосредственно работаю, а не где бы то ни было ещё.
Следовательно это вопрос вкуса. Вкусы большинства питонистов отличаются от вашего.
Делайте выводы.

И при чем тут это? в чем тут неоднозначность моего варианта? читаете его из другого места он там однозначно надежно, четко и единственно определен.

В том-то и дело, что писать в одном месте, а смотреть в другое, особенно при коллективной разработке, черевато последствиями.
Выше писал почему мне предпочтительнее в одном файле. Как и всех известных мне питон программистов.
Но я не буду вас переубеждать. Хотите писать в пхп-стиле на питоне - дело ваше.

Вспомните IOC и подобные вещи когда все зависимости максимально прячутся и доставляются по требованию.

Что я должен вспомнить?

В случае импортов все сверху жестко захардкорено в файл, вам почему-то такой подход по душе)

Не вижу проблемы.
Мне по душе явность.

В 99% случаев само имя много говорит а сущности - если нет значит оно плохо подобрано. Весь путь до этого излишен.

Вам излишен. Мне нет.

Для интерпретатора это обычная директива сделать определенное действие - точно такой же выполняющийся код, который создает объект модуля, не надо приписывать тут что-то особенное этому фрагменту. Это никакая не ‘ссылка’ это точно такой же выполняющийся код.

Значит вы всё-таки сознательно “клеете дурака”. Мне всё равно как это работает на уровне интерпретатора. Для программиста импорт - просто отсылка к коду размещённому в другом месте. Собственно импорт - основной инструмент в обеспечении самого DRY принципа.
Перечитайте значения понятия DRY больше 1-го раза.

Я понимаю о чем вы. И то что по сути это мелочь и не так уж сложно и напряжно явно все определить, но не надо выворачивать что если есть такая ‘позиция’ то это значит что все остальное ‘хуже и бредово’ приводя какие то аргументы о читаемости, это не читаемость это избыточность читаемости.

Значит. В рамках системы созданной в расчёте на такую позицию.
Читабельность - всегда компромисс между краткостью и излишеством. Вы думаете что полный импорт - излишество. Я так не думаю.
Я так понимаю, так не думает и дизайнер языка.

перед тем как опровергать подумайте головой, и конкретными аргументами а не фразами ‘хуже’, хотя можете молится на какую то там свою (или не свою) позицию.

1. Я всегда думаю исключительно головой. У вас есть другие органы для мыслительных процессов?
2. Я уже объяснил почему я так думаю. Вы продолжаете троллить. Попробуйте вникнуть в философию языка, а не просто тащите фичи из других языков.

Ferroman
Вам излишен. Мне нет.

опять же почему?

Ferroman
Это вы так решили. Вам так удобно. Мне это нужно, и мне гораздо более удобно смотреть что откуда импортируется в файле, в котором я непосредственно работаю, а не где бы то ни было ещё.
Следовательно это вопрос вкуса. Вкусы большинства питонистов отличаются от вашего.
Делайте выводы.

это вы считаете за аргументы? то что вы делаете руками делается в одном месте и один раз, а вот когда все в разных местах хардкорят импорты, половина которых забывается, удалятся или еще что туда сюда меняется и получается каша, нежели в случае когда это все догружается по требованию, из одного места.
Делайте выводы.

Ferroman
В том-то и дело, что писать в одном месте, а смотреть в другое, особенно при коллективной разработке, черевато последствиями.

Где аргументы, если последствиями то какими? вы видимо не понимаете что это код будет написан один раз и забыт, далее он будет только читаться (и то в 1% вариантов) и все, никаких изменения в нем не будет.

Ferroman
Вы думаете что полный импорт - излишество. Я так не думаю.
Я так понимаю, так не думает и дизайнер языка.

Почему вы так не думаете? потому что думаете что так думает автор языка? хоть один аргумент пожалуйста.

Ferroman
2. Я уже объяснил почему я так думаю. Вы продолжаете троллить.

Не вижу аргументированного объяснения. Троллите вы.

Ferroman
Что я должен вспомнить?

То что если есть зависимости то следует их понижать, и это не дело вкуса или чего то еще, есть вполне объективные вещи которые лежат вне самого языка, и множество возможных реализаций этого с помощью конкретного языка.

Ferroman
Перечитайте значения понятия DRY больше 1-го раза.

Перечитайте сами, я уже от вас наслушался,у меня есть неудобство в реализации и я ищу способ его решения, вы же занимайтесь перечитыванием принципов.

Ferroman
Попробуйте вникнуть в философию языка, а не просто тащите фичи из других языков.

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

Упорный Evg, для меня тоже читабельность кода важнее быстроты его написания.
Неявные импорты сильно это дело портят - особенно в больших проектах со значительной codebase.
ИМХО, удобство чтения исходников - чуть ли не главный критерий оценки любого языка программирования.
Вы данное утверждение не воспринимаете - что ж, дело личное.

Есть такой трюк: можно написать __builtins__.name = object, тогда name будет доступно в любом модуле.
Если хотите - попробуйте, поиграйтесь. Возможно, потом лучше поймете, почему так делать не нужно никогда.
И никому этот код не показывайте :)

опять же почему?

Потому что я хочу видеть все сущности используемые в коде файла. Окуда они взялись. А не лазить по сторонним файлам сопоставляя сущности с файлами где они представлены.

это вы считаете за аргументы?

Да считаю. Если вы - нет, то это не моя проблема.

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

В каких это “разных местах”?

половина которых забывается, удалятся или еще что туда сюда меняется и получается каша,

Если у вас в импортах “каша” то вы ССЗБ.

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

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

Где аргументы, если последствиями то какими? вы видимо не понимаете что это код будет написан один раз и забыт, далее он будет только читаться (и то в 1% вариантов) и все, никаких изменения в нем не будет.

Я не ратую за лёгкость писания кода, а только за чтения. Поскольку код чаще читают, чем пишут.
Спрятать импорты - усложнить его чтение.

Почему вы так не думаете? потому что думаете что так думает автор языка? хоть один аргумент пожалуйста.

Кроме того, что я согласен в этом вопросе с автором, есть ещё причина - потому что язык создан для такого его использования.
Использовать его не обращая внимания на изначальный дизайн - забивать гвозди шуруповёртом.

То что если есть зависимости то следует их понижать, и это не дело вкуса или чего то еще, есть вполне объективные вещи которые лежат вне самого языка, и множество возможных реализаций этого с помощью конкретного языка.

Это просто какая-то абстрактная фраза. Мы говорим о конкретном “синтаксическом сахаре” языка. Я говорю что такой сахар вреден читабельности. Вы твердите обратное.
При чём тут абстрактные “вещи вне языка”, я уже не говорю про какие-то “зависимости”.

Перечитайте сами, я уже от вас наслушался,у меня есть неудобство в реализации и я ищу способ его решения, вы же занимайтесь перечитыванием принципов.

Я читаю принципы вам, сам то я их уже и без того неплохо знаю. Мне показалось вы не совсем понимаете зачем они нужны и что конкретно имелось в виду под абривиатурой DRY.
И опять же пытаюсь вас переубедить что “неудобство” скорее у вас в голове, чем есть в реальности.
Ели вам надо что-то типа плагинов, когда неизвестно сколько их есть, а следовательно что надо импортировать - то это одно, тут очевидно нужно искать динамичное решение, задача обязывает. Если же вы хотите избавится от импортов при программировании, “поскольку надоело” - это совсем другое, и неудобсво лежит в плоскости отношения к тому как пишутся программы на питоне.

Мне ясна эта философия, и я выше объяснил аргументировано почему в данном случае мне лучше следовать своей позиции.

Нет не объяснили и не аргументировали. “Лень копировать импорты” - не самый сильный аргумент. C DRY я уже объяснил, что к импорту этот принцип отношения не имеет.

А вы следуйте своей философии, если у вас такой фанатичный догматизм, я же на это не претендую, я просто указал преимущества, от вас преимуществ я не услышал,

Это python-философия. Я ей следую, ибо было бы глупо следовать философии одного языка, используя другой.
Я указал недостатки вашего способа. Вы в упор не хотите их видеть. Эти недостатки, на мой взгляд, и судя по всему не только на мой, перевешивают возможные +.

мне так удобно, так задумывалось в дизайне языка. Я думаю что так думают все.'

Т.е. “так задумано в дизайне языка” уже не аргумент? А про “мне так удобно” - это был контраргумент на ваше “99% случаев это никому не надо” “мне неудобно”.
“Так думают все” - я такого не говорил, наверняка так думают не все. Но я таких питонистов не встречал.

Ещё раз - делайте как хотите. Хотите “как PHP” - я думаю можно как-то это сделать. Моя позиция довольно проста - я не рекомендую так делать, и считаю подход неверным в корне, в чём и пытался вас в этом убедить.

Все своидится к тому что вы уперлись что вам нужна вот эта информация почти всегда - from django.contrib.contenttypes.models import ContentType, вот объясните зачем вам в 99% случаев то что идет до самого имени? каким-то доводом кроме “так задумано в дизайне языка”. Во вторых что там именно задумано? язык предоставляет возможность импорта а как пользоваться ею решает программист. Если есть импорты это не значит что это единственно возможный и правильный способ подгружать имена, над любым инструментом всегда можно сделать более абстрактную и более удобную для конкретного случаю обертку.

Андрей Светлов
Упорный Evg, для меня тоже читабельность кода важнее быстроты его написания.
Неявные импорты сильно это дело портят - особенно в больших проектах со значительной codebase.
ИМХО, удобство чтения исходников - чуть ли не главный критерий оценки любого языка программирования.
Вы данное утверждение не воспринимаете - что ж, дело личное.

Во 1-х у меня сейчас немного другая специфика, нужно написать быстро и много небольших вещей, которые будут забыты и никто к ним возвращаться никогда не будет. Во 2-х мне не ясны ваши аргументы насчет читаемости, все импорты будут определены только не в самом файле а в другом месте причем одном, разница только в том что в вашем случае придется листать файл к верху, а в моем открыть один другой файл и найти там соответствие - те это практически равносильно как видите, никакой неявности и магии тут нет, это просто способ реализации облегчающий написание и все. Это равносильно тому что интерпретатор не вывалит исключение когда найдет неизвестное имя, а попытается загрузить его за программиста вот и все. Перекрытие имен может напрягать только в случаях если именам давать неосмысленные имена типа A,B,C.

Из плюсов вашего способа только то что в 99% исходников будет найден именно он, но это далеко не значит что так лучше. И разабраться в том что в коде есть небольшой автоподгрузчик имен кот. выполняет грязную работу никого не затруднит, человек просто увидит что имя не объявлено и найдет единственное место где оно объявляется - тут нет проблемы.

Отредактировано (Дек. 27, 2009 11:12:01)

Sapienti Sat.

Ferroman
Sapienti Sat.

Ага именно так, когда конкретно возразить нечем.

Вы не желаете видеть аргументы, ли не считаете их достаточно вескими.
Продолжать нет смысла, и всё уже сказано. Sapienti Sat.