I think that can cause infinite recursion. If I use my own __getattribute__, my __getattr__ may be called. I think it's best practice to use the object.__getattribute__ when looking up attributes inside these methods.

No, they are only used by the resource class to create the "methods" during __init__. They can't live inside the class since I can't remove them dynamically from instances. Are you thinking a "_" prefix or something?

Yeah, a _ prefix would be good. Just to help signify that they're not part of a public API.

That was supposed to be 'rindex', which would raise an exception if the '+' was not found. I was kind of abusing the exceptions here. I've re-written without the try block.

See above.

Thanks for pointing this out, it made me realize there was a bug in this method.

Also, there is some tricky stuff going on here, which definitely needs to be
documented, so thanks for mentioning it.

I'm catching the AttributeError exception, because if 
'resource = object.__getattribute__(self, '_resource')' raises this exception
it means that self._resource has not been initialized yet, which implies I'm in
__init__ trying to initialize it or 'self._transport'. In these special cases I
need to just set the attribute on the object itself, and not look at the fields
of the resource.

This code is dependent on the ordering of assignments and is a little more
prone to breakage under modification than I would like. Can you think of a 
better way to handle this?

Maybe store a _initted flag that we key off of. If set, we set the value directly. Otherwise, we go through the other logic. This would get set as soon as __init__ is done.

I think we want the number of items on the page, otherwise there would be no way to get this value. I plan to add in support for making the queries with counts only for retrieving the total number.

Any ideas on the interface you'd like to see for this sort of thing?

I thought we had the list resources return the total number as part of the payload? No?

You're right, it is returned. I thought it was originally, but during testing I coincidentally had exactly 25 total items in a list, so I thought my assumption was wrong, and we were returning the page length.

I think __len__ should give the page length, and we could have 'resource.total_results' return the total value?

I think __len__ is actually just too vague in this case. Can we scrap it and have two specific attributes, one for each type of count?

Also, a num_pages or something would be good too, to show how many pages there are in total. This would be calculated based on the number per page and the total results found.

It depends on whether or not we would like a ResourceList with 0 items to be true or false (this makes it True). I thought we might want it to be true since there are still a lot of operations with a list when there are no results, but this isn't really keeping with the way things usually work in Python, so I'll remove this.

I'm not sure exactly the best place to put things, or how to split it up, so I shoved them in request.py. Let me know if you have better ideas.

request.py seems fine.

Yeah I'll take care of this, try/except should be fine.

The reason we need to set this is we are making a request for the 'self' resource from a count, which already has it set. So in the case of this resource self.url = "http://r.rb.org/api/resource/?counts-only=True". This means we need to remove the argument, or override it. The interface for the user has no way to remove arguments, just add and override, so I hadn't added this functionality to HttpRequest yet.

Argument removal code can be tacked on to the HttpRequest without changing any user facing interfaces, so I was focusing on other tasks for now, as we really should fix this on the RB side. The only thing this code chunk affects is trying to call 'resource.get_self()' from a resource that was built with 'get_resource(counts_only=True)'. Counts don't actually have a self link, this was added for convenience.

This was an attempt to be defensive. We know the Root resource should have token=None, no matter what is guessed by the factory, so I was setting the argument in case there was some code path I didn't anticipate, or a future modification which uses it. Removing this and setting it inline when calling __init__ will have the same effect, but is less durable to future changes.

Remove or keep?

I figured that was the case. It feels a bit odd still, since we're accepting the argument, passing it, but overriding. I understand the need to accept it, as it's an interface and that argument is expected. I don't think that's an unusual thing, and in the other cases, I don't think we follow this pattern.

I would almost say that we should accept **kwargs in the arg list for this and just never let token appear except when setting it when calling super().

I think the **kwargs method would be nicer. I'm trimming down the __init__ arguments for each class to what they need.

This class is only instantiated once per RBClient, but I'll move it out because it is a constant something else might want in the future.