PEP 722 and PEP 723 User Study Discussion

When I went to university I was already using linux, so for me it was easier
to just stick to the packaged libraries and hopefully never need the others.

A couple of years after I became a debian contributor and started packaging
the python modules I needed.

Before graduating and starting to work I had never once used venv and pip.

Now I still prefer using packages that are available in my distribution :smiley:

Just to add my two-cent interpretation of these results, I’d say:

  1. 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.
  2. 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?[1]
  3. 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).

  1. There are still some lingering questions about stuff like escaping and quoting, but I’m optimistic a solution can be found there. ↩︎

3 Likes

Clearly the concept (simply specify dependencies inline) is considered very useful.

TOML seems little known, and apparently even triggered apprehension in all participants. Also the implied generality caused misconceptions about imaginary capabilities:

In the last few months no substantial use cases have been found for TOML, beyond specifying the Python version. If that can be done with

it seems that would avoid unneeded complexity, lower the learning curve, be easier to remember, and cause fewer misconceptions.

2 Likes

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.

1 Like

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.

5 Likes

That’s a good point! Maybe I don’t write enough pyproject.toml files but every time I do, I have to look up the keys again just to make sure. # Script Dependencies: is much easier to remember IMO.

1 Like

With the exception of PySimpleGUI, all the ones you mentioned are available from distribution packages.

Whatever is picked will be easy to find examples for.
I doubt that it makes any difference once it is implemented on ease to learn.

1 Like

Maybe, but that’s Linux only, which is ~1-2% of all desktop machines. So until winget and Homebrew become universally adopted, ~98% of desktop users starting out with Python still have to use pip.

1 Like

This discussion has deviated significantly from the original topic here folks.

I’d request that folks hold off on further discussion/speculation in the direction of what students are capable of or do, what the relevance of Python versions is, platform usage etc.

12 Likes

As an experienced dev who hardly ever writes TOML, my vote is for PEP 723.

My one hesitancy is the # /// marker. Why prefer a marker no-one else has ever used? Why not use a familiar one like # ``` (apart from it being hard write in markdown).

1 Like

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.

4 Likes

Because people may not understand that syntax naturally either, plus Markdown isn’t really baked into Python like it is for e.g. Rust.

There was a massive amount of discussion on this topic over in the PEP 723 thread.

6 Likes

I still feel strongly that my proposal to reuse -*- from the “coding” declaration is a good choice for all the same reasons as ///, but also with the benefit of already being an in-use standard: PEP 723: Embedding pyproject.toml in single-file scripts - #139 by gwerbin

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.

8 Likes

As said in the documentation, the -*- marker is be compatible with emacs.

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.

1 Like

There is definitely no rushing here. This whole topic has been extensively discussed for months which led to those PEPs which have also been discussed for quite a while.

3 Likes

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).

6 Likes

I announced my decision as PEP delegate at PEP 722/723 decision.