История Python. Принципы проектирования | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- Translation complete.
If you do not want to register an account, you can sign in with OpenID.
Python's Design Philosophy | ||
Later blog entries will dive into the gory details of Python's history. However, before I do that, I would like to elaborate on the philosophical guidelines that helped me make decisions while designing and implementing Python. | Дальнейшие записи в этом блоге опустятся в окровавленные пучины истории Python. Однако, прежде чем это сделать, я хотел бы остановиться на философских принципах которые помогали мне проектировать и реализовывать Python. | |
First of all, Python was originally conceived as a one-person “skunkworks” project – there was no official budget, and I wanted results quickly, in part so that I could convince management to support the project (in which I was fairly successful). This led to a number of timesaving rules: | Прежде всего, Python изначально задумывался как персональный проект "опытной мастерской" - без официального бюджета. Плюс я хотел получить результаты быстро, в частности для того, чтобы убедить руководство поддержать проект (в чем я преуспел). Это привело меня к нескольким, экономящим время правилам: | |
Borrow ideas from elsewhere whenever it makes sense. | ||
“Things should be as simple as possible, but no simpler.” (Einstein) | "Вещи должны быть настолько простыми насколько это возможно, но не проще" (Эйнштейн). | |
Do one thing well (The "UNIX philosophy"). | ||
Don’t fret too much about performance--plan to optimize later when needed. | Не слишком беспокойся о производительности - планируй оптимизацию на тот момент когда она понадобится. | |
Don’t fight the environment and go with the flow. | — "Не пытайтесь переделать мир" - хорошо, но пафосно. Я думаю что Гвидо не пафосный чувак, и не стал бы использовать пафосный принцип среди непафосных. Поэтому нужно переделать. — ziderzee — Что здесь есть "окружение"? Есть "переменные окружения". А здесь -- не в тему. — godlesser — общество, обстоятельства, среда — ziderzee | |
Don’t try for perfection because “good enough” is often just that. | Не стремись к совершенству, потому что зачастую "нормально" бывает достаточно. | — Может «То, что мы называем "достаточно хороший"» или «То на что мы соглашаемся как "достаточно подходящий" (приемлемый))» или что-то такое, что подчеркивало бы субъективность выражения "good enough" и смещение его повседневного смысла в негативную сторону… — kain-haart — Да, согласен это как раз то чего не хватало моему варианту. Я изменил порядок "частей" в предложении. Как мне кажется - стало лучше. Но мне не очень нравится окончание предложения "не прибегай к излишнему совершенствованию". Мне кажется что нужно как-то усилить "ненужность лишнего" совершествования — ziderzee — не стремись к совершенству, просто "хорошо" чаще всего бывает достаточно — olegsh — good enough - http://multitran.ru/c/m.exe?CL=1&l1=1... — ziderzee |
(Hence) it’s okay to cut corners sometimes, especially if you can do it right later. | (Следовательно) нормально иногда срезать углы, особенно, если позднее сможешь это исправить. | |
Other principles weren’t intended as timesavers. Sometimes they were quite the opposite: | Остальные принципы применялись не ради экономии времени. Причем зачастую они приводят к прямо противоположному эффекту. | |
The Python implementation should not be tied to a particular platform. It’s okay if some functionality is not always available, but the core should work everywhere. | Реализация Python не должна быть привязанна к определенной платформе. Ничего, если некоторая функциональность будет не всегда доступна, но вот ядро должно работать везде. | — "какой-то" - без него можно обойтись. "присутствовать" заменил на "доступна", потому что на мой взгляд более подходит к слову функциональность, применяемому в этом контексте. Согласны? — ziderzee — Согласен. Спасибо. — kain-haart |
Don’t bother users with details that the machine can handle (I didn’t always follow this rule and some of the of the disastrous consequences are described in later sections). | Не обременяй пользователей детальными описаниями того, с чем машина может работать (я не всегда следовал этому правилу и некоторые из катастрофических последствий этого описаны ниже). | |
Support and encourage platform-independent user code, but don’t cut off access to platform capabilities or properties (This is in sharp contrast to Java.) | Поддерживай и вдохновляй платформо-независимый пользовательский код, но не закрывай доступ к платформенным возможностям или свойствам (это резко контрастирует с Java). | — Здесь, думаю, речь идет именно о платформо-независимом коде, а не о разработках. Код более узкое понятие, а разработки - более обширное и, как следствие, тезис принимает административно-стратегический характер. Что, опять же, на мой взгяд, не совсем верно. — ziderzee |
A large complex system should have multiple levels of extensibility. This maximizes the opportunities for users, sophisticated or not, to help themselves. | Большая сложная система должна иметь несколько уровней расширяемости. Это даёт пользователям больше возможностей, независимо от их опыта. | — "помочь самим себе" плохо звучит, на ум приходят утопающие и онанисты, очевидно имеется ввиду то, что я изначально написал — olegsh — не факт. облегчение работы - это снижение затрат. а помочь самому себе - это решение проблем пользователя пользователем. т.е. без участия кого либо. согласны? я согласен что есть что-то от онанистов. но пока в голову ничего лучше не пришло. надо подумать еще. — ziderzee More 3 comments — с расширяемостью понятно. несколько парадигм, поддерживаемых языком - свойство расширяемых языков. "искушенный" сюда не подходит. вроде придумал удобоваримый вариант. — ziderzee |
Errors should not be fatal. That is, user code should be able to recover from error conditions as long as the virtual machine is still functional. | Ошибки не должны быть фатальными. Это означает, что код пользователя должен иметь возможность продолжать выполняться даже при ошибочных параметрах, и при условии что виртуальная машина всё еще работает. | — Во втором предложении непонятно было из-за чего код может иметь возможность продолжить выполнение. Я добавил "ошибочные параметры". Получилось как-то тяжело. Надо бы пересмотреть. — ziderzee |
At the same time, errors should not pass silently (These last two items naturally led to the decision to use exceptions throughout the implementation.) | В тоже время ошибки не должны оставаться незамеченными (последние два принципа привели к решению использовать механизм исключений во всей реализации). | — как вариант - использовать механизм исключений во всем коде — olegsh — я думаю он подразумевал что до введения последних двух принципов - они использовали механизм исключений не во всей реализации. т.е. для каких-то вещей они использовали одну схему, а для каких-то исключения. после того как решили использовать эти принципе - они сделали однообразное использование исключений везде. — ziderzee More 3 comments — да, "правила" здесь не к месту. вообще это принципы. но их здесь много. первая часть начинается со второго абзаца на этой странице. — ziderzee |
© Guido van Rossum.
— http://multitran.ru/c/m.exe?l1=1&l2=2... — olegsh
— долго думал, но все же согласен с вашим вариантом ) — ziderzee
"История Python. Принципы проектирования". - название продуманное. Первая часть ставится перед всеми переводами этой серии (это из блога Гвидо ван Россума - Python History). Вторая часть, после точки, название соотствующей статьи. Изменять не вижу смысла, теряется связывающая все статьи нить. — ziderzee