>> Pyrex will do this if you declare the object as being of >> type 'dict' (and it will check the type on the boundary >> between Python and extension code, so it's still type-safe). >> Similarly for 'list' and a few other built-in types that >> have dedicated C APIs. > > Right, this is totally not "black magic". >
Of course not -- but as I mentioned above, this isn't what I was referring to. I was referring to cases where either (1) there's no *explicit* type information, which I think we can handle many of as Cython gets smarter, and (2) cases where it's not *possible* to infer the type information, but you have some sort of implicit contract (because, say, you're writing the code that calls this C extension). > There are some cases, though, where you can easily write C-API code that > outperforms Cython code. A well known example is a call to PyDict_GetItem() > in C and a subsequent check for a NULL return value. Cython code needs to > read the value into a variable first and then test it, a common idiom being > > result = d.get(key) > if result is not None: > ... > Maybe I'm being too optimistic, but there are some cases like this that we *could* teach the compiler to figure out, right? It would probably involve *some* amount of Python-specific analysis, and we surely couldn't catch *all* of the cases, but we could probably get the lion's share of the idiomatic ones ... > But in general, this is really chasing microseconds in places where it > rarely matters. > Sure. But that said, if you *really* do care about those last few microseconds -- because maybe you're obsessed with irrelevant microbenchmarks like I've often been? ;) -- there is a little extra you can squeeze with direct use of the Python/C API. -cc _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
