Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change some APIs in order to return an iterator instead of a list #243

Closed
giampaolo opened this issue May 23, 2014 · 4 comments
Closed

Change some APIs in order to return an iterator instead of a list #243

giampaolo opened this issue May 23, 2014 · 4 comments

Comments

@giampaolo
Copy link
Owner

From g.rodola on January 19, 2012 14:47:03

As of right now we have different process methods which are returning a list:

Process.get_open_files()
Process.get_connections()
Process.get_children()
Process.get_threads()

I think *at least* the first 2 should return an iterator instead.
That would be particularly useful for get_open_files() and get_connections() 
since they can produce hundreds of results.
Users using those methods in a for loop won't suffer any code breakage.
Others will be bitten though, so maybe it makes sense to schedule this change 
for a major release (1.0.0 maybe, the project is mature enough to get there 
after all).

Original issue: http://code.google.com/p/psutil/issues/detail?id=243

@giampaolo
Copy link
Owner Author

From dolfandr...@gmail.com on January 19, 2012 06:09:08

I don't fully agree. Not being able to index the return value of the methods 
would be annoying to me. I would then need to do

>>> [p for p in Process.get_children()][0]

instead of just

>>> Process.get_children()[0]

@giampaolo
Copy link
Owner Author

From jlo...@gmail.com on January 20, 2012 12:35:55

Are you planning to change the underling C implementation for these methods? 
Right now the list is being built in C code, so there would be very little 
benefit to turning these into iterators at the Python API wrapper level.

Can we make a good enough case for a performance or functionality improvement 
by making these into iterators that it's worth breaking compatibility with the 
previous versions?

@giampaolo
Copy link
Owner Author

From g.rodola on January 20, 2012 12:45:31

> Are you planning to change the underling C implementation for these methods?

Yes: http://docs.python.org/c-api/gen.html Building the whole list in C and 
then yield-ify it in python would be useless.

> Can we make a good enough case for a performance or functionality improvement 
> by making these into iterators that it's worth breaking compatibility with 
> the previous versions? 

Yeah, I suppose it makes sense to make a benchmark first to figure out whether 
this actually worths the effort.

Labels: Compatibility Performance

@giampaolo
Copy link
Owner Author

From g.rodola on February 24, 2013 14:36:38

Thinking back, I think it's not worth the effort. Closing out.

Status: WontFix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant