[issue14201] libc.time != libc['time']

Éric Araujo added the comment: Item access is documented in this section: http://docs.python.org/library/ctypes#loading-shared-libraries (scroll a bit down looking for __getitem__); the wording about caching is ambiguous with respect to the current behavior. -- assignee: -> docs@pyt

[issue14201] libc.time != libc['time']

Erik Johansson added the comment: Perhaps this behaviour should be documented somewhere (unless it already is)? -- ___ Python tracker ___ ___

[issue14201] libc.time != libc['time']

Thomas Heller added the comment: The rationale was to allow different packages (for example) in the same process to have their own private instance of a foreign function, with possibly different definitions of restype, argtypes and/or errcheck. --

[issue14201] libc.time != libc['time']

Martin v. Löwis added the comment: This is intentional; the caching was removed in 214b28d7a999. Thomas, can you remember the rationale for this change? -- nosy: +loewis, theller ___ Python tracker __

[issue14201] libc.time != libc['time']

Changes by Antoine Pitrou : -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge versions: +Python 3.2, Python 3.3 ___ Python tracker ___ ___

[issue14201] libc.time != libc['time']

New submission from Erik Johansson : I would expect that the following code would give True as result: >>> from ctypes import * >>> libc = CDLL("libc.so.6") >>> libc.time == libc['time'] False Is it by design that libc['time'] always returns a different _FuncPtr object? It is a bit confusing w