Skip to content
Snippets Groups Projects
  1. Aug 21, 2024
    • Marc Troelitzsch's avatar
      refactor: Update some outdated syntax · 6eb48c47
      Marc Troelitzsch authored
      This commit updates some outdated syntax with the modern alternatives.
      The changes were applied automatically using pyupgrade (v2.0.1) with the
      following command:
      
      ```
      pyupgrade --py3-plus **/*.py
      ```
      
      These updates are purely syntactical and there should be no change in
      functionality.
      6eb48c47
  2. Aug 11, 2024
    • Adam Williamson's avatar
      Bump version: 0.10.1 → 0.11.0 · da48d446
      Adam Williamson authored
      da48d446
    • Adam Williamson's avatar
    • Adam Williamson's avatar
      a1895931
    • Adam Williamson's avatar
      Deprecate `limit` for `api_chunk_size`, extend `max_items` (#259) · 95c0b0fc
      Adam Williamson authored
      
      As discussed in #259, the `limit` parameter - to the low-level
      `listing.List` and its subclasses, and to various higher-level
      functions which ultimately return `List` or `GeneratorList`
      instances - is confusing and misleading.
      
      It is passed through to the API calls, and effectively specifies
      how many items a single API call will return. But because our
      `List` yields a single item at a time and will keep doing API
      calls until the API says there's no more data, it does not limit
      how many items our `List` will yield, nor specify its chunk size.
      It seems natural to expect that `List(limit=10)` or
      `page.revisions(limit=10)` will give you a generator that yields
      only 10 items, or yields 10 items at a time, but it does not; it
      gives you a generator which queries the API in chunks of 10 items
      at a time, but will yield every item the API gives it, one by one.
      
      This is probably not ever how we really intended mwclient to work
      (there's an old `# NOTE: Fix limit` comment which implies as much)
      but it has worked this way for 16 years, so we should probably
      not change it just in case someone really has a need to specify
      the API chunk size for some reason, or some code somehow happens
      to implicitly rely on it behaving the way it does.
      
      So, this keeps the behaviour of the `limit` param wherever it
      exists, but triggers a deprecation warning. Everything that had
      a `limit` param now also has an `api_chunk_size` param that does
      the same thing, but is more explicitly named and does not trigger
      a deprecation warning. And everything that had a `limit` param
      now also has a `max_items` param that does what it sounds like,
      and what people are more likely to want - sets an absolute limit
      on the number of items the generator will yield.
      
      For efficiency, if `max_items` is set, neither `limit` nor
      `api_chunk_size` is set, and `max_items` is below
      `site.api_limit`, we set the API chunk size to `max_items` so
      we only retrieve as many items as we actually need.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      95c0b0fc
  3. Aug 08, 2024
  4. Jul 17, 2024
  5. Jul 16, 2024
  6. Jul 11, 2024
  7. Jun 01, 2024
  8. May 18, 2024
  9. May 06, 2024
  10. Mar 27, 2024
  11. Feb 16, 2024
  12. Feb 09, 2024
  13. Jan 28, 2024
  14. Jan 27, 2024
  15. Dec 07, 2023
  16. Dec 06, 2023
  17. Oct 03, 2023
  18. Sep 24, 2023
  19. Sep 05, 2023
Loading