5
szukam w kodzie w tym repo https://github.com/datacenter/cobra i widzę importu z poleceń wbudowanych w następujący sposób w ciągu kilku plików:Dlaczego importować wbudowane, jeśli nigdy nie zmienisz definicji wbudowanych funkcji?
cobra/internal/codec/jsoncodec.py:15:from builtins import str
cobra/internal/codec/xmlcodec.py:15:from builtins import str
cobra/internal/base/moimpl.py:16:from builtins import next
cobra/internal/base/moimpl.py:17:from builtins import str
cobra/internal/base/moimpl.py:18:from builtins import object
cobra/internal/rest/accessimpl.py:15:from builtins import object
cobra/internal/rest/accessimpl.py:16:from builtins import str
cobra/mit/session.py:15:from builtins import str
cobra/mit/session.py:16:from builtins import object
cobra/mit/meta.py:16:from builtins import str
cobra/mit/meta.py:17:from builtins import next
cobra/mit/meta.py:18:from builtins import object
cobra/mit/access.py:21:from builtins import object
cobra/mit/naming.py:15:from builtins import next
cobra/mit/naming.py:16:from builtins import str
cobra/mit/naming.py:17:from builtins import object
cobra/mit/request.py:15:from builtins import str
cobra/mit/request.py:16:from builtins import object
Jaka jest logika/co uzyskuje się w ten sposób? W module nie ma miejsca, w którym obiekty te zostaną ponownie zdefiniowane.
Pod tym względem łamie to zgodność 2.7, której oczekiwałem od tego modułu, jak określono w dokumentacji.
Może lepszym pomysłem powinno być zapytanie deweloperów projektu, dlaczego to robią! –
Mając te nazwy w przestrzeni nazw modułów będą 1. nieznacznie bardziej wydajne niż dostęp do nich w postaci wbudowanych, i 2. nie będą miały wpływu jakiekolwiek redefinitions wbudowanych modułów importowanych później. Dlaczego to zrobili, nie mogę powiedzieć; ludzie po prostu polubili to w ten sposób ... – kindall
W którym przypadku potrzebujesz wbudowanych metod importowania wydajności? I to podejście nie działa na Pythonie 2.x –