PEP 722 and PEP 723 User Study Discussion

[barry-scott]

@cdce8p

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.

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.

[vovavili (Vladimir)]

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.

[pradyunsg (Pradyun Gedam)]

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.

[tim-mitchell]

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

[willingc (Carol Willing)]

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.

@courtneywebster

TL; DR

• Participants want the ability to specify 3rd-party dependencies and required Python versions.
• None of the participants had knowledge of or had used TOML syntax but did not necessarily view it as a blocker. PEP 722 syntax felt more aligned with their current experience but PEP 723 wasn’t incomprehensible.
• Participants felt both proposals would enable them to run and share Python scripts more easily.

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.

[brettcannon]

@tim-mitchell

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

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.

[gwerbin (Greg Werbin)]

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.

[pitrou (Antoine Pitrou)]

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

[KangOl (Christophe Simonis)]

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

[gwerbin (Greg Werbin)]

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.

[brettcannon]

@gwerbin

I do care about pausing this rush to approve either 722 or 732 and considering a slightly longer-term view.

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.

[brettcannon]

@KangOl

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

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.

@gwerbin

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.

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