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

2012-03-07 Thread Thomas Heller
Thomas Heller thel...@ctypes.org 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']

2012-03-07 Thread Erik Johansson
Erik Johansson e...@ejohansson.se added the comment: Perhaps this behaviour should be documented somewhere (unless it already is)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14201 ___

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

2012-03-07 Thread Éric Araujo
Éric Araujo mer...@netwok.org 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. --

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

2012-03-05 Thread Erik Johansson
New submission from Erik Johansson e...@ejohansson.se: 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

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

2012-03-05 Thread Antoine Pitrou
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +amaury.forgeotdarc, belopolsky, meador.inge versions: +Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14201 ___

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

2012-03-05 Thread Martin v . Löwis
Martin v. Löwis mar...@v.loewis.de 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 rep...@bugs.python.org