Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Bugs

[issue14673] add sys.implementation

 

 

Python bugs RSS feed   Index | Next | Previous | View Threaded


report at bugs

Apr 25, 2012, 10:16 PM

Post #1 of 12 (158 views)
Permalink
[issue14673] add sys.implementation

New submission from Eric Snow <ericsnowcurrently [at] gmail>:

(see thread at http://mail.python.org/pipermail/python-ideas/2012-April/014878.html)

This is a patch to add sys.implementation to Python (with doc addition). The main motivation is to have an explicit place to look for the name and version of the implementation for generating the import cache tag (a la PEP 3147).

----------
components: Interpreter Core
files: sys_implementation.diff
keywords: patch
messages: 159357
nosy: eric.snow
priority: normal
severity: normal
status: open
title: add sys.implementation
type: behavior
versions: Python 3.3
Added file: http://bugs.python.org/file25369/sys_implementation.diff

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 6:06 AM

Post #2 of 12 (155 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

If it can contain a variable number of fields, I think it should be a dict rather than a tuple.

----------
nosy: +ncoghlan, pitrou

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 7:48 AM

Post #3 of 12 (150 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA [at] GMail>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 8:12 AM

Post #4 of 12 (151 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Éric Araujo <merwok [at] netwok> added the comment:

*version* is a version tuple, in the format of :data:`sys.version_info`,
which represents the version of the Python implementation, **not** the
version of the Python specification it implements.

If that version number is specific to each VM, then I’m not sure we should mandate a specific format.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 9:07 AM

Post #5 of 12 (152 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Eric Snow <ericsnowcurrently [at] gmail> added the comment:

@antoine - I wondered about that. In the end I got something up to start with.

The list of fields in sys.implementation may change over time, unlike sys.version_info, et al. However, during interpreter execution, I would expect that neither that list nor the contents would change. The variability would only be between implementations and between versions of those implementations.

A dict would imply to me that it might vary during interpreter execution. An immutable type makes it clear to me that it won't be changing. I'm fine with a dict, though, if you think that's better. Perhaps a dictproxy?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 9:17 AM

Post #6 of 12 (151 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Eric Snow <ericsnowcurrently [at] gmail> added the comment:

@Éric - that's a good point. I considered it for a little bit, but went with the quick and easy think to get it rolling.

There is a real benefit to mandating an API sys.implementation.version. importlib would use that version to calculate the tag to use for cached modules. Without a specified/uniform data structure, that job is trickier.

Having an explicit sys.implementation.cache_tag field would solve that, and the importlib code would check for that field first. However, I didn't want to start off with that as a "required" field, considering that only CPython would take advantage of module caches (as far as I know).

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 9:19 AM

Post #7 of 12 (152 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Eric Snow <ericsnowcurrently [at] gmail> added the comment:

I'm going to write a PEP for this, after all. I want to make sure that it's easy to access, in one place, these points that are coming up and their resolutions.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 12:11 PM

Post #8 of 12 (151 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Martin v. Löwis <martin [at] v> added the comment:

If the main motivation for this is that importlib can use it, I fail to see the point to make it cross-implementation. Other implementations of Python may not use byte code files at all, or use different byte code syntaxes, or not use the marshal module to load byte code. So the part of importlib that deals with cached .pyc files will be specific to CPython, anyway - why make it a cross-implementation attribute?

----------
nosy: +loewis

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 2:08 PM

Post #9 of 12 (149 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Eric Snow <ericsnowcurrently [at] gmail> added the comment:

Thanks for bringing this up, Martin.

sys.implementation is about having an implementation-specific location (hence sys) to consolidate explicit values concerning the implementation. It's partly about clarifying the run-time distinction between Python-the-language and Python-the-implementation.

'name' and 'version' are the initial fields in sys.implementation because they are the most obvious choices, and a good starting point. If sys.implementation were available now we'd use it in importlib. That's what has motivated me to pursue this.

You are correct that we can hard-code "cpython" in the bootstrap code to generate the cache tag. And perhaps that would be a better use of time. We can't just use platform.python_implementation(), however, since the frozen importlib can only use builtin modules.

I expect you're right that some of the importlib code (particularly w.r.t. cached modules) is CPython-specific. However, I'm sure Brett has tried to minimize that subset of the module. Maybe he knows if the other implementations have plans for using importlib or how it affects them. If not, I'll ask around.

Regardless, importlib is not the only motivator here. Right now platform.python_implementation() has to guess the implementation name. Having the different implementations specify the name explicitly in the sys module would be an improvement without a lot of work. Nick Coghlan has indicated that it would be useful for the test suite.

Ultimately, sys.implementation would become the source for information about a specific Python implementation. Others could expound the point better, but as time goes by this will be more important. This current effort would get the ball rolling. Consequent to the concerns so far, I'll try to get a PEP out in the next couple days.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 26, 2012, 4:52 PM

Post #10 of 12 (151 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Brett Cannon <brett [at] python> added the comment:

So I'm w/ Antoine that a dict would be better so that the other VMs can add whatever they want into that object (e.g. Jython could specify what JVM they are running against) without causing confusion as to what some index means to each VM. The mutability of it is not important IMO.

As for the other implementations using importlib, they all plan to with (hopefully) no direct modification, but whether they support bytecode I don't know (I think Jython has talked about it, but who knows).

And pertaining to whether this is useful outside of importlib, I suspect it is. We already have 'jython' as an "OS" type to work around some differences. Adding this attribute would more clearly delineate when another VM is being used that might require working around some difference without overloading os.name (e.g. PyPy implementing something differently in their 1.7 release of Python 2.7 but is subsequently fixed in their 1.8 release).

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 27, 2012, 12:13 AM

Post #11 of 12 (149 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Martin v. Löwis <martin [at] v> added the comment:

When I added sys.subversion, people requested that it shall contain the CPython string. When sys._mercurial was introduced, it copied that. So there are plenty of ways already to figure out that it is CPython which you are using.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 27, 2012, 12:31 AM

Post #12 of 12 (150 views)
Permalink
[issue14673] add sys.implementation [In reply to]

Eric Snow <ericsnowcurrently [at] gmail> added the comment:

An updated patch using a dict. (FYI, I have the PEP up on python-ideas.)

----------
Added file: http://bugs.python.org/file25378/sys_implementation_2.diff

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue14673>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Python bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.