Найти - Пользователи
Полная версия: В чем смысл такого кода?
Начало » Python для новичков » В чем смысл такого кода?
1
kus
Приветствую, господа.
Читаю тут коробочные библиотеки питона, и уже не раз попадается код такого типа (это молуль os ):
 def _fscodec():
    encoding = sys.getfilesystemencoding()
    errors = sys.getfilesystemencodeerrors()
    def fsencode(filename):
        """Encode filename (an os.PathLike, bytes, or str) to the filesystem
        encoding with 'surrogateescape' error handler, return bytes unchanged.
        On Windows, use 'strict' error handler if the file system encoding is
        'mbcs' (which is the default encoding).
        """
        filename = fspath(filename)  # Does type-checking of `filename`.
        if isinstance(filename, str):
            return filename.encode(encoding, errors)
        else:
            return filename
    def fsdecode(filename):
        """Decode filename (an os.PathLike, bytes, or str) from the filesystem
        encoding with 'surrogateescape' error handler, return str unchanged. On
        Windows, use 'strict' error handler if the file system encoding is
        'mbcs' (which is the default encoding).
        """
        filename = fspath(filename)  # Does type-checking of `filename`.
        if isinstance(filename, bytes):
            return filename.decode(encoding, errors)
        else:
            return filename
    return fsencode, fsdecode
fsencode, fsdecode = _fscodec()
del _fscodec
В чем цимес делать функцию, в которой объявить еще 2 функции. А потом распаковать их в 2 указателя?
ЗЫ: Я сижу уже неделю думаю, что этим хотел сказать автор?
Спасибо.
py.user.next
Видимо, он хочет без имён что-то создавать, чтобы в любое время дать этим функциям имена и в любое время стереть эти имена. Но, видимо, он не догоняет, что такие вложения не дают тестировать такие функции, так как они не видны снаружи. То есть для создания юнит-теста для одной из этих функций ему придётся делать обе этих функции.

Так что, думаю, это всё сделано из-за имён. Он создаёт локальные пространства имён.

Вот там в дзене питона последнее правило есть про пространства имена
  
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB