Language specifications for strings

In PyCharm you can set the programming/markup language of strings like this:

# language=html
foo = '<div>hello there!</div>'

I find this extremely useful and use it all over the place. A pattern I noticed is that a large proportion of such uses are in fact more like:

# language=html
foo = format_html("<div>{}</div", bar)

In this case the format_html function doesn’t take any random string as the first argument, it takes a string that is supposed to be html. Reading through my usage of # language= I see that I have CSS, HTML, and JavaScript.

There are many places in my codebases that also have very different types of “languages” that unfortunately isn’t supported as a language injection in PyCharm. Some examples:

fully qualified name (module.module.symbol, for example view functions in Django)
module names (module.module, for example app names in Django)

• file paths
• host names (www.example.com)
• urls (https://example.com/)
• time zone (UTC)
• language code (en)
• regexes
• date formats
• django app names

There are probably more, but I think this gets the point across.

PyCharm has some (presumably hardcoded) rules about some of these strings, for example in settings.py it knows that strings in the list INSTALLED_APPS are module names, so you can jump to the definitions of those modules, and PyCharm will resolve and check them for you. But this is a closed system where any introduced variables I create myself can’t be validated in this way.

I think it would be good if python typing could have a facility for this type of thing. When this gets some traction we could see support for it in Python language servers, PyCharm, static analysis tools, etc.

What do you guys think?

(originally posted at https://discuss.python.org/t/language-specifications-for-strings/21826/1 where it was suggested that this is the right place for this discussion)

Commencez par lire la proposition et le fil de discussion lié sur discuss.python.org, puis comparez les catégories de chaînes demandées, telles que HTML, les noms de modules, les URLs, les expressions régulières et les formats de date. Un résultat complet définirait une fonctionnalité de typing de Python suffisamment clairement pour que les serveurs de langage, PyCharm et les outils d’analyse statique puissent la prendre en charge.