Closes#784Closes#785
First commit fixes a small bug that I observed while trying to record some new test fixtures: the stringification of the headers is not correctly printed as a list of tuples, but as an `iteritems` object, so I forced the list evaluation.
Second commit adds the missing properties `allow_merge_commit`, `allow_rebase_merge`, `allow_squash_merge`, and `has_projects` to the `Repository` class.
Note however that I ran into some trouble while modifying the `edit` method of the `Repository` class to make use of the new properties, specifically while writing tests, so I will fix the `edit` method in a future PR.
As mentioned in https://developer.github.com/v3/orgs/, an organization also has a description. This PR adds this attribute to the `Organization` class, as well as modifies its `edit` method so that it's possible to update it.
I noticed too late the [`add_attribute.py` script](https://github.com/PyGithub/PyGithub/blob/8ae2bcb1e6f96beeec99fbbcf00f4af46bb38cde/scripts/add_attribute.py), so I did my modifications by hand, but I noticed that the output of the script and the style used for all the other attributes are different. I preferred the style that is prevalent in the file, rather than the output of the script.
* Add methods add_to_members(), has_in_pending_members(), and remove_from_membership() methods to Organization class.
* Add scrubbed replay files used for testing
* More massaging of test data
* Fix URL to remove organization membership
* Remove `has_in_pending_members()` method
* Add team privacy and add additional parameter to test. Still requires replaydata
* Reorder parameters to not break existing code
* Update tests for #702
* Add hook support for organizations
Specifically, the create_hook, get_hook, and get_hooks calls
* Added support for the edit and delete hook functions
* Added missing parameters to organisation repo creation
* team_id should already be an id not a team object
* Name arguments in the test
* Fixed assertion check
* Added missing parameters to user repo creation
* Fixed comments
This is a minor thing. It’s a convention, not a rule (obviously)—but it’s also a best practice.
Many text editors look for this kind of comment as the first line—or second line, if there is a shebang (the `#!/usr/bin/env python`, or whatever else)—and make use of this to determine the file’s encoding.
Jacopo Notarstefano