On 4/27/2012 11:49 AM, R. David Murray wrote:
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman <v+python@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@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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com