Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve key naming clarity and consistency across REST requests #683

Open
ossa-ma opened this issue Feb 18, 2025 · 6 comments · May be fixed by #714
Open

Improve key naming clarity and consistency across REST requests #683

ossa-ma opened this issue Feb 18, 2025 · 6 comments · May be fixed by #714
Assignees
Labels
component:other Questions unrelated to SDK status:triaged Issue/PR triaged to the corresponding sub-team type:feature request New feature request/enhancement

Comments

@ossa-ma
Copy link

ossa-ma commented Feb 18, 2025

Description of the feature request:

It is not immediately obvious that both camel casing and underscore pythonic style casing are interchangeable for the input data keys to Gemini. It would be helpful to note this somewhere as there are several examples where both styles are used in a confusing fashion often time in the same input json:

An example:
...

"generationConfig": {
            "stopSequences": [
                "Title"
            ],
            "temperature": 1.0,
            "maxOutputTokens": 800,
            "topP": 0.8,
            "topK": 10,
            "response_mime_type": "application/json",
             "response_schema": {
                "type": "ARRAY",
                "items": {
                  "type": "OBJECT",
                  "properties": {
                    "recipe_name": {"type":"STRING"},
                  }
                }
              }
}

...

References:
https://github.com/google-gemini/generative-ai-python/blob/8849d4f46010ce4ae68243c4f8a44a138b56598f/samples/rest/configure_model_parameters.sh#L20
https://github.com/google-gemini/generative-ai-python/blob/8849d4f46010ce4ae68243c4f8a44a138b56598f/samples/rest/controlled_generation.sh#L13

It also doesn't help that the general version of the API reference denotes everything in camel case so if a developer is only referring to that it would create a confusing situation:
https://ai.google.dev/api/generate-content#generationconfig

What problem are you trying to solve with this feature?

Improved clarity and consistency in Gemini API documentation, reduces potential for errors imo.

Any other information you'd like to share?

No response

@Gunand3043 Gunand3043 added type:feature request New feature request/enhancement status:triaged Issue/PR triaged to the corresponding sub-team component:python sdk Issue/PR related to Python SDK labels Feb 18, 2025
@MarkDaoust MarkDaoust added component:other Questions unrelated to SDK and removed component:python sdk Issue/PR related to Python SDK labels Feb 18, 2025
@MarkDaoust
Copy link
Collaborator

@Giom-V - you were looking at rest samples, maybe look into enforcing this at the same time?

@ossa-ma
Copy link
Author

ossa-ma commented Feb 18, 2025

I think it would also be useful to add a script example for generating content with pdfs as inline data (not file data).

I have included an example below:

echo "[START text_gen_multimodal_two_pdf_inline]"
# Use a temporary file to hold the base64 encoded pdf data

PDF_PATH_1=${MEDIA_DIR}/test_1.pdf
PDF_PATH_2=${MEDIA_DIR}/test_2.pdf

TEMP_1_B64=$(mktemp)
trap 'rm -f "$TEMP_1_B64"' EXIT
base64 $B64FLAGS $PDF_PATH_1 > "$TEMP_1_B64"

TEMP_2_B64=$(mktemp)
trap 'rm -f "$TEMP_2_B64"' EXIT
base64 $B64FLAGS $PDF_PATH_2 > "$TEMP_2_B64"

# Use a temporary file to hold the JSON payload
TEMP_JSON=$(mktemp)
trap 'rm -f "$TEMP_JSON"' EXIT

cat > "$TEMP_JSON" << EOF
{
  "contents": [{
    "role": "user",
    "parts":[
      {"text": "Extract the pet names, type and ages from these documents."},
      {
        "inline_data": {
          "mime_type":"application/pdf",
          "data": "$(cat "$TEMP_1_B64")"
        },
        "inline_data": {
          "mime_type":"application/pdf",
          "data": "$(cat "$TEMP_2_B64")"
        }
      }
    ]
  }],
  "system_instruction": {
    "parts": [
      {"text": "Extract the pet names and ages from these documents and return them in the following JSON format:

                Pet = {\"name\": str, \"type\": str, \"age\": int}
                Return: list[Pet]"
      }
    ]
  },
  "generation_config": {
    "temperature": 0.2,
    "top_p": 0.95,
    "top_k": 40,
    "max_output_tokens": 1000,
    "response_mime_type": "application/json"
  }
}
EOF

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=$GOOGLE_API_KEY" \
    -H 'Content-Type: application/json' \
    -X POST \
    -d "@$TEMP_JSON" 2> /dev/null

@demoncoder-crypto
Copy link

Hey, I would love to work on this issue.

@Giom-V
Copy link
Contributor

Giom-V commented Mar 10, 2025

@demoncoder-crypto Feel free to send a PR, I'll review it.

demoncoder-crypto pushed a commit to demoncoder-crypto/generative-ai-python that referenced this issue Mar 11, 2025
… Standardize on camelCase for REST API parameter names - Update README.md to document parameter naming conventions - Create new inline_pdf_example.sh with consistent naming - Fix inconsistent naming in several example files - Fixes google-gemini#683
@demoncoder-crypto
Copy link

To resolve this issue, I recommend

1)- Updating all shell scripts in the samples/rest directory to use consistent naming
2)- Documenting the flexibility- by adding a note in the REST API documentation which explains both naming conventions that are supported and including this information in the README.md or in comments at the top of the REST example files.
3)- Developing a Style guide to demonstrate internal guidelines for contributors.

@ossa-ma
Copy link
Author

ossa-ma commented Mar 11, 2025

@demoncoder-crypto I've left comments on the pull request regarding some changes that you missed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:other Questions unrelated to SDK status:triaged Issue/PR triaged to the corresponding sub-team type:feature request New feature request/enhancement
Projects
None yet
6 participants