Czy obiekt pliku zamyka się automatycznie, gdy liczba jego odwołań jest równa zero?

Question

Byłem pod wrażeniem, że obiekty plików są natychmiast zamknięte, kiedy ich liczy referencyjne hit 0, stąd wiersz:

foo = open('foo').read() 

dostanie ci zawartość pliku i natychmiast zamknij plik. Jednak po przeczytaniu odpowiedzi na Is close() necessary when using iterator on a Python file object mam wrażenie, że tak się nie dzieje i że wywołanie .close() na obiekcie pliku jest zawsze konieczne: .

Czy powyższa linia robi to, co myślę, że robi, a nawet jeśli tak, to czy jest to działanie Pythonica?

Answer 1

Odpowiedź zawiera link, który podałeś.

Garbage collector zamyka plik, gdy niszczy obiekt pliku, ale:

• naprawdę nie mieć kontrolę nad tym, kiedy to się stanie.

  Podczas gdy CPython używa licznika odwołań do deterministycznego udostępniania zasobów (dzięki czemu można przewidzieć, kiedy obiekt zostanie zniszczony) inne wersje nie muszą. Na przykład zarówno Jython, jak i IronPython używają JVM i .Ull garbage collector, który zwalnia (i finalizuje) obiekty tylko wtedy, gdy istnieje potrzeba odzyskania pamięci i może tego nie robić dla niektórych obiektów do końca programu. Nawet w przypadku CPython GC algorytm może się zmienić w przyszłości, ponieważ liczenie odniesienia nie jest zbyt wydajne.

• jeśli zostanie zgłoszony wyjątek podczas zamykania pliku w celu zniszczenia obiektu, nie można naprawdę nic z tym zrobić, ponieważ nie będzie wiadomo.

Answer 2

Jeśli chcesz mieć pewność, chciałbym napisać kod jak poniżej:

from __future__ import with_statement 

with open('foo') as f: 
    foo = f.read() 

ten sposób, plik zamyka się zgodnie z oczekiwaniami, nawet z wyjątkami.

---

Znacznie później: Oto niektóre kodu z import dis pokazać jak kompilator traktuje je inaczej.

>>> def foo(filename): 
...  with open(filename) as f: 
...   return f.read() 
... 
>>> def bar(filename): 
...  return open(filename).read() 
... 
>>> from dis import dis 
>>> 
>>> dis(foo) 
    2   0 LOAD_GLOBAL    0 (open) 
       3 LOAD_FAST    0 (filename) 
       6 CALL_FUNCTION   1 
       9 DUP_TOP    
      10 LOAD_ATTR    1 (__exit__) 
      13 ROT_TWO    
      14 LOAD_ATTR    2 (__enter__) 
      17 CALL_FUNCTION   0 
      20 STORE_FAST    1 (_[1]) 
      23 SETUP_FINALLY   23 (to 49) 
      26 LOAD_FAST    1 (_[1]) 
      29 DELETE_FAST    1 (_[1]) 
      32 STORE_FAST    2 (f) 

    3   35 LOAD_FAST    2 (f) 
      38 LOAD_ATTR    3 (read) 
      41 CALL_FUNCTION   0 
      44 RETURN_VALUE   
      45 POP_BLOCK   
      46 LOAD_CONST    0 (None) 
     >> 49 WITH_CLEANUP   
      50 END_FINALLY   
      51 LOAD_CONST    0 (None) 
      54 RETURN_VALUE   
>>> dis(bar) 
    2   0 LOAD_GLOBAL    0 (open) 
       3 LOAD_FAST    0 (filename) 
       6 CALL_FUNCTION   1 
       9 LOAD_ATTR    1 (read) 
      12 CALL_FUNCTION   0 
      15 RETURN_VALUE 

Answer 3

Nie, Python zoptymalizować usuwanie nieużywanych przedmiotów, więc nigdy nie może zamknąć plik (OK na końcu skryptu na wyjeździe to będzie czyszczenia). @ hughdbrown wskazały dobre rozwiązanie.

Answer 4

Dla realizacji CPython pythona: tak, to jest gwarantowana być zamknięte, gdy jej Ilość referencyjna spadnie do zera.

Dla Pythona jako języka abstrakcyjnego (np. W tym Jython, IronPython itp.): nie, nie ma gwarancji, że zostanie zamknięty. W szczególności implementacja Pythona może nie korzystać z liczenia odwołań, ale używać innej formy GC.

Referencje:

• http://docs.python.org/c-api/typeobj.html#tp_dealloc
• http://eli.thegreenplace.net/2009/06/12/safely-using-destructors-in-python/