Guria: переводы
Style Guide for Python Code
→If this spelling causes local name clashes, then spell them
import myclass
import foo.bar.yourclass
and use "myclass.MyClass" and "foo.bar.yourclass.YourClass"
import myclass
import foo.bar.yourclass
and use "myclass.MyClass" and "foo.bar.yourclass.YourClass"
0 Если же такое написание вызывает локальные конфликты, тогда используйте:
import myclass
import foo.bar.yourclass
и обращайтесь к классам как "myclass.MyClass" и "foo.bar.yourclass.YourClass"
import myclass
import foo.bar.yourclass
и обращайтесь к классам как "myclass.MyClass" и "foo.bar.yourclass.YourClass"
→When importing a class from a class-containing module, it's usually okay to spell this
from myclass import MyClass
from foo.bar.yourclass import YourClass
from myclass import MyClass
from foo.bar.yourclass import YourClass
0 При импортировании класса из модуля можно использовать следующую конструкцию:
from myclass import MyClass
from foo.bar.yourclass import YourClass
from myclass import MyClass
from foo.bar.yourclass import YourClass
→Even now that PEP 328 is fully implemented in Python 2.5, its style of explicit relative imports is actively discouraged; absolute imports are more portable and usually more readable.
0 Даже сейчас когда PEP 328 полностью реализовано в Python 2.5, его стиль явных относительных импортов сбивает с толку. Абсолютные импортирования более переносимы и обычно более читаемы.
→Always use the absolute package path for all imports.
0 Всегда используйте абсолютные пути в пакетах для импортирований.
→Relative imports for intra-package imports are highly discouraged.
0 Относительные импортирования для внутри-пакетных модулей озадачивают.
→Put any relevant __all__ specification after the imports.
0 Разместите соответствующую спецификацию переменной __all__ после блока импортирований.
→You should put a blank line between each group of imports.
0 Вы должны разделять каждую группу импортирования пустой строкой.
→Imports should be grouped in the following order:
1. standard library imports
2. related third party imports
3. local application/library specific imports
1. standard library imports
2. related third party imports
3. local application/library specific imports
0 Импортирования должны быть сгруппированы в следующем порядке:
1. модули стандартной библиотеки
2. модули сторонних поставщиков
3. локальные модули относящиеся к приложению/библиотеке
1. модули стандартной библиотеки
2. модули сторонних поставщиков
3. локальные модули относящиеся к приложению/библиотеке
→Imports are always put at the top of the file, just after any module comments and docstrings, and before module globals and constants.
0 Всегда размещайте импорт модулей в начале файла, сразу после комментариев и строк документации модуля, и перед глобальными переменными и константами модуля.
→it's okay to say this though:
from subprocess import Popen, PIPE
from subprocess import Popen, PIPE
0 при этом можно писать так:
from subprocess import Popen, PIPE
from subprocess import Popen, PIPE
0 Импорт модулей должен быть, как правило, на отдельных строках, например:
Правильно:
import os
import sys
Неправильно:
import sys, os
Правильно:
import os
import sys
Неправильно:
import sys, os
→Open source projects with a global audience are encouraged to adopt a similar policy.
0 Проектам с открытым исходным кодом с глобальной аудиторией предлагается следовать аналогичной политике.
→Authors whose names are not based on the latin alphabet MUST provide a latin transliteration of their names.
0 Авторы чьи имена не основаны на латинском алфавите ОБЯЗАНЫ предоставлять латинскую транслитерацию их имён.
→The only exceptions are (a) test cases testing the non-ASCII features, and (b) names of authors.
0 Единственные исключения - это (а) тестовые случаи проверяющие функции связанные с не ASCII символами и (б) имена авторов.
→In addition, string literals and comments must also be in ASCII.
0 Кроме того, строковые значения и комментарии также должны использовать ASCII.
→All identifiers in the Python standard library MUST use ASCII-only identifiers, and SHOULD use English words wherever feasible (in many cases, abbreviations and technical terms are used which aren't English).
0 Все идентификаторы в стандартной библиотеке Python ОБЯЗАНЫ использовать только ASCII символы и ДОЛЖНЫ использовать английские слова где это возможно (во многих случаях используются аббревиатуры и технические тремины, не являющиеся английскими).
→For Python 3.0 and beyond, the following policy is prescribed for the standard library (see PEP 3131):
0 Для Python 3.0 и выше следующая политика предписана для стандартной библиотеки (см. PEP 3131):
→Latin-1 (or UTF-8) should only be used when a comment or docstring needs to mention an author name that requires Latin-1; otherwise, using \x, \u or \U escapes is the preferred way to include non-ASCII data in string literals.
0 Latin-1 (или UTF-8) должны использоваться только в случае необходимости упоминания в комментарии или строке документации имени автора, требующего Latin-1, иначе рекомендуемый способ включения не ASCII данных - использование эскейп-последовательностей \x, \u или \U.
→Files using ASCII (or UTF-8, for Python 3.0) should not have a coding cookie.
0 Файлы использующие ASCII (или UTF-8, в случае Python 3.0) не должны содержать указание кодировки.
→For Python 3.0 and beyond, UTF-8 is preferred over Latin-1, see PEP 3120.
0 Для Python 3.0 и выше, кодировка UTF-8 имеет предпочтение, нежели Latin-1 (см. PEP 3120).
Резюме
- Пол:
- мужчина
- Родной язык:
- русский
- С нами:
-
с 12 марта 2009 г.
(6429 дней)
Не является членом клуба. - Деятельность:
-
65 версий перевода
с общим рейтингом 0
10 комментариев
Карма: 1 (оценок: 1)