feat(generator): add pydantic_disable_protected_namespaces config

[msabramo]

Fixes: GH-982

Change Summary

Adds a pydantic_disable_protected_namespaces config setting. When this is true - e.g.: something like this in schema.prisma:

generator client {
  provider = "prisma-client-py"
  pydantic_disable_protected_namespaces = true
}

it adds:

protected_namespaces=()

to the Pydantic model_config.

Checklist

• Unit tests for the changes exist
• Tests pass without significant drop in coverage
• Documentation reflects changes where applicable
• Test snapshots have been updated if applicable

Agreement

By submitting this pull request, I confirm that you can use, modify, copy and redistribute this contribution, under the terms of your choice.

[RobertCraigie]

Thanks for the PR.

Out of curiosity, do you know if renaming those fields would be difficult / not ideal?

[msabramo]

Thanks for the PR.

Out of curiosity, do you know if renaming those fields would be difficult / not ideal?

Well I'm not the maintainer of that project, but I'd say it would be difficult because we have a deployment of that software and we have a database with tables with those fields. That said I guess Prisma has migrations and maybe it would take of the renaming, but I don't have a lot of experience with it.

The problem is that model has 2 meanings here. Model in the Pydantic sense but also in LiteLLM, the model is referring to the model in Large Language Model (LLM). So model actually a pretty reasonable prefix to have -- it's just unfortunate that it overlaps with pydantic terminology.

[RobertCraigie]

Thanks for the context, I will note that it is possible to rename fields at the client level without causing db migrations :)

Granted that in this case, model_ would really be the ideal field name anyway, I think this is a reasonable change.

I do wonder if this kind of setting should live on the model instead of the entire generator?

@Python(pydantic_disable_protected_namespaces: true)
model LiteLLM_ProxyModelTable {
  model_id String @id @default(uuid())
  model_name String 
  litellm_params Json
  model_info Json? 
  created_at    DateTime               @default(now()) @map("created_at")
  created_by String
  updated_at    DateTime               @default(now()) @updatedAt @map("updated_at")
  updated_by String
}

but I don't feel strongly.

[msabramo]

Yeah per-model seems nice. I think that would work.

[msabramo]

How would I change this to be per-model?

[RobertCraigie]

We have a Lark grammar for parsing @Python() declarations.

So you'd have to update the grammar/schema.lark file to support booleans, run nox -s lark, then it should be a case of updating this model type & using that config during codegen.

---

I just noticed my original example wouldn't be possible unfortunately, it'd have to be this fwiw

/// @Python(pydantic_disable_protected_namespaces: true)
model LiteLLM_ProxyModelTable {
  model_id String @id @default(uuid())
  model_name String 
  litellm_params Json
  model_info Json? 
  created_at    DateTime               @default(now()) @map("created_at")
  created_by String
  updated_at    DateTime               @default(now()) @updatedAt @map("updated_at")
  updated_by String
}

---

additionally, I appreciate this is more work than you originally signed up for with this PR so I'm happy to take this over the line myself but unfortunately it won't land particularly fast.

[msabramo]

Yeah, you can go ahead and take this over. I'm in no rush for this. Thanks!