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
On Tue, Mar 20, 2012 at 00:41, Eric Snow <ericsnowcurrently@gmail.com>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.
On Mar 20, 2012 1:11 PM, "Benjamin Peterson" <benjamin@python.org> wrote:
Brett Cannon <brett@...> 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
Eric Snow <ericsnowcurrently@...> writes:
On Mar 20, 2012 1:11 PM, "Benjamin Peterson"
<benjamin@python.org> wrote:
Brett Cannon <brett <at> ...> 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.
On Wed, Mar 21, 2012 at 11:41 AM, Benjamin Peterson <benjamin@python.org> 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
On Tue, Mar 20, 2012 at 22:00, Benjamin Peterson <benjamin@python.org>wrote:
Nick Coghlan <ncoghlan@...> 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().
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
On Mon, Mar 19, 2012 at 10:41 PM, Eric Snow <ericsnowcurrently@gmail.com> 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
On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson <benjamin@python.org> wrote:
Eric Snow <ericsnowcurrently@...> 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
On Thu, Mar 22, 2012 at 7:22 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson <benjamin@python.org> wrote:
Eric Snow <ericsnowcurrently@...> 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
Eric Snow wrote:
On Thu, Mar 22, 2012 at 7:22 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Mar 22, 2012 at 4:37 AM, Benjamin Peterson <benjamin@python.org> wrote:
Eric Snow <ericsnowcurrently@...> 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
On Mon, Mar 19, 2012 at 10:41 PM, Eric Snow <ericsnowcurrently@gmail.com> 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
On Tue, Apr 24, 2012 at 12:42 AM, Eric Snow <ericsnowcurrently@gmail.com> 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
participants (7)
-
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Brett Cannon -
Eric Snow -
Mark Shannon -
Nick Coghlan