[Python-Dev] sys.implementation

[Glenn Linderman]

On 4/27/2012 11:49 AM, R. David Murray wrote:
> On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman<v+python at g.nevcal.com>  wrote:
>> On 4/27/2012 12:34 AM, Eric Snow wrote:
>>> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw<barry at python.org>   wrote:
>>>> It's somewhat of a corner case, but I think a PEP couldn't hurt.  The
>>>> rationale section would be useful, at least.
>>>     http://mail.python.org/pipermail/python-ideas/2012-April/014954.html
>> My conclusion is that sys.implementation clearly should not be part of
>> the stdlib, but rather be part of the language implementation.  Whether
>> it then fits with the rest of what is in sys, or not, I am not qualified
>> to say.  If not, perhaps a new module name is warranted... perhaps
>> "implementation" at the top level of the namespace.
> IMO, there are two different things here that you are conflating(*): the
> *implementation* of the stdlib, and the stdlib *API*.  sys.implementation
> would be a part of the API that any conforming implementation of
> python+stdlib would be required to implement.

Hmm.  OK.

> We also have a goal of making as much of the *implementation* of the
> stdlib usable by any python implementation as possible, but as you say
> that is a work in progress.

OK.
> There are, by the way, many things documented in the "library"
> documentation that are in fact provided by the language implementation
> itself.  All of the fundamental types, for example.

I was aware of this last, but wasn't thinking about it during these 
musings... although the thoughts of documentation also crossed my mind, 
I didn't mention them, figuring it could come up later.

So "library" documentation already covers all three categories of stuff 
that I mentioned, plus one more (restated here for clarity, with better 
wording):

* language implementation
* implementation dependent modules
* implementation independent modules
* implementation dependent optimizations of implementation independent 
modules

 From the perspective of a user of a single implementation of the 
language + library, it really doesn't matter how the documentation is 
organized, or whether the documentation notes which of the above 4 
categories an item falls in.

 From the perspective of a user of multiple implementations, or 
perspective of a developer of an implementation other than CPython, 
knowledge of the category could be useful for both portability and 
performance planning. Organizing the documentation in some manner to be 
aware of such categories may help other implementations provide 
appropriate addenda.  The closer any of them get to tracking the Py3 
trunk in real time, the more so.

Here's a ponderable: In the long term, should the documentation be 
unified for multiple implementations?  Or should it be split into 4 
pieces, so that alternate implementations could swap in their own 
sections for implementation dependent items?

>
> --David
>
> (*) the Oracle lawyers sometimes seem to be trying to get
> the judge and jury to make the same mistake.
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120427/458615ac/attachment.html>