I will rather vote to mention that while ending scripts in .py is not prohibited, it's discouraged. To make clear what's our preference. And rather keep MUST have .py ending for modules.

I think the main advantage to having the .py extension is that the editor knows the language of the file and flake8 can run on it. So I would strongly suggest if we adopt this that we require that there be minimal implementation in such files. With such a requirement I am mildly in favor of this propose. Without it, I am strongly against.

I hope we can all agree that complex python scripts with no .py extension is a bad idea.

I'm absolutely in favor of keeping script files small, and with no real logic (one-off scripts that never get committed to git are another matter, in both that and whether a .py extension makes sense, and even whether our coding conventions apply).

From a more meta perspective, I'm not really in favor of using the dev guide to re-state best practices that are well established and well stated outside our own documentation ecosystem. Maybe it's just me, but I feel like our conventions are too big and hard to internalize already (this RFC exists because I wasn't aware of the current rule, after all), and I would much prefer for them to more tightly focus on policy and style choices that are about standardization rather than education.

I also philosophically dislike constraining any aspect of interface to editor integration concerns - that's a level of implementation detail even deeper than language choice. I don't deny using suffixes for editors is convenient, and it's why I will continue to write one-off scripts with .py extensions - but if we need to work a little harder (or even clutter up our repos or file headers with a bit more stuff to make everyone's editors happy) to keep editor behavior from affecting interface decisions, so be it.

I agree with Jim's comments above, but would add — I suspect that most editors can be convinced to detect file types based on the contents of the hashbang line in addition to (or instead of) the file extension, so the flake8 issue may be a red-herring.

Also, we already have reasonably strong conventions that scripts should be small. I suggest we use implementation of RFC as a reason to push on DM-24281 and turn those conventions into documented standards.

I'm not really in favor of using the dev guide to re-state best practices that are well established and well stated outside our own documentation ecosystem.

I'm not sure about this, as not every developer will necessarily be fully plugged into the external ecosystem. At a minimum, we should have a reference to the best statements of best practices for educational purposes. But other than that I'm fine with not explicitly duplicating such conventions in our style guides.

As to the particular case mentioned here, I had not really interpreted the rule to apply to non-module scripts, but given that the text can be interpreted differently, I welcome clarification or removal.

This is only ever so slightly contentious around the edges; there seems to be broad agreement on the core proposal.  I'm adopting this with the intent to keep it minimal: clarify that the rule on Python module naming does not extend to script files, with a brief aside that such files should not contain much code.

I'd be happy for someone else to use this as motivation to work on DM-24281, but I don't want to make either ticket a blocker on the other; I already have an embarrassingly long list of adopted-not-implemented RFCs to follow up on, and don't want to make implementing this one any harder than it has to be.

One tricky thing about implementing this RFC: it may be difficult to flake8-check the (minimal) script file (outside an editor, unlike the comments above). https://github.com/tholo/pytest-flake8/issues/27

I considered this during the RFC discussion. I'm inclined to say that this policy only applies to minimal script files and not scripts that include business logic. There is only one line of python in the minimalist files so living without the flake8 check seems like a low risk to code maintainability.

In theory the linting job that runs on github could be changed to include a flake8 bin.src/* since only python files should be in bin.src. Then we would catch any problems even if pytest missed them.