The RFC library can't do much here: it just makes a request and then receives the response from the R/3 system. So if the R/3 system returns 100k rows, the library will receive these 100k rows, if the R/3 system returns a chunk of these rows, the library will receive only this chunk...
In order to do chunking (or "paging") the two sides (the external program and the ABAP code that gets called) will have to cooperate in some way. This is nothing a generic library could do.
RFC basically follows the "request-response" pattern, and if you want smaller pieces of response data, then the client has to make multiple requests and the server has to return only a part of the "overall data" for each of these requests.
Edit: I have also read your issue #60 now, and if your main concern is performance, then perhaps you are better of to use the C/C++ NW RFC Library directly instead of a Python wrapper?
I'm not familiar with how Python works, but if it is somewhat similar to Java/JNI, then I expect that you have a total of two copies of all the data in memory: first the RFC library receives the data from the wire and stores it on the C heap, and then some C <-> Python interop layer needs to copy that data over to the Python virtual machine?! If that is the case, you could already safe 50% of memory consumption by writing your extractor program in C/C++.