On 4/27/2012 11:49 AM, R. David Murray wrote:
On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman<v+pyt...@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<ba...@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
_______________________________________________
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/archive%40mail-archive.com
