Get objects.

        **Pseudo-directory Notes**: Rackspace has two approaches to pseudo-
        directories within the (really) flat storage object namespace:

          1. Dummy directory storage objects. These are real storage objects
             of type "application/directory" and must be manually uploaded
             by the client.
          2. Implied subdirectories using the `path` API query parameter.

        Both serve the same purpose, but the latter is much preferred because
        there is no independent maintenance of extra dummy objects, and the
        `path` approach is always correct (for the existing storage objects).

        This package uses the latter `path` approach, but gets into an
        ambiguous situation where there is both a dummy directory storage
        object and an implied subdirectory. To remedy this situation, we only
        show information for the dummy directory object in results if present,
        and ignore the implied subdirectory. But, under the hood this means
        that our `limit` parameter may end up with less than the desired
        number of objects. So, we use the heuristic that if we **do** have
        "application/directory" objects, we end up doing an extra query of
        double the limit size to ensure we can get up to the limit amount
        of objects. This double query approach is inefficient, but as
        using dummy objects should now be deprecated, the second query should
        only rarely occur.

def get_objects(self, path, marker=None,
                    limit=settings.CLOUD_BROWSER_DEFAULT_LIST_LIMIT):
        """Get objects.

        **Pseudo-directory Notes**: Rackspace has two approaches to pseudo-
        directories within the (really) flat storage object namespace:

          1. Dummy directory storage objects. These are real storage objects
             of type "application/directory" and must be manually uploaded
             by the client.
          2. Implied subdirectories using the `path` API query parameter.

        Both serve the same purpose, but the latter is much preferred because
        there is no independent maintenance of extra dummy objects, and the
        `path` approach is always correct (for the existing storage objects).

        This package uses the latter `path` approach, but gets into an
        ambiguous situation where there is both a dummy directory storage
        object and an implied subdirectory. To remedy this situation, we only
        show information for the dummy directory object in results if present,
        and ignore the implied subdirectory. But, under the hood this means
        that our `limit` parameter may end up with less than the desired
        number of objects. So, we use the heuristic that if we **do** have
        "application/directory" objects, we end up doing an extra query of
        double the limit size to ensure we can get up to the limit amount
        of objects. This double query approach is inefficient, but as
        using dummy objects should now be deprecated, the second query should
        only rarely occur.

        """
        object_infos, full_query = self._get_object_infos(path, marker, limit)
        if full_query and len(object_infos) < limit:
            # The underlying query returned a full result set, but we
            # truncated it to under limit. Re-run at twice the limit and then
            # slice back.
            object_infos, _ = self._get_object_infos(path, marker, 2 * limit)
            object_infos = object_infos[:limit]

        return [self.obj_cls.from_info(self, x) for x in object_infos]