graphql-python / graphql-core-legacy

GraphQL base implementation for Python (legacy version – see graphql-core for the current one)

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Revert the removal of the `_value` postfix in the graphql() function

Cito opened this issue · comments

In f6d79ab, the _value postfix of some of the graphql() parameters has been removed and gives a deprecation warning now.

I propose to revert that change (and reverse the deprecation message, i.e. display it now for the shorter names instead), because:

  • We want to be as compatible with GraphQL.js (the "GraphQL reference implementation") as possible, including the naming. This makes it easier for us to keep in sync with GraphQL.js in the future and for developers to translate examples directly from JavaScript to Python (you only need to translate from camelCase to snake_case, but not change names).
  • The _value postfix still exists in the ExecutionContext which is inconsistent
  • graphql-core-next and graphql-core/modern branch also use the names with the _value postfix

If we believe the _value postfix is really stupid and unnecessary or want to make other name changes, then please in the future let's first try to convice the GraphQL.js people (who are nice and responsive) to make that change there, and then we can replicate it in Python.

@syrusakbary - what do you think?

commented

My understanding is that graphql-core's purpose is to match the js impl as closely as possible. Even in cases where that makes it a bit un-pythonic it makes it easier to keep it up-to-date with the reference implementation in js. I think that's one of the reasons graphene even exists: as a more pythonic, easier-to-use layer on top of graphql-core.

So I'm fine with making the variable names a bit worse (in my opinion) in order to make it easier to stay up-to-date. Also good to have this be close-ish to graphql-core-next so it's easier for people to switch over to that. I don't think _value is even important enough to talk to graphql.js people about.

Ok, so I have reverted this change now. Starting with v2.3 the old parameter names will be valid again. The short parameter names still work, but will now produce deprecation warnings.