Mailman 3 sys.implementation - Python-ideas

sys.implementation

Eric Snow

20 Mar 2012 20 Mar '12

4:41 a.m.

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)? -eric [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

Show replies by date

Brett Cannon

20 Mar 20 Mar

3:01 p.m.

On Tue, Mar 20, 2012 at 00:41, Eric Snow wrote:

...

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)?

I was wondering that myself when looking at imp.source_to_cache() at PyCon. I would still like to see it happen.

Benjamin Peterson

7:09 p.m.

Brett Cannon writes:

...

I was wondering that myself when looking at imp.source_to_cache() at PyCon.

What's implementation specific about that?

Eric Snow

21 Mar 21 Mar

1:29 a.m.

On Mar 20, 2012 1:11 PM, "Benjamin Peterson" wrote:

...

Brett Cannon writes:

...
I was wondering that myself when looking at imp.source_to_cache() at

PyCon.

...

What's implementation specific about that?

File suffixes on the .pyc files there include implementation information. To get that info in Python you can use the platform module (not an option for bootstrapping importlib) or guess (essentially what the platform module does). -eric

...

_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Benjamin Peterson

1:41 a.m.

Eric Snow writes:

...

On Mar 20, 2012 1:11 PM, "Benjamin Peterson"

wrote:

...

...
Brett Cannon writes:

...
I was wondering that myself when looking at imp.source_to_cache() at PyCon.

What's implementation specific about that?

File suffixes on the .pyc files there include implementation information. To get that info in Python you can use the platform module (not an option for bootstrapping importlib) or guess (essentially what the platform module does).

I think source_to_cache() is a bad example, though, because the operation would basically identical in every Python implementation. The tag will just change. It even changes in every CPython version.

Nick Coghlan

1:50 a.m.

On Wed, Mar 21, 2012 at 11:41 AM, Benjamin Peterson wrote:

...

I think source_to_cache() is a bad example, though, because the operation would basically identical in every Python implementation. The tag will just change. It even changes in every CPython version.

I believe that was Brett's point. Currently other implementations have to replace imp.get_tag() to change the magic string, whereas that kind of info could easily be consolidated into a "sys.implementation" struct that standardised a few things so that impls just needed to populate the struct correctly rather than making scattered changes to a variety of different modules. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Benjamin Peterson

2 a.m.

Nick Coghlan writes:

...

I believe that was Brett's point.

Ah, so you're not suggesting moving imp.source_to_cache() to some sys.implementation module. Great.

Brett Cannon

2:19 p.m.

On Tue, Mar 20, 2012 at 22:00, Benjamin Peterson wrote:

...

Nick Coghlan writes:

...
I believe that was Brett's point.

Ah, so you're not suggesting moving imp.source_to_cache() to some sys.implementation module. Great.

Just FYI, everyone guessed right about what I was thinking and Benjamin is right about not suggesting moving imp.source_to_cache() but simply adding sys.implementation so that imp.source_to_cache() can use that instead of imp.get_tag().

Barry Warsaw

23 Mar 23 Mar

12:45 a.m.

On Mar 21, 2012, at 10:19 AM, Brett Cannon wrote:

...

Just FYI, everyone guessed right about what I was thinking and Benjamin is right about not suggesting moving imp.source_to_cache() but simply adding sys.implementation so that imp.source_to_cache() can use that instead of imp.get_tag().

Yeah, that would be kind of nice. imp.get_tag() was just a convenient place to stash that information at the time. -Barry

Eric Snow

21 Mar 21 Mar

4:02 p.m.

On Mon, Mar 19, 2012 at 10:41 PM, Eric Snow wrote:

...

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)?

FYI, there are several reasons why sys.implementation is a good idea when some of the same info is already in the platform module: * The implementation in the platform module is essentially just guessing [1]. With sys.implementation the various implementations would explicitly set the values in their own version of the sys module. * The platform module is part of the stdlib, which ideally would minimize implementation details such as would be in sys.implementation. * Any module used in the importlib bootstrap must be built-in or frozen, neither of which apply to the platform module. This is the point that led to me finding the previous proposal. I expect that any overlap between sys.implementation and the platform module would simply defer to sys.implementation (with the same interface in platform wrapping it). I'd like to move this forward, so any objections or feedback at this point would be helpful. If Christian is interested it taking this I'd gladly step back. Regardless, feedback from the different Python implementations will be especially important here. Preferably, sys.implementation (the object bundling the various info) would be available on all implementations sooner rather than later... -eric [1] http://hg.python.org/cpython/file/default/Lib/platform.py#l1247

...

-eric

[1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

Benjamin Peterson

6:37 p.m.

Eric Snow writes:

...

I'd like to move this forward, so any objections or feedback at this point would be helpful.

I would like to see a concrete proposal of what would get put in there. Regards, Benjamin

Nick Coghlan

23 Mar 23 Mar

1:22 a.m.

On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson wrote:

...

Eric Snow writes:

...
I'd like to move this forward, so any objections or feedback at this point would be helpful.

I would like to see a concrete proposal of what would get put in there.

+1 A possible starting list: - impl name (with a view to further standardising the way we check for impl specific tests in the regression test suite) - impl version (official place to store the implementation version, potentially independent of the language version as it already is in PyPy) - cache tag (replacement for imp.get_tag()) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Eric Snow

22 Apr 22 Apr

8:59 a.m.

On Thu, Mar 22, 2012 at 7:22 PM, Nick Coghlan wrote:

...

On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson wrote:

...
Eric Snow writes:

...
I'd like to move this forward, so any objections or feedback at this point would be helpful.

I would like to see a concrete proposal of what would get put in there.

+1

A possible starting list:

- impl name (with a view to further standardising the way we check for impl specific tests in the regression test suite) - impl version (official place to store the implementation version, potentially independent of the language version as it already is in PyPy) - cache tag (replacement for imp.get_tag())

This is a great start, Nick. Having a solid sys.implementation would (for one) help with the import machinery, as your list suggests. I'm planning on reviewing that old thread over the next few days. [1] In the meantime, any additional thoughts by anyone on what would go into sys.implementation would be very helpful. -eric p.s. is python-ideas the right place for this discussion? Also, ultimately this topic should go into a PEP, right? [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

Mark Shannon

9:57 a.m.

Eric Snow wrote:

...

On Thu, Mar 22, 2012 at 7:22 PM, Nick Coghlan wrote:

...
On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson wrote:

...
Eric Snow writes:

...
I'd like to move this forward, so any objections or feedback at this point would be helpful. I would like to see a concrete proposal of what would get put in there. +1

A possible starting list:

- impl name (with a view to further standardising the way we check for impl specific tests in the regression test suite) - impl version (official place to store the implementation version, potentially independent of the language version as it already is in PyPy) - cache tag (replacement for imp.get_tag())

One more: GC (reference-counting, copying, mark-and-sweep, generational, etc.)

...

This is a great start, Nick. Having a solid sys.implementation would (for one) help with the import machinery, as your list suggests. I'm planning on reviewing that old thread over the next few days. [1] In the meantime, any additional thoughts by anyone on what would go into sys.implementation would be very helpful.

-eric

p.s. is python-ideas the right place for this discussion? Also, ultimately this topic should go into a PEP, right?

[1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas

Antoine Pitrou

11:30 a.m.

On Sun, 22 Apr 2012 10:57:13 +0100 Mark Shannon wrote:

...

One more:

GC (reference-counting, copying, mark-and-sweep, generational, etc.)

I think this would sound more natural in the gc module itself. Regards Antoine.

Eric Snow

24 Apr 24 Apr

6:42 a.m.

On Mon, Mar 19, 2012 at 10:41 PM, Eric Snow wrote:

...

In October 2009 there was a short flurry of interest in adding "sys.implementation" as an object to encapsulate some implementation-specific information [1]. Does anyone recollect where this proposal went? Would anyone object to reviving it (or a variant)?

The premise is that sys.implementation would be a "namedtuple" (like sys.version_info). It would contain (as much as is practical) the information that is specific to a particular implementation of Python. "Required" attributes of sys.implementation would be those that the standard library makes use of. For instance, importlib would make use of sys.implementation.name (or sys.implementation.cache_tag) if there were one. The thread from 2009 covered a lot of this ground already. [1] Here are the "required" attributes of sys.implementation that I advocate: * name (mixed case; sys.implementation.name.lower() used as an identifier) * version (of the implementation, not of the targeted language version; structured like sys.version_info?) Here are other variables that _could_ go in sys.implementation: * cache_tag (e.g. 'cpython33' for CPython 3.3) * repository * repository_revision * build_toolchain * url (or website) * site_prefix * runtime Let's start with a minimum set of expected attributes, which would have an immediate purpose in the stdlib. However, let's not disallow implementations from adding whatever other attributes are meaningful for them. -eric [1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html

Eric Snow

26 Apr 26 Apr

5:34 a.m.

On Tue, Apr 24, 2012 at 12:42 AM, Eric Snow wrote:

...

The premise is that sys.implementation would be a "namedtuple" (like sys.version_info). It would contain (as much as is practical) the information that is specific to a particular implementation of Python. "Required" attributes of sys.implementation would be those that the standard library makes use of. For instance, importlib would make use of sys.implementation.name (or sys.implementation.cache_tag) if there were one. The thread from 2009 covered a lot of this ground already. [1]

Here are the "required" attributes of sys.implementation that I advocate:

* name (mixed case; sys.implementation.name.lower() used as an identifier) * version (of the implementation, not of the targeted language version; structured like sys.version_info?)

Here are other variables that _could_ go in sys.implementation:

* cache_tag (e.g. 'cpython33' for CPython 3.3) * repository * repository_revision * build_toolchain * url (or website) * site_prefix * runtime

Let's start with a minimum set of expected attributes, which would have an immediate purpose in the stdlib. However, let's not disallow implementations from adding whatever other attributes are meaningful for them.

FYI, I've created a tracker ticket with a patch and moved this over to python-dev. -eric [1] http://bugs.python.org/issue14673

4381

Age (days ago)

4418

Last active (days ago)

List overview

Download

16 comments

7 participants

participants (7)

Antoine Pitrou
Barry Warsaw
Benjamin Peterson
Brett Cannon
Eric Snow
Mark Shannon
Nick Coghlan

sys.implementation

tags

participants (7)