v+python at g.nevcal.com
Fri Apr 27 22:11:03 CEST 2012
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.
>> 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.
> 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.
> 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
* language implementation
* implementation dependent modules
* implementation independent modules
* implementation dependent optimizations of implementation independent
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?
> (*) 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
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev