sys.path is a hack - bringing it back under control
Hi, I often find this in my scripts/projects, that I run directly from checkout: DEVPATH = os.path.dirname(os.path.abspath(__file__)) sys.path.insert(0, DEVPATH) This seems like a hack to me, because the process of sys.path modification is completely out of control for Python application developer, which means it is easy to break an application and get lost. I don't remember the exact user story for that bad association with sys.path (perhaps Django issue #1908), but something makes me feel that I am not alone: http://stackoverflow.com/questions/5500736/troubleshooting-python-sys-path What I'd like to propose is some control/info over what modified sys.path. The simplest case: 1. make sys.path a list of pairs (path, file-that-added-the-path) 2. make sys.path read-only 3. add sys.path.add() method for modification 4. logger for sys.path.add() events (or recipe how to implement it in documentation) This will help a lot. Limiting sys.path may cause a loss of some functionality if you need to remove some or replace it completely, but I don't know where the ability to reset() sys.path can be useful. -- anatoly t.
Le 20/02/2012 10:47, anatoly techtonik a écrit :
Hi, You shouldn’t have to do that if you’re running 'python something.py'
http://docs.python.org/py3k/library/sys.html#sys.path The trick is to place the script in the directory that you want in the path, ie. next to top-level packages. But from your code above this seems to be the case already... Regards, -- Simon Sapin
On Mon, Feb 20, 2012 at 1:06 PM, Simon Sapin <simon.sapin@kozea.fr> wrote:
But I did for some reason, and right now I can't even say if it was Windows, Linux, FreeBSD, PyPy, IPython, gdb or debugging from IDE. As initialized upon program startup, the first item of this list,
s/trick/hack/ and it will be just what I am saying. Not many Python projects use this structure. -- anatoly t.
anatoly techtonik wrote:
If you can't say why you did it, how can we judge whether you did it for a good reason or a bad reason? Having a user-accessible search path is not a hack, or if it is, it is a hack in the positive sense: a feature, not a design bug. The same concept is used by Unix tools, via the PATH environment variable. It is "the simplest thing that could possibly work" for solving the problem of configurable search paths. Personally, I don't believe sys.pack needs to be brought back under control, because I don't believe it is out of control. Most code doesn't need to mess with the path; of that which does, most does not lead to problems. The only time I have seen path problems is when I have accidentally shadowed standard library modules, and they are simple to solve. Perhaps others have experienced harder problems, and if so, they have my sympathy, but I don't believe this is a problem so great that it needs to break backward compatibility. I would say, though, that nearly every time I have changed sys.path, I would have been satisfied with some way of importing directly from a known location. import spam from 'this/is/a/relative/path' from spam import ham from '/and/this/is/an/absolute/path' sort of thing, although I can see that import...from and from...import are too similar for comfort. -- Steven
On Mon, Feb 20, 2012 at 7:47 PM, anatoly techtonik <techtonik@gmail.com> wrote:
PEP 395 describes my current plan to fix sys.path initialisation (however, I can't yet promise that it will make it into 3.3, since it doesn't even have a reference implementation yet, and I have several other things I want to get done first). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Feb 20, 2012 at 1:38 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
tl;dr :( The abstract doesn't give any valuable info. "proposes new mechanisms to eliminate some longstanding traps" doesn't say anything. Which mechanssms? What traps? I see there a mention of my problem with Django. How can it help to debug other sys.path problems? Do I really have to read 15 page document to understand that? -- anatoly t.
On Mon, Feb 20, 2012 at 11:18 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Perhaps you could try reading the Table of Contents, too. (Hopefully you don't find it too long - it's 20+ lines) Or else you may want to refrain from participating in language discussions if you aren't interested in understanding the topic in depth. No serious design discussion can possibly be held amongst people that are only willing to read a PEP abstract rather than the full PEP. (But then, it's been suggested many times in the past that you may get better responses if you don't make a habit of effectively calling the current core developers a bunch of incompetent idiots, and that doesn't appear to have had the slightest effect on your style of communication. Why should this be any different?). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Feb 20, 2012 at 5:16 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I've read the ToC, but which of these parts answers the question: "How to make debugging sys.path problems easier?" Abstract Relationship with Other PEPs What's in a __name__? Traps for the Unwary Why are my imports broken? Importing the main module twice In a bit of a pickle Where's the source? Forkless Windows Qualified Names for Modules Alternative Names Eliminating the Traps Fixing main module imports inside packages Optional addition: command line relative imports Compatibility with PEP 382 Incompatibility with PEP 402 Potential incompatibilities with scripts stored in packages Fixing dual imports of the main module Fixing pickling without breaking introspection Fixing multiprocessing on Windows Explicit relative imports
I didn't want to offend anybody by giving an impression that what you're doing is not important. I realize that there are papers that people need to read, especially who are willing to participate in ideas discussion, but the point is that I'd like to have a simple answer for a simple proposal. I read the proposal. In the following order: PEP-0395: Abstract PEP-3155: Rationale (skimmed) PEP-3155: Proposal (reread several times, a lot of questions) PEP-3155: Discussion (skim, got a feeling that there should be a link to the actual discussion) PEP-3155: Naming choice PEP-3155: References (is still not clear what is `qualified name`) http://en.wikipedia.org/wiki/QName http://translate.google.com/#auto|ru|qualified%20name (got translation that it is 'full name' - that makes sense) PEP-3155: Naming choice (all right, the more intuitive 'full name' and 'path' are not really 'full name' and filesystem path, so the name is different) PEP-0395: Contents PEP-0395: Qualifed Names for Modules (started - "To make it feasible to fix these problems once and for all, it is proposed to add a new module level attribute: __qualname__" - which problems?) PEP-0395: Traps for the Unwary ("The overloading of the semantics of __name__, along with some historically associated behaviour in the initialisation of sys.path[0], has resulted in several traps for the unwary" - damn, how is this gonna help to debug sys.path problems? gave up, wrote a sad tl;dr smile) Now I hope it gives an overview what difficulties a person who is out-of-context has while trying to solve one tiny user story of debugging sys.path. I just want everything to be as much simplified as possible, possibly killing the fun for prose readers. Maybe I don't really want to think about complex PEP matters, because the idea is just an episode in the daily workflow. I'd also really prefer to keep complicated matters (e.g. discussions) around tiny user stories, that don't require much time to load into the brain and you can only concentrate on two or three of them that are conflicting. Proposal to read 15 page technical paper doesn't work well with this scenario, so if you just said - "Yes. You have to read that.", I'd reply "Well, ok. Next time then.". (But then, it's been suggested many times in the past that
I am not an English writer, but I am interested to know where did this impression of me calling core developers a bunch of incompetent idiots is coming from. If anybody can quote concrete example and explain in private - I may have a chance to change something. My English is a result of learning legal and technical English texts, not love letters, and I may not possess the communication skills required to write proper letters in informal language (which also I prefer more than business stuff). I can write in third person without *you* or *I* other personal pronounce, but it takes more time to compose the proper form, so the note like this one can take an hour or more (it already took more), and time is that I really lack. Not me alone, though, but I may be too obsessed with saving someone else's time by placing too much attention to it, indeed. -- anatoly t.
On 2/20/2012 12:39 PM, anatoly techtonik wrote:
I am not an English writer,
I am a native English (American) speaker/writer who can barely write in one other natural language (Spanish). So I have great sympathy for and appreciation for those who struggle with English. And I am willing to help those who wish to improve.
From the way you have written in the past. Nick may have been exaggerating a bit, but I have gotten similar impressions, though you have been writing better and more effectively recently. I think it was just a month ago that you were persuasive enough to get something added for 3.3.
If anybody can quote concrete example and explain in private - I may have a chance to change something.
Now that I know that it is not your intention to come across as antagonistic, I will try to do the above if I see bad examples in the future.
My English is a result of learning legal and technical English texts,
The legal part in interesting. Legal English in adversarial situations is used to metaphorically club people -- or to confuse people. In reading the Argentina Python users list, I have noticed that conversational Spanish is not exactly the same as the formal Spanish I learned in classes some decades ago. But it is sometimes hard to know what is a sloppy error and what is an accepted idiom. -- Terry Jan Reedy
On Tue, Feb 21, 2012 at 3:39 AM, anatoly techtonik <techtonik@gmail.com> wrote:
I've read the ToC, but which of these parts answers the question: "How to make debugging sys.path problems easier?"
Ah, my apologies. I must confess to having misread your original email (I paid too much attention to the first half, not enough to the latter). PEP 395 aims to avoid people feeling the need to mess with sys.path in the first place, thus reducing the likelihood of problems occurring in the first place. For *debugging* sys.path, as you say, the problem is figuring out who is messing it up after problems have already occurred and you've found strange entries in there. There's definitely a case to be made that sys.path should be a smarter kind of object by default, one that accepts callbacks to be triggered when modifications occur. (such behaviour would be useful for updating namespace package __path__ attributes, for instance). However, for purely debugging purposes, it should be sufficient to monkeypatch sys.path with an object that write any changes through to the original path, while overriding the various mutations methods to report the source of the modification (via stack introspection). IIt's the same kind of technique you can use to investigate faults in *any* kind of container. (Versions based on UserDict and UserList might be interesting Python Cookbook recipes).
The fault was mine - I didn't understand your suggestion correctly, so I didn't realise that PEP 395 doesn't actually address it.
Anatoly, thanks for taking the time to explain that. The impression comes from the fact that many of the things you object to within Python are largely a result of limited availability of development resources, so even things that are at least arguably good ideas simply don't get investigated. The universe of good ideas is vast, the universe of bad ideas is even larger, but the space we have the capacity to explore is actually relatively tiny. Since there's such an enormous number of things that *could* be done, the answer to "why aren't they done?" is almost always going to "because people don't think they're important enough to do them instead of all the other things they're doing". Deciding how to spend our time on Python-related efforts is a matter of perceived priorities and potential payoffs and those are always going to vary substantially across individuals. Being more willing to accept that as a rationale for not doing things would go a long way towards reducing the negative reactions - I know mine arise not so much for your initial suggestions (which are often, although not always, quite reasonable ideas in a world where we had unlimited development resources), but from subsequently continuing to push them in the face "because we're simply not interested in doing that" and "the status quo may not be perfect, but it's good enough that it isn't worth the hassle of changing" responses. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hello, I am a bit confused. Tests are best not located amongst code, but in a sub directory. I was strongly stated on #python to use unittest(2) or nose in order not to use the path hacks. so did stackoverflow also stated when I googled it : http://stackoverflow.com/questions/61151/where-do-the-python-unit-tests-go Okay unittest tries relative import by adding a dot in front of the name, but in the fallback, in the end, does not it uses the sys path hack ? (my eyes may be old, my brain damaged by alcohol, but it looks very much this way). It looks like hiding dust under the carpet, and stating that by tabooing sys.path hack use and locating it in very savant module, the problem gets solved. I am honestly, just very candid on this one, and pretty puzzled. sys path hack, looks to me a lot like coupling between classes, global varaibles, or gotos, and other beasts. It may be needed and yet powerful therefore great wisdom is needed to handle them carefully. PS (not sure I am 100% serious after this point) Why not create a module like __use_wisefully__ then ? people would be warned by being compelled to write : from __use_wisefully__ import sys.path ? Cheers, -- Jul
On Feb 20, 11:18 pm, anatoly techtonik <techto...@gmail.com> wrote:
tl;dr :(
You're _constantly_ bemoaning the "obvious" lack of clear communication paths in the Python community, and yet when you're pointed to an _explicit piece of documentation that answers your concerns_ you can't even be bothered to read it. It's pretty damn "obvious" that your only real issue with communication is when it isn't being spoon fed to you.
On Tue, Feb 21, 2012 at 1:37 PM, alex23 <wuwei23@gmail.com> wrote:
In Anatoly's defence (and as he clarified in a later message), PEP 395 really *didn't* answer his question, and he had made his way through quite a bit of it (and PEP 3155, which it references) before giving up on trying to figure out how it was relevant - I had simply misunderstood the original email. After I *did* understand it, I pointed out that investigating unexpected or undesirable modifications to mutable containers when the data changes aren't enough to pinpoint the culprit is actually one of the valid use cases for monkeypatching rather than a reason to change the language behaviour. (That said, there are other, more valid, arguments in favour of providing a notification mechanism for sys.path changes, mainly relating to namespace packages. That's a different discussion, though, and one more appropriate for import-sig). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Le 20/02/2012 10:47, anatoly techtonik a écrit :
Hi, You shouldn’t have to do that if you’re running 'python something.py'
http://docs.python.org/py3k/library/sys.html#sys.path The trick is to place the script in the directory that you want in the path, ie. next to top-level packages. But from your code above this seems to be the case already... Regards, -- Simon Sapin
On Mon, Feb 20, 2012 at 1:06 PM, Simon Sapin <simon.sapin@kozea.fr> wrote:
But I did for some reason, and right now I can't even say if it was Windows, Linux, FreeBSD, PyPy, IPython, gdb or debugging from IDE. As initialized upon program startup, the first item of this list,
s/trick/hack/ and it will be just what I am saying. Not many Python projects use this structure. -- anatoly t.
anatoly techtonik wrote:
If you can't say why you did it, how can we judge whether you did it for a good reason or a bad reason? Having a user-accessible search path is not a hack, or if it is, it is a hack in the positive sense: a feature, not a design bug. The same concept is used by Unix tools, via the PATH environment variable. It is "the simplest thing that could possibly work" for solving the problem of configurable search paths. Personally, I don't believe sys.pack needs to be brought back under control, because I don't believe it is out of control. Most code doesn't need to mess with the path; of that which does, most does not lead to problems. The only time I have seen path problems is when I have accidentally shadowed standard library modules, and they are simple to solve. Perhaps others have experienced harder problems, and if so, they have my sympathy, but I don't believe this is a problem so great that it needs to break backward compatibility. I would say, though, that nearly every time I have changed sys.path, I would have been satisfied with some way of importing directly from a known location. import spam from 'this/is/a/relative/path' from spam import ham from '/and/this/is/an/absolute/path' sort of thing, although I can see that import...from and from...import are too similar for comfort. -- Steven
On Mon, Feb 20, 2012 at 7:47 PM, anatoly techtonik <techtonik@gmail.com> wrote:
PEP 395 describes my current plan to fix sys.path initialisation (however, I can't yet promise that it will make it into 3.3, since it doesn't even have a reference implementation yet, and I have several other things I want to get done first). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Feb 20, 2012 at 1:38 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
tl;dr :( The abstract doesn't give any valuable info. "proposes new mechanisms to eliminate some longstanding traps" doesn't say anything. Which mechanssms? What traps? I see there a mention of my problem with Django. How can it help to debug other sys.path problems? Do I really have to read 15 page document to understand that? -- anatoly t.
On Mon, Feb 20, 2012 at 11:18 PM, anatoly techtonik <techtonik@gmail.com> wrote:
Perhaps you could try reading the Table of Contents, too. (Hopefully you don't find it too long - it's 20+ lines) Or else you may want to refrain from participating in language discussions if you aren't interested in understanding the topic in depth. No serious design discussion can possibly be held amongst people that are only willing to read a PEP abstract rather than the full PEP. (But then, it's been suggested many times in the past that you may get better responses if you don't make a habit of effectively calling the current core developers a bunch of incompetent idiots, and that doesn't appear to have had the slightest effect on your style of communication. Why should this be any different?). Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Mon, Feb 20, 2012 at 5:16 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
I've read the ToC, but which of these parts answers the question: "How to make debugging sys.path problems easier?" Abstract Relationship with Other PEPs What's in a __name__? Traps for the Unwary Why are my imports broken? Importing the main module twice In a bit of a pickle Where's the source? Forkless Windows Qualified Names for Modules Alternative Names Eliminating the Traps Fixing main module imports inside packages Optional addition: command line relative imports Compatibility with PEP 382 Incompatibility with PEP 402 Potential incompatibilities with scripts stored in packages Fixing dual imports of the main module Fixing pickling without breaking introspection Fixing multiprocessing on Windows Explicit relative imports
I didn't want to offend anybody by giving an impression that what you're doing is not important. I realize that there are papers that people need to read, especially who are willing to participate in ideas discussion, but the point is that I'd like to have a simple answer for a simple proposal. I read the proposal. In the following order: PEP-0395: Abstract PEP-3155: Rationale (skimmed) PEP-3155: Proposal (reread several times, a lot of questions) PEP-3155: Discussion (skim, got a feeling that there should be a link to the actual discussion) PEP-3155: Naming choice PEP-3155: References (is still not clear what is `qualified name`) http://en.wikipedia.org/wiki/QName http://translate.google.com/#auto|ru|qualified%20name (got translation that it is 'full name' - that makes sense) PEP-3155: Naming choice (all right, the more intuitive 'full name' and 'path' are not really 'full name' and filesystem path, so the name is different) PEP-0395: Contents PEP-0395: Qualifed Names for Modules (started - "To make it feasible to fix these problems once and for all, it is proposed to add a new module level attribute: __qualname__" - which problems?) PEP-0395: Traps for the Unwary ("The overloading of the semantics of __name__, along with some historically associated behaviour in the initialisation of sys.path[0], has resulted in several traps for the unwary" - damn, how is this gonna help to debug sys.path problems? gave up, wrote a sad tl;dr smile) Now I hope it gives an overview what difficulties a person who is out-of-context has while trying to solve one tiny user story of debugging sys.path. I just want everything to be as much simplified as possible, possibly killing the fun for prose readers. Maybe I don't really want to think about complex PEP matters, because the idea is just an episode in the daily workflow. I'd also really prefer to keep complicated matters (e.g. discussions) around tiny user stories, that don't require much time to load into the brain and you can only concentrate on two or three of them that are conflicting. Proposal to read 15 page technical paper doesn't work well with this scenario, so if you just said - "Yes. You have to read that.", I'd reply "Well, ok. Next time then.". (But then, it's been suggested many times in the past that
I am not an English writer, but I am interested to know where did this impression of me calling core developers a bunch of incompetent idiots is coming from. If anybody can quote concrete example and explain in private - I may have a chance to change something. My English is a result of learning legal and technical English texts, not love letters, and I may not possess the communication skills required to write proper letters in informal language (which also I prefer more than business stuff). I can write in third person without *you* or *I* other personal pronounce, but it takes more time to compose the proper form, so the note like this one can take an hour or more (it already took more), and time is that I really lack. Not me alone, though, but I may be too obsessed with saving someone else's time by placing too much attention to it, indeed. -- anatoly t.
On 2/20/2012 12:39 PM, anatoly techtonik wrote:
I am not an English writer,
I am a native English (American) speaker/writer who can barely write in one other natural language (Spanish). So I have great sympathy for and appreciation for those who struggle with English. And I am willing to help those who wish to improve.
From the way you have written in the past. Nick may have been exaggerating a bit, but I have gotten similar impressions, though you have been writing better and more effectively recently. I think it was just a month ago that you were persuasive enough to get something added for 3.3.
If anybody can quote concrete example and explain in private - I may have a chance to change something.
Now that I know that it is not your intention to come across as antagonistic, I will try to do the above if I see bad examples in the future.
My English is a result of learning legal and technical English texts,
The legal part in interesting. Legal English in adversarial situations is used to metaphorically club people -- or to confuse people. In reading the Argentina Python users list, I have noticed that conversational Spanish is not exactly the same as the formal Spanish I learned in classes some decades ago. But it is sometimes hard to know what is a sloppy error and what is an accepted idiom. -- Terry Jan Reedy
On Tue, Feb 21, 2012 at 3:39 AM, anatoly techtonik <techtonik@gmail.com> wrote:
I've read the ToC, but which of these parts answers the question: "How to make debugging sys.path problems easier?"
Ah, my apologies. I must confess to having misread your original email (I paid too much attention to the first half, not enough to the latter). PEP 395 aims to avoid people feeling the need to mess with sys.path in the first place, thus reducing the likelihood of problems occurring in the first place. For *debugging* sys.path, as you say, the problem is figuring out who is messing it up after problems have already occurred and you've found strange entries in there. There's definitely a case to be made that sys.path should be a smarter kind of object by default, one that accepts callbacks to be triggered when modifications occur. (such behaviour would be useful for updating namespace package __path__ attributes, for instance). However, for purely debugging purposes, it should be sufficient to monkeypatch sys.path with an object that write any changes through to the original path, while overriding the various mutations methods to report the source of the modification (via stack introspection). IIt's the same kind of technique you can use to investigate faults in *any* kind of container. (Versions based on UserDict and UserList might be interesting Python Cookbook recipes).
The fault was mine - I didn't understand your suggestion correctly, so I didn't realise that PEP 395 doesn't actually address it.
Anatoly, thanks for taking the time to explain that. The impression comes from the fact that many of the things you object to within Python are largely a result of limited availability of development resources, so even things that are at least arguably good ideas simply don't get investigated. The universe of good ideas is vast, the universe of bad ideas is even larger, but the space we have the capacity to explore is actually relatively tiny. Since there's such an enormous number of things that *could* be done, the answer to "why aren't they done?" is almost always going to "because people don't think they're important enough to do them instead of all the other things they're doing". Deciding how to spend our time on Python-related efforts is a matter of perceived priorities and potential payoffs and those are always going to vary substantially across individuals. Being more willing to accept that as a rationale for not doing things would go a long way towards reducing the negative reactions - I know mine arise not so much for your initial suggestions (which are often, although not always, quite reasonable ideas in a world where we had unlimited development resources), but from subsequently continuing to push them in the face "because we're simply not interested in doing that" and "the status quo may not be perfect, but it's good enough that it isn't worth the hassle of changing" responses. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Hello, I am a bit confused. Tests are best not located amongst code, but in a sub directory. I was strongly stated on #python to use unittest(2) or nose in order not to use the path hacks. so did stackoverflow also stated when I googled it : http://stackoverflow.com/questions/61151/where-do-the-python-unit-tests-go Okay unittest tries relative import by adding a dot in front of the name, but in the fallback, in the end, does not it uses the sys path hack ? (my eyes may be old, my brain damaged by alcohol, but it looks very much this way). It looks like hiding dust under the carpet, and stating that by tabooing sys.path hack use and locating it in very savant module, the problem gets solved. I am honestly, just very candid on this one, and pretty puzzled. sys path hack, looks to me a lot like coupling between classes, global varaibles, or gotos, and other beasts. It may be needed and yet powerful therefore great wisdom is needed to handle them carefully. PS (not sure I am 100% serious after this point) Why not create a module like __use_wisefully__ then ? people would be warned by being compelled to write : from __use_wisefully__ import sys.path ? Cheers, -- Jul
On Feb 20, 11:18 pm, anatoly techtonik <techto...@gmail.com> wrote:
tl;dr :(
You're _constantly_ bemoaning the "obvious" lack of clear communication paths in the Python community, and yet when you're pointed to an _explicit piece of documentation that answers your concerns_ you can't even be bothered to read it. It's pretty damn "obvious" that your only real issue with communication is when it isn't being spoon fed to you.
On Tue, Feb 21, 2012 at 1:37 PM, alex23 <wuwei23@gmail.com> wrote:
In Anatoly's defence (and as he clarified in a later message), PEP 395 really *didn't* answer his question, and he had made his way through quite a bit of it (and PEP 3155, which it references) before giving up on trying to figure out how it was relevant - I had simply misunderstood the original email. After I *did* understand it, I pointed out that investigating unexpected or undesirable modifications to mutable containers when the data changes aren't enough to pinpoint the culprit is actually one of the valid use cases for monkeypatching rather than a reason to change the language behaviour. (That said, there are other, more valid, arguments in favour of providing a notification mechanism for sys.path changes, mainly relating to namespace packages. That's a different discussion, though, and one more appropriate for import-sig). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (7)
-
alex23 -
anatoly techtonik -
julien tayon -
Nick Coghlan -
Simon Sapin -
Steven D'Aprano -
Terry Reedy