-
Notifications
You must be signed in to change notification settings - Fork 0
NetworkX GSoC 2015 Application: NetworkX 2.0 API Mridul Seth
Name: Mridul Seth
University: BITS Pilani, India
E-Mail: seth.mridul@gmail.com
GitHub: MridulS
IRC: mridul_seth
I am currently a second year undergraduate student double majoring in Mathematics and Electronics Engineering. I have done formal course work on graphs and networks as part of my college courses. I have been using Python and Git for more than 2 years now, and I am comfortable with them. I am also comfortable with working on C. I work on an OS X machine with vim and sublime as my text editors. I started contributing to open source projects a year back, I did some contributions to sympy. I work with the registration office of my university, and have created many softwares to facilitate course registration and generating time tables for the students.
I started using NetworkX in early December,2014 and started contributing to the open source project in early February, 2014. Currently I am working on the following PRs:
My PR regarding the data keyword in G.neighbors #1344 lead me to choosing this project for GSoC. Further issues can be seen at https://github.com/networkx/networkx/issues?q=author%3AMridulS
I plan to invest 40 hours per week during the summer for this project.And about 10-15 hours per week for pre and post GSoC period. I plan to continue working for networkx after GSoC. I will also be writing a weekly blog about the progress during the summer.
As NetworkX moves towards NetworkX 2.0 and an iterator/generator reporting model, implementing a better, less redundant API is a must for NetworkX. The central idea of this project (proposal) is to offer to a modernised API, clean up and review the existing code, and update the documentation as required. The most important part of the project is to define an appropriate design specification. Further the redesigned API should have a feasible design plan and shouldn't affect (lower) the performance drastically. The next part would be to implement it and do performance testing and compare it with the old API. There are many ideas discussed in #1246. This new API should be able to give an unified interface to access graph data which should be independent of the base class, it could be OrderedGraph, ThinGraph, etc. which is implemented in #1314. It should also work with alternate backends like a SQL based. Currently Di/Multi/Graphs have different APIs, this project would also further investigate the idea of having a unified API for different base classes. #1246 comment.
The three tentative project deliverables:
- Rename the
_iter-suffixed functions over their unsuffixed counterparts - Investigate and implement a generic interface for accessing graph data
- Use the opportunity presented by a reorganization to implement efficient code for Python 2&3
For functions like neighbors/edges/adjacency which have two functions to report their data, one which returns a list func and the other returns an iterator func_iter. As we are moving towards a iterator reporting paradigm for 2.0 API, the functions returning lists will be changed to return iterators and thus the _iter suffix will be retired. This would be a backward-incompatible change.
The third part will be implemented at the same time while working on part 1 and part 2. Python 3 is required for iterating. Efficiency could be improved for Python 2 with the use of the future package. This package offers range as an alias for xrange in Python 2 and functions to efficiently iterate over dictionaries. Thus making the code more cleaner and easier to maintain. (This has to be discussed more as there are different opinions within the community)
Will update this as discussed in #1382. As discussed in #1382, 2.0 would try to avoid bringing a lot of new backward incompatible changes. We already have lot of new functionalities. So, the main focus for NetworkX 2.0 should be renaming the _iter functions, and we will be breaking backward compatibility by doing the current changes and it is much easier for people to adapt code to backwards incompatible changes when the number of changes are small and fairly insignificant. This https://github.com/ysitu/networkx/commit/bfce79ab2af50f5a7e7769d36b8c40909985e4c9 will be used as the starting point for the renaming of _iter functions.
The first part of the summer will be focused on renaming _iter functions, cleaning and reorganising the existing code as decided by the community, updating documentation, tests and getting ready for NetworkX 2.0. As there will be many different opinions regarding the new API design, discussion regarding the design specification with the community will be a major part of the new API. Redefining a new API will be done over the renaming summer and post summer too. The new API will be implemented in a different branch.
The project will end with updating the documentation, unit tests, adding more examples, and writing a wrap up report on significant changes in NetworkX 2.0
A rough timeline:
- Working on issues and pending PRs in https://github.com/networkx/networkx/milestones/networkx-2.0
- Discussion about the API Design specification
- Working on renaming _iter functions.
- Updating the documentation and tests as necessary.
- Further discussion about the API design.
- Cleaning and reorganising the current codebase as required and decided.
- Working on the implementation of the new API design.
- Cleaning and reorganising the current codebase as required and decided.
- Continue working on the new API design and get it ready for the next major version release. :)