Skip to content
Snippets Groups Projects
  1. Oct 11, 2024
  2. Oct 10, 2024
  3. Oct 05, 2024
  4. Sep 29, 2024
  5. Sep 28, 2024
    • Marc Troelitzsch's avatar
      fix: Avoid import conflicts by renaming types.py to _types.py · d4ca8555
      Marc Troelitzsch authored
      Renaming `types.py` to `_types.py` to avoid conflicts with Python's
      built-in modules. This change addresses some `ImportErrors` such as:
      
      ```
      ImportError: cannot import name 'MappingProxyType' from partially initialized module 'types' (most likely due to a circular import)
      ```
      
      As far as I can tell this is not a problem when installing the library
      using pip or running tests in tox, only local execution when adding the
      source-root to the `PYTHONPATH`. This is e.g. the case in the default
      IntelliJ/Pycharm run configuration when testing in scratch files.
      d4ca8555
    • Marc Trölitzsch's avatar
      b881c78a
  6. Sep 27, 2024
  7. Sep 16, 2024
  8. Sep 05, 2024
  9. Sep 01, 2024
  10. Aug 31, 2024
  11. Aug 30, 2024
  12. Aug 26, 2024
  13. Aug 25, 2024
  14. Aug 23, 2024
    • Adam Williamson's avatar
      Make logged_in more accurate · e7c51daa
      Adam Williamson authored
      
      I found this while writing integration tests. If you try to login
      with an incorrect username and password, mwclient correctly raises
      mwclient.errors.LoginError...but if you then check logged_in, it
      is True. Clearly that's wrong.
      
      The logic for setting logged_in will basically consider us logged
      in any time we process an API call and there is no 'anon' key in
      the userinfo dict *or there is no userinfo dict at all*. The last
      API call processed on a failed login attempt has no userinfo
      dict.
      
      This tweaks it so we only changed the logged_in value (in either
      direction) if the API call we're handling has a userinfo dict.
      
      We also fix the type of the empty userinfo we create if there
      isn't one in the call (no idea why it was a tuple, it doesn't
      really matter but it's weird) and explicitly set self.logged_in
      to False in Site initialization. I don't think this is strictly
      necessary as we can expect the init process to result in at least
      one API call with a userinfo dict, but it feels more correct.
      
      Signed-off-by: default avatarAdam Williamson <awilliam@redhat.com>
      e7c51daa
Loading