The sys module is perhaps the most core module to Python and one of the oldest. It has grown relatively organically over the years and its contents could use a little clean up. Similar proposals have come up before but without enough interest to keep them rolling. My motivation for cleaning up sys is a combination of things: * I'm working on a proposal that may include adding a sub-namespace to sys (similar to what we did with sys.implementation) and removing-ish some attributes. * The namespace is large enough that scanning quickly through it, particularly alphabetically a la help() or the docs, isn't very helpful. * Other outstanding proposals like PEP 432 may restructure underlying APIs and having the sys module mirror the resulting APIs would help reduce the cognitive overhead in this space. * It would be nice to support descriptors on the module. * The current structure does not communicate the role of the module very well. Changing the sys module should be done carefully and as little as possible. The status quo has something like a +10 modifier when it comes to sys changes. The current API is pretty stable and undoubtedly a lot of code relies on it. This proposal reflects an understanding of those considerations and addresses them in an entirely backward compatible way (including impact on alternate Python implementations). At the moment I'm not proposing any big changes to sys nor any changes at all to its API. That can come later. <wink> Instead, this proposal is about setting the stage for better flexibility in making changes to sys when the need arises. Consequently I propose just 2.5000000000000001 relatively simple changes: 1. the existing sys module be renamed to _sys (and the stdlib be changed accordingly where appropriate); 2. a pure Python sys module be added to the stdlib that wraps the existing API; 2.5. the new module should use the replace-itself-in-sys.modules technique to provide a module subclass that supports descriptors. Thoughts? -eric
Le 13/03/2014 08:43, Eric Snow a écrit :
At the moment I'm not proposing any big changes to sys nor any changes at all to its API. That can come later. <wink> Instead, this proposal is about setting the stage for better flexibility in making changes to sys when the need arises. Consequently I propose just 2.5000000000000001 relatively simple changes:
1. the existing sys module be renamed to _sys (and the stdlib be changed accordingly where appropriate); 2. a pure Python sys module be added to the stdlib that wraps the existing API;
I'm not sure what that brings until the need arises. However, making it a pure Python sys module means it won't be immediately available at startup like sys currently is (i.e. it's a built-in module). I don't know if there are any scenarios where it may matter.
2.5. the new module should use the replace-itself-in-sys.modules technique to provide a module subclass that supports descriptors.
I don't think any module should be specific in that regard. Special cases generally make the language more complicated to learn. Also, you haven't explained the rationale. Regards Antoine.
13.03.14 11:17, Antoine Pitrou написав(ла):
1. the existing sys module be renamed to _sys (and the stdlib be changed accordingly where appropriate); 2. a pure Python sys module be added to the stdlib that wraps the existing API;
I'm not sure what that brings until the need arises. However, making it a pure Python sys module means it won't be immediately available at startup like sys currently is (i.e. it's a built-in module). I don't know if there are any scenarios where it may matter.
Many sys attributes (argv, displayhook, excepthook, modules, path, path_hooks, path_importer_cache, ps1, ps2, stderr, stdin, stdout, tracebacklimit) are used implicit in builtins and in interpreter core. Even import system doesn't work without the sys module. So it should be initialized very early and finalized very late.
On Mar 13, 2014, at 02:04 PM, Serhiy Storchaka wrote:
Many sys attributes (argv, displayhook, excepthook, modules, path, path_hooks, path_importer_cache, ps1, ps2, stderr, stdin, stdout, tracebacklimit) are used implicit in builtins and in interpreter core. Even import system doesn't work without the sys module. So it should be initialized very early and finalized very late.
If the C API PySys_* functions were updated to use _sys instead, hopefully most stuff in the core would still work, right? -Barry
13.03.14 22:03, Barry Warsaw написав(ла):
On Mar 13, 2014, at 02:04 PM, Serhiy Storchaka wrote:
Many sys attributes (argv, displayhook, excepthook, modules, path, path_hooks, path_importer_cache, ps1, ps2, stderr, stdin, stdout, tracebacklimit) are used implicit in builtins and in interpreter core. Even import system doesn't work without the sys module. So it should be initialized very early and finalized very late.
If the C API PySys_* functions were updated to use _sys instead, hopefully most stuff in the core would still work, right?
Perhaps. If sys attributes will be writable properties which updates _sys.
On Mar 13, 2014 3:18 AM, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
Le 13/03/2014 08:43, Eric Snow a écrit :
1. the existing sys module be renamed to _sys (and the stdlib be changed accordingly where appropriate); 2. a pure Python sys module be added to the stdlib that wraps the
existing API;
I'm not sure what that brings until the need arises.
It means no one needs to change 'import sys' to 'import _sys' in their code.
However, making it a pure Python sys module means it won't be immediately available at startup like sys currently is (i.e. it's a built-in module). I don't know if there are any scenarios where it may matter.
As I noted, we would need to update some spots in the stdlib to import _sys rather than sys.
2.5. the new module should use the replace-itself-in-sys.modules technique to provide a module subclass that supports descriptors.
I don't think any module should be specific in that regard. Special cases
generally make the language more complicated to learn. Also, you haven't explained the rationale. As others have noted, there isn't much point to making any of these changes until we have some need that they satisfy. I anticipate having that need in the mid-term and wanted to see if the proposed approach is palatable. -eric
On 13 March 2014 17:43, Eric Snow <ericsnowcurrently@gmail.com> wrote:
At the moment I'm not proposing any big changes to sys nor any changes at all to its API. That can come later. <wink> Instead, this proposal is about setting the stage for better flexibility in making changes to sys when the need arises. Consequently I propose just 2.5000000000000001 relatively simple changes:
1. the existing sys module be renamed to _sys (and the stdlib be changed accordingly where appropriate); 2. a pure Python sys module be added to the stdlib that wraps the existing API;
As Antoine suggests, we shouldn't do that until we have a concrete use case (although I'm generally approving of the idea, there are also benefits to having it as entirely a builtin module). It may seem counterintuitive, but it's actually easier to sell non-invasive prep work after already making the case for the subsequent change :)
2.5. the new module should use the replace-itself-in-sys.modules technique to provide a module subclass that supports descriptors.
I'm generally against doing that without a clear rationale for why defining a new object to use isn't more appropriate (we've survived attribute -> function transitions before, like the one to using the thread safe sys.exc_info()). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (5)
-
Antoine Pitrou -
Barry Warsaw -
Eric Snow -
Nick Coghlan -
Serhiy Storchaka