Just to add my two-cent interpretation of these results, I’d say:
It seems there is a user desire to be able to specify some kind of metadata in single-file scripts, so in that sense these PEPs are on to something.
The fact that users were not super turned off by TOML is enough to make me think it’s worth trying to find a way to make that work somehow. There is no question that a full-fledged metadata format is more flexible and extensible than a plain dependencies-only format, and if users seem okay with handling such a format, why not take the opportunity to use it?
Unsurprisingly, I read users’ desire to specify Python version requirements along with package version requirements as an indication that we should try to treat Python as “just another dependency”. I’d be interested to see more canvassing for user thoughts on this matter (independent of these PEPs).
There are still some lingering questions about stuff like escaping and quoting, but I’m optimistic a solution can be found there. ↩︎
I think the times have changed. From my extremely limited experience with helping out, beginners these days rarely stick just to stdlib. They usually use at least pandas (though their pandas code is usually terrible), BeautifulSoup4 or requests, sometimes a GUI library like PyQT or PySimpleGUI, at the very least because that’s what all the educational material on the Internet uses. Even the book I learned Python with explicitly encouraged me to download libraries like pyperclip, PyPDF2, openpyxl, Pillow, etc. for its assignments.
Python version matters less to me than it used to. 3.6, f-strings, 3.7, dataclasses, 3.8, “=“ in fstrings, 3.9 “|” to merge dictionaries… So typically I can (without even thinking about it) have a script that is compatible with the last 3 releases, 4 if I avoid “|”.
On another note, without rereading the PEPS I can still remember 722 # Script Dependencies:, but would need to copy-paste 723 TOML. I think that adds to the “apprehension”. Although, with time, I suppose it would become as natural as other syntax.
First, @courtneywebster, thank you for the detailed and insightful summary of the user study. I found it interesting to read and tracks my experiences with Jupyter in education.
The TL; DR is interesting, and it affirms that PEP 722 and PEP 723 provide acceptable experiences. I could see either PEP to be useful. From an education standpoint, I, as an instructor, would wish to have the minimum Python version to be specified so that I could easily run/check the validity of the script each semester.
I actually think both 723 and 722 are useful and have legitimate places in the world. I tend to lean more in favor of 722 than 723, but that’s just my personal preference.
The point of my obnoxious re-posting of my own idea is that I care less about which one gets accepted, and more about avoiding the proliferation of new micro-standards that don’t interoperate with any others, serving only one particular limited purpose localized in time.
It seems like a surprising lack of restraint, uncharacteristic of the Python community.
-1 on -*-. The “coding” declaration was not often used in the first place, but it has become obsolete now that source files are utf8 by default. It’s also the only use of -*- in the Python ecosystem that I know of, so not really a standard IMHO.
I don’t particularly care if it’s /// or -*-, but I do care about pausing this rush to approve either 722 or 732 and considering a slightly longer-term view.
I also think it’s a natural choice to use what already exists, even if it’s a lot less popular than it used to be. We are Python programmers. We don’t reinvent wheels. We have a large inventory of wheels, some of which are a little old and dusty, but we ultimately use what works.
The fact that “coding” declarations are themselves obsolete doesn’t strike me as strong motivation to disregard the foundation of a standard syntax that’s already been laid here.
But unless we use a complete format that Emacs recognizes, I don’t think that connection is important. Plus we wouldn’t want to actually trigger Emacs anyway since the thing the comment specifies is scoped to just the comment and not the whole file, so we would have to be careful not to confuse Emacs.
You seem to be pushing for -*-, but that actually isn’t part of Python; the coding[=:]\s*([-\w.]+) regex is the critical marker in a comment at the top of the file. For instance, the few times I have specified the encoding cookie I have not used the marker that triggers Emacs as I am not an Emacs user; I’ve used # coding: ... and the Vim-supported format. So I personally don’t believe there’s that much of a “foundation” to -*- compared to /// (or any other comment delimiter that I’ve seen suggested which won’t accidentally break when run under a formatter).