Skip to content

Clarify safety_level get/set index mismatch is intentional (#173)#175

Open
beaufour wants to merge 1 commit into
masterfrom
fix-safety-level-docstring
Open

Clarify safety_level get/set index mismatch is intentional (#173)#175
beaufour wants to merge 1 commit into
masterfrom
fix-safety-level-docstring

Conversation

@beaufour

@beaufour beaufour commented Jul 7, 2026

Copy link
Copy Markdown
Collaborator

Summary

Fixes the misleading Photo.getSafetyLevel() docstring shipped in #174 / 0.8.1.

getSafetyLevel() returns Flickr's raw 0-indexed value from getInfo/search (0=safe, 1=moderate, 2=restricted), but flickr.photos.setSafetyLevel expects a 1-indexed value (1=safe, 2=moderate, 3=restricted). The old docstring wrongly claimed the two scales matched, so following its own example would set the wrong safety level (reported in #173).

This is a long-standing asymmetry in the Flickr API itself, not a bug in this library — we intentionally pass both values through unchanged rather than normalise them. This PR makes that explicit.

Changes (docs only, no behaviour change)

  • Rewrite the getSafetyLevel() docstring: document the real 0-indexed scale, state the mismatch with setSafetyLevel is by design, and show the +1 conversion for round-tripping.
  • Add a matching note at the safety_level converter so readers of the raw attribute see the same caveat.

Verification

Confirmed the 0-indexed getInfo scale against independent sources:

  • Flickr's official setSafetyLevel docs — 1-indexed setter.
  • The Flickr Foundation's own flickr-photos-api parse_safety_level() — maps getInfo 0/1/2 → safe/moderate/restricted.
  • A recorded real getInfo response in that repo returning safety_level="0" for a safe photo.

Existing test/test_photos.py passes (38 passed).

🤖 Generated with Claude Code

getSafetyLevel() returns Flickr's raw 0-indexed value (0=safe, 1=moderate,
2=restricted) from getInfo/search, while setSafetyLevel expects a 1-indexed
value (1=safe, 2=moderate, 3=restricted). This is a long-standing asymmetry
in the Flickr API itself, not a bug in this library.

PR #174 shipped a docstring wrongly claiming the two scales match. Correct
the getSafetyLevel() docstring to document the real 0-indexed scale, note
the mismatch is intentional (we mirror Flickr rather than normalise), and
show the +1 conversion for round-tripping into setSafetyLevel. Add a
matching note at the safety_level converter.

Verified against the Flickr Foundation's own flickr-photos-api parser and a
recorded getInfo API response (safety_level="0" -> safe).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant