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

Mailing List Archive: Python: Dev

sys.implementation

 

 

First page Previous page 1 2 3 Next page Last page  View All Python dev RSS feed   Index | Next | Previous | View Threaded


ericsnowcurrently at gmail

Apr 25, 2012, 10:31 PM

Post #1 of 55 (452 views)
Permalink
sys.implementation

The proposal of adding sys.implementation has come up a couple times
over the last few years. [1][2] While the reaction has been
overwhelmingly positive, nothing has come of it. I've created a
tracker issue and a patch:

http://bugs.python.org/issue14673

The patch adds a struct sequence that holds ("name" => "CPython",
"version" => sys.version_info). If later needs dictate more fields,
we can cross that bridge then.

Are there any objections? Considering the positive reaction and the
scope of the addition, does this need a PEP?

-eric

[1] http://mail.python.org/pipermail/python-dev/2009-October/092893.html
[2] http://mail.python.org/pipermail/python-ideas/2012-April/014878.html
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

Apr 26, 2012, 7:31 AM

Post #2 of 55 (440 views)
Permalink
Re: sys.implementation [In reply to]

On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:

>The proposal of adding sys.implementation has come up a couple times
>over the last few years. [1][2] While the reaction has been
>overwhelmingly positive, nothing has come of it. I've created a
>tracker issue and a patch:
>
> http://bugs.python.org/issue14673
>
>The patch adds a struct sequence that holds ("name" => "CPython",
>"version" => sys.version_info). If later needs dictate more fields,
>we can cross that bridge then.
>
>Are there any objections? Considering the positive reaction and the
>scope of the addition, does this need a PEP?

It's somewhat of a corner case, but I think a PEP couldn't hurt. The
rationale section would be useful, at least.

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

Apr 26, 2012, 9:21 AM

Post #3 of 55 (442 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <barry [at] python> wrote:
> On Apr 25, 2012, at 11:31 PM, Eric Snow wrote:
>>Are there any objections? †Considering the positive reaction and the
>>scope of the addition, does this need a PEP?
>
> It's somewhat of a corner case, but I think a PEP couldn't hurt. †The
> rationale section would be useful, at least.
>
> -Barry

Yeah, I'm finding little bits and pieces that would be nice to have
recorded in one place. I'll get something up in the next couple days.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


larry at hastings

Apr 26, 2012, 8:29 PM

Post #4 of 55 (436 views)
Permalink
Re: sys.implementation [In reply to]

On 04/25/2012 10:31 PM, Eric Snow wrote:
> The patch adds a struct sequence that holds ("name" => "CPython",
> "version" => sys.version_info). If later needs dictate more fields,
> we can cross that bridge then.

My one bit of bike-shedding: I don't think it's desirable that this
object be iterable. Therefore I suggest you don't use struct sequence.


//arry/


ericsnowcurrently at gmail

Apr 26, 2012, 11:05 PM

Post #5 of 55 (432 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, Apr 26, 2012 at 9:29 PM, Larry Hastings <larry [at] hastings> wrote:
> My one bit of bike-shedding: I don't think it's desirable that this object
> be iterable.† Therefore I suggest you don't use struct sequence.

Good point. Noted.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

Apr 27, 2012, 12:34 AM

Post #6 of 55 (435 views)
Permalink
Re: sys.implementation [In reply to]

On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw <barry [at] python> 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

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


v+python at g

Apr 27, 2012, 10:40 AM

Post #7 of 55 (428 views)
Permalink
Re: sys.implementation [In reply to]

On 4/27/2012 12:34 AM, Eric Snow wrote:
> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw<barry [at] python> 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

The idea of having separate versions for CPython and stdlib has been
raised recently, although I believe it has been mostly been deferred or
discarded. Should that be resurrected, sys.implementation may be a good
repository for the additional version info defining the stdlib version.

However, this PEP raises the following question in my mind: is the sys
module part of the stdlib? Before reaching a hasty conclusion, consider
the following points:

1) with this proposal, the contents of sys.implementation will vary
between implementations. If stdlib is to be shared among
implementations, then it seems sys.implementation should not be part of
the stdlib, but rather part of the implementation. Is sys considered
part of the implementation or part of the stdlib? I've always perceived
it as part of the stdlib, because of the way it is documented.

2) importlib wants to be part of the stdlib, and thus available to other
implementations, but it must be built-in or frozen. The goal with
importlib is a common implementation in Python, that can be used by all
implementations. I am not clear on whether the accelerated C code is
part of the stdlib, or part of an implementation optimization, nor how
the structuring of such things is arranged to separate stdlib from
implementation (if it is; if it isn't, should it be?)

3) can anything that must be built-in or frozen be part of the stdlib? I
don't see why not, if it is common to all implementations, even if it
depends on data it obtains from the implementation via some mechanism
such as the proposed sys.implementation. However, if it is not common, I
don't know how it can be standard/stdlib... which raises issues in my
understanding of the various modules available as Python with C
accelerators, and I know there are pure C modules that are part of the
stdlib. So I think this idea of making the stdlib more sharable between
implementations is still a work-in-progress, even a design-in-progress,
but maybe part of the solution is to separate, or at least delineate,
things that can be common, from things that cannot be common to all
implementations.

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.

So my thoughts are:

Things that are part of the stdlib should be available in Python source
to be shared across implementations. Things that are not available in
Python source cannot be shared across implementations, and therefore
should not be part of the stdlib, but rather part of an
implementation-specific library, or part of the language specification.

Or maybe stdlib should be an umbrella term, with the following subsets:
common (Python implementation available, and not dependent on
implementation-specific details except in very standardized ways),
implementation-specific (provided by each implementation, either in
implementation-specific Python, or some other implementation language),
accelerators (a faster version of a common module, provided by an
implementation when necessary for performance).

In this situation, sys.implementation, as proposed, should be
implementation-specific.


rdmurray at bitdance

Apr 27, 2012, 11:49 AM

Post #8 of 55 (422 views)
Permalink
Re: sys.implementation [In reply to]

On Fri, 27 Apr 2012 10:40:43 -0700, Glenn Linderman <v+python [at] g> 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> 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.

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.

--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
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


v+python at g

Apr 27, 2012, 1:11 PM

Post #9 of 55 (418 views)
Permalink
Re: sys.implementation [In reply to]

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> 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> 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
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/v%2Bpython%40g.nevcal.com
>
>


ncoghlan at gmail

Apr 28, 2012, 12:58 AM

Post #10 of 55 (426 views)
Permalink
Re: sys.implementation [In reply to]

On Sat, Apr 28, 2012 at 6:11 AM, Glenn Linderman <v+python [at] g> wrote:
> 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?

Probably not, because the boundary between language, standard library
and implementation *is* blurry. The blurriness in the descriptions
reflects the blurriness in reality.

Anything that doesn't have dedicated syntax is, in a formal sense,
part of the standard library rather than the core language definition.
That includes the GC API, the weakref API, the sys module, the
operator module, the builtins module, the types module, etc. The
language specification itself just states that there *is* a builtin
namespace and you *can* do imports. It is then up to the standard
library specification to describe the *contents* of the builtin
namespace, as well as state what other modules and packages can be
imported by default.

However, the various parts of the standard library differ can wildly
in how *closely coupled* they are to a particular implementation.

Some, such as builtins, gc, operator, weakref, types and sys are
*very* tightly coupled with a specific implementation and always will
be. If someone is writing a new implementation of Python, they're
almost certainly going to have to write new version of these modules
from scratch that interoperate correctly with their code generator and
evaluation loop.

Historically, the import machinery was similarly coupled to a specific
implementation. The goal of bootstrapping importlib as the main import
implementation is to change that so that most of the import machinery
is decoupled from the implementation, with the bare minimum remaining
as implementation specific code (specifically, the code needed to
carry out the bootstrapping process, such as supporting frozen and
builtin modules).

Other modules may differ in performance characteristics between
implementations, particular for older C modules in CPython which don't
have a pure Python counterpart.

So, yes, I agree the four categories you list are helpful in
*thinking* about the questions involved, but, no, I don't think it's a
good principle for organising the documentation (precisely because the
categories are related to implementation details that shouldn't matter
all that much to end users).

Cheers,
Nick.

--
Nick Coghlan†† |†† ncoghlan [at] gmail†† |†† Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 8, 2012, 6:14 PM

Post #11 of 55 (365 views)
Permalink
Re: sys.implementation [In reply to]

Hi Eric,

Great job on the latest PEP 421. I really like it. A few additional
comments/questions.

* sys.implementation.version

This is defined as the version of the implementation, while
sys.version_info is the version of the language. The semantics of
sys.version_info have been sufficiently squishy in the past, as the XXX
implies. This PEP shouldn't try to untangle that, so I think it be better
to represent both values explicitly in sys.implementation.

* Adding new required variables. I'd claim that it's not unduly heavyweight
to require a new PEP to add required variables to sys.implementation. That
hypothetical PEP will have to include things like rationale, impact on
other implementations, etc. That seems like enough to warrant a new PEP,
even if it's relatively succinct.

I'd also make it clear that adding new variables to
sys.implementation.metadata explicitly does *not* require a PEP.

* In Example Metadata Value:

"If they later have meaningful uses cases, they can be added by following
the process described in Adding New Required Attributes."

I'd rephrase this to "If these or any other variables are deemed to have
meaningful use cases across all implementations, they can be moved or added
to sys.implementation directly, following the process described in Adding
New Required Attributes."

* I mildly prefer sys.implementation.name to be lower cased. My intuition is
that to be safe, most comparisons of the value will coerce to lower case,
which is easy enough in Python, but perhaps a bit more of a pain in C. I
don't feel really strongly about this though. (A counter argument is that
the value might be printed, so a case-sensitive version would be better.)

* Since I'm advocating to be explicit about the language version and the
implementation version, .hexversion is probably also useful for both.

* I've said before that I think the keys in sys.implementation should be
locked down (i.e. not writable). I think sys.implementation.metadata
should be the same type.

Cheers,
-Barry
Attachments: signature.asc (0.82 KB)


ericsnowcurrently at gmail

May 8, 2012, 8:03 PM

Post #12 of 55 (362 views)
Permalink
Re: sys.implementation [In reply to]

On Tue, May 8, 2012 at 7:14 PM, Barry Warsaw <barry [at] python> wrote:
> Hi Eric,
>
> Great job on the latest PEP 421. †I really like it.

Encouragement appreciated. :)

> †A few additional
> comments/questions.
>
> †* sys.implementation.version
>
> † This is defined as the version of the implementation, while
> † sys.version_info is the version of the language. †The semantics of
> † sys.version_info have been sufficiently squishy in the past, as the XXX
> † implies. †This PEP shouldn't try to untangle that, so I think it be better
> † to represent both values explicitly in sys.implementation.

Definitely tangled. So, sys.implementation.version and
sys.implementation.lang_version? Also, my inclination is to not have
a sys.version equivalent in sys.implementation for now, in the
interest of keeping things as bare-bones as possible to start.

> †* Adding new required variables. †I'd claim that it's not unduly heavyweight
> † to require a new PEP to add required variables to sys.implementation. †That
> † hypothetical PEP will have to include things like rationale, impact on
> † other implementations, etc. †That seems like enough to warrant a new PEP,
> † even if it's relatively succinct.

Agreed. I'll go with that for the PEP.

> † I'd also make it clear that adding new variables to
> † sys.implementation.metadata explicitly does *not* require a PEP.

Good point.

> †* In Example Metadata Value:
>
> † "If they later have meaningful uses cases, they can be added by following
> † the process described in Adding New Required Attributes."
>
> † I'd rephrase this to "If these or any other variables are deemed to have
> † meaningful use cases across all implementations, they can be moved or added
> † to sys.implementation directly, following the process described in Adding
> † New Required Attributes."

That's an important distinction. I'll clean it up.

> †* I mildly prefer sys.implementation.name to be lower cased. †My intuition is
> † that to be safe, most comparisons of the value will coerce to lower case,
> † which is easy enough in Python, but perhaps a bit more of a pain in C. †I
> † don't feel really strongly about this though. †(A counter argument is that
> † the value might be printed, so a case-sensitive version would be better.)

I'm not sure it makes a lot of difference. Since cache_tag will be
provided by the implementation, I don't have any strong use-cases that
would constrain the name itself. Still, my preference is for lower
case as well. I'll mull this one over.

> †* Since I'm advocating to be explicit about the language version and the
> † implementation version, .hexversion is probably also useful for both.

That's fine with me, and pretty trivial to do.

> †* I've said before that I think the keys in sys.implementation should be
> † locked down (i.e. not writable).

I've been on and off about this. It's certainly not too hard to do,
it makes sense, and I don't see a lot of reason not to do it. I'll
give it a go.

>†I think sys.implementation.metadata
> † should be the same type.

This I wonder about. The more I think about it, the more it fits.
I'll give it a day and if that still holds I'll work it in.

Thanks for the feedback, Barry! Feels like the PEP's getting close.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

May 9, 2012, 2:57 AM

Post #13 of 55 (367 views)
Permalink
Re: sys.implementation [In reply to]

On 27.04.2012 09:34, Eric Snow wrote:
> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw<barry [at] python> 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

Interesting proposal. I have a number of comments:

- namespace vs. dictionary. Barry was using it in the form
sys.implementation.version. I think this is how it should work,
yet the PEP says that sys.implementation is a dictionary, which
means that you would need to write
sys.implementation['version']

I think the PEP should be silent on the type of sys.implementation,
in particular, it should not mandate that it be a module (else
"from sys.implementation import url" ought to work)

[.Update: it seems this is already reflected in the PEP. I wonder
where the requirement for "a new type" comes from. I think making
it a module should be conforming, even though probably discouraged
for cpython, as it would make people think that they can rely on
it being a module. I wish there was a builtin class

class record:
pass

which can be used to create objects which have only attributes
and no methods. Making it a type should also work:

class implementation:
name = "cpython"
version = (3,3,0)

in which case it would an instance of an existing type, namely,
"type"]

- under-specified attributes: "run-time environment" doesn't mean much
to me - my first guess is that it is the set of environment variables,
i.e. a dictionary identical to os.environ. I assume you mean something
different ...
gc_type is supposedly a string, but I cannot guess what possible
values it may have. I also wonder why it's relevant.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


brett at python

May 9, 2012, 7:44 AM

Post #14 of 55 (361 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 5:57 AM, "Martin v. Löwis" <martin [at] v>wrote:

> On 27.04.2012 09:34, Eric Snow wrote:
>
>> On Thu, Apr 26, 2012 at 8:31 AM, Barry Warsaw<barry [at] python> 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<http://mail.python.org/pipermail/python-ideas/2012-April/014954.html>
>>
>
> Interesting proposal. I have a number of comments:
>
> - namespace vs. dictionary. Barry was using it in the form
> sys.implementation.version. I think this is how it should work,
> yet the PEP says that sys.implementation is a dictionary, which
> means that you would need to write
> sys.implementation['version']
>
> I think the PEP should be silent on the type of sys.implementation,
> in particular, it should not mandate that it be a module (else
> "from sys.implementation import url" ought to work)
>
> [.Update: it seems this is already reflected in the PEP. I wonder
> where the requirement for "a new type" comes from. I think making
> it a module should be conforming, even though probably discouraged
> for cpython, as it would make people think that they can rely on
> it being a module.


That stems from people arguing over whether sys.implementation should be a
dict or a tuple, and people going "it shouldn't be a sequence since it
lacks a proper order", but then others saying "it shouldn't be a dict
because it isn't meant to be mutated" (or something since I argued for the
dict). So Eric (I suspect) went with what made sense to him.


> I wish there was a builtin class
>
> class record:
> pass
>
> which can be used to create objects which have only attributes
> and no methods.


I have heard this request now a bazillion times over the years. Why don't
we have such an empty class sitting somewhere in the stdlib with a
constructor classmethod to simply return new instances (and if you want to
get really fancy, optional keyword arguments to update the instance with
the keys/values passed in)? Is it simply because it's just two lines of
Python that *everyone* has replicated at some point?

-Brett



> Making it a type should also work:
>
> class implementation:
> name = "cpython"
> version = (3,3,0)
>
> in which case it would an instance of an existing type, namely,
> "type"]
>
> - under-specified attributes: "run-time environment" doesn't mean much
> to me - my first guess is that it is the set of environment variables,
> i.e. a dictionary identical to os.environ. I assume you mean something
> different ...
> gc_type is supposedly a string, but I cannot guess what possible
> values it may have. I also wonder why it's relevant.
>
> Regards,
> Martin
>
> ______________________________**_________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/**mailman/listinfo/python-dev<http://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: http://mail.python.org/**mailman/options/python-dev/**
> brett%40python.org<http://mail.python.org/mailman/options/python-dev/brett%40python.org>
>


solipsis at pitrou

May 9, 2012, 7:50 AM

Post #15 of 55 (362 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, 9 May 2012 10:44:59 -0400
Brett Cannon <brett [at] python> wrote:
>
> > I wish there was a builtin class
> >
> > class record:
> > pass
> >
> > which can be used to create objects which have only attributes
> > and no methods.
>
>
> I have heard this request now a bazillion times over the years. Why don't
> we have such an empty class sitting somewhere in the stdlib with a
> constructor classmethod to simply return new instances (and if you want to
> get really fancy, optional keyword arguments to update the instance with
> the keys/values passed in)? Is it simply because it's just two lines of
> Python that *everyone* has replicated at some point?

In this case, it's because sys is a built-in module written in C, and
importing Python code is a no-go.

We have a similar problem with ABCs: io jumps through hoops to register
its implementation classes with the I/O ABCs.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 9, 2012, 7:51 AM

Post #16 of 55 (360 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 3:57 AM, "Martin v. LŲwis" <martin [at] v> wrote:
> Interesting proposal. I have a number of comments:

Thanks for taking a look, Martin.

> - namespace vs. dictionary. Barry was using it in the form
> †sys.implementation.version. I think this is how it should work,
> †yet the PEP says that sys.implementation is a dictionary, which
> †means that you would need to write
> †sys.implementation['version']
>
> †I think the PEP should be silent on the type of sys.implementation,
> †in particular, it should not mandate that it be a module (else
> †"from sys.implementation import url" ought to work)
>
> †[.Update: it seems this is already reflected in the PEP. I wonder
> † where the requirement for "a new type" comes from. I think making
> † it a module should be conforming, even though probably discouraged
> † for cpython, as it would make people think that they can rely on
> † it being a module. I wish there was a builtin class
>
> † † class record:
> † † † †pass
>
> † which can be used to create objects which have only attributes
> † and no methods. Making it a type should also work:
>
> † †class implementation:
> † † † name = "cpython"
> † † † version = (3,3,0)
>
> †in which case it would an instance of an existing type, namely,
> †"type"]

The type for sys.implementation has slowly shifted from the original
proposal. At this point it's settled into where I think it will stay,
a custom type. I've covered the choice of type in the rationale
section. However, there may be merit in not being so specific about
the type. I'll give that some thought.

> - under-specified attributes: "run-time environment" doesn't mean much
> †to me - my first guess is that it is the set of environment variables,
> †i.e. a dictionary identical to os.environ. I assume you mean something
> †different ...
> †gc_type is supposedly a string, but I cannot guess what possible
> †values it may have. I also wonder why it's relevant.

Sorry for the confusion. These are from the examples section for
sys.implementation.metadata. I believe the current version of the PEP
is more clear on the distinction.

Thanks again for the feedback.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 9, 2012, 7:53 AM

Post #17 of 55 (361 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 8:44 AM, Brett Cannon <brett [at] python> wrote:
> On Wed, May 9, 2012 at 5:57 AM, "Martin v. LŲwis" <martin [at] v>
> wrote:
>> †[Update: it seems this is already reflected in the PEP. I wonder
>> † where the requirement for "a new type" comes from. I think making
>> † it a module should be conforming, even though probably discouraged
>> † for cpython, as it would make people think that they can rely on
>> † it being a module.
>
>
> That stems from people arguing over whether sys.implementation should be a
> dict or a tuple, and people going "it shouldn't be a sequence since it lacks
> a proper order", but then others saying "it shouldn't be a dict because it
> isn't meant to be mutated" (or something since I argued for the dict). So
> Eric (I suspect) went with what made sense to him.

Yep.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 9, 2012, 8:07 AM

Post #18 of 55 (365 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 8:50 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:
> On Wed, 9 May 2012 10:44:59 -0400
> Brett Cannon <brett [at] python> wrote:
>>
>> > I wish there was a builtin class
>> >
>> > † † class record:
>> > † † † †pass
>> >
>> > † which can be used to create objects which have only attributes
>> > † and no methods.
>>
>>
>> I have heard this request now a bazillion times over the years. Why don't
>> we have such an empty class sitting somewhere in the stdlib with a
>> constructor classmethod to simply return new instances (and if you want to
>> get really fancy, optional keyword arguments to update the instance with
>> the keys/values passed in)? Is it simply because it's just two lines of
>> Python that *everyone* has replicated at some point?
>
> In this case, it's because sys is a built-in module written in C, and
> importing Python code is a no-go.

Something I've remotely considered is an approach like namedtuple
takes: define a pure Python template, .format() it, and exec it.
However, this is partly a reflection of my lack of familiarity with
using the C-API. As well, the only place I've seen this done in the
CPython code base is with namedtuple. Consequently, I was planning on
taking the normal approach. Should the namedtuple-exec technique be
avoided at the C level?

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


brett at python

May 9, 2012, 8:09 AM

Post #19 of 55 (362 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 10:50 AM, Antoine Pitrou <solipsis [at] pitrou> wrote:

> On Wed, 9 May 2012 10:44:59 -0400
> Brett Cannon <brett [at] python> wrote:
> >
> > > I wish there was a builtin class
> > >
> > > class record:
> > > pass
> > >
> > > which can be used to create objects which have only attributes
> > > and no methods.
> >
> >
> > I have heard this request now a bazillion times over the years. Why don't
> > we have such an empty class sitting somewhere in the stdlib with a
> > constructor classmethod to simply return new instances (and if you want
> to
> > get really fancy, optional keyword arguments to update the instance with
> > the keys/values passed in)? Is it simply because it's just two lines of
> > Python that *everyone* has replicated at some point?
>
> In this case, it's because sys is a built-in module written in C, and
> importing Python code is a no-go.
>

Sure, but couldn't we define this "empty" class in C code so that you can
use the C API with it as well and just provide a C function to get a new
instance?

-Brett


>
> We have a similar problem with ABCs: io jumps through hoops to register
> its implementation classes with the I/O ABCs.
>
> Regards
>
> Antoine.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/brett%40python.org
>


barry at python

May 9, 2012, 9:39 AM

Post #20 of 55 (363 views)
Permalink
Re: sys.implementation [In reply to]

On May 08, 2012, at 09:03 PM, Eric Snow wrote:

>>   This is defined as the version of the implementation, while
>>   sys.version_info is the version of the language.  The semantics of
>>   sys.version_info have been sufficiently squishy in the past, as the XXX
>>   implies.  This PEP shouldn't try to untangle that, so I think it be better
>>   to represent both values explicitly in sys.implementation.
>
>Definitely tangled. So, sys.implementation.version and
>sys.implementation.lang_version? Also, my inclination is to not have
>a sys.version equivalent in sys.implementation for now, in the
>interest of keeping things as bare-bones as possible to start.

I think it would be fine, if PEP 421 was clear about the semantics of
sys.implementation.version and was silent about trying to disentangle the
semantics of sys.version. IOW, the PEP can say that the semantics of
sys.version are fuzzy, but not try to clear it up. Then it would be explicit
(as it already is) that sys.implementation.version describes the version of
the implementation, not the version of the language compliance.

If the latter is useful later, then it can use the PEP 421 described process
to propose a new sys.implementation value that describes a language compliance
variable.

>>  * I mildly prefer sys.implementation.name to be lower cased.  My intuition
>> is   that to be safe, most comparisons of the value will coerce to lower
>> case,   which is easy enough in Python, but perhaps a bit more of a pain in
>> C.  I   don't feel really strongly about this though.  (A counter argument
>> is that   the value might be printed, so a case-sensitive version would be
>> better.)
>
>I'm not sure it makes a lot of difference. Since cache_tag will be
>provided by the implementation, I don't have any strong use-cases that
>would constrain the name itself. Still, my preference is for lower
>case as well. I'll mull this one over.

Cool. As I said, I'm on the fence about it too. :)

>>  * I've said before that I think the keys in sys.implementation should be
>>   locked down (i.e. not writable).
>
>I've been on and off about this. It's certainly not too hard to do,
>it makes sense, and I don't see a lot of reason not to do it. I'll
>give it a go.

Maybe it doesn't matter. We're all adults here. I think there are two good
choices. Either the PEP explicitly describes sys.implementation as immutable,
or it is silent about it. IOW, I don't think the PEP should explicitly allow
sys.implementation to be mutable.

>> I think sys.implementation.metadata
>>   should be the same type.
>
>This I wonder about. The more I think about it, the more it fits.
>I'll give it a day and if that still holds I'll work it in.

Cool.

>Thanks for the feedback, Barry! Feels like the PEP's getting close.

Indeed!

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

May 9, 2012, 9:45 AM

Post #21 of 55 (361 views)
Permalink
Re: sys.implementation [In reply to]

> Sure, but couldn't we define this "empty" class in C code so that you can
> use the C API with it as well and just provide a C function to get a new
> instance?

That would be easy. All you need is a dictoffset.

Regards,
Martin


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 9, 2012, 9:50 AM

Post #22 of 55 (363 views)
Permalink
Re: sys.implementation [In reply to]

On May 09, 2012, at 08:51 AM, Eric Snow wrote:

>The type for sys.implementation has slowly shifted from the original
>proposal. At this point it's settled into where I think it will stay,
>a custom type. I've covered the choice of type in the rationale
>section. However, there may be merit in not being so specific about
>the type. I'll give that some thought.

Right. See my previous follow up for what I think the PEP should say about
the semantics of the type, without being so specific about the actual type.

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

May 9, 2012, 9:53 AM

Post #23 of 55 (361 views)
Permalink
Re: sys.implementation [In reply to]

On May 09, 2012, at 11:09 AM, Brett Cannon wrote:

>Sure, but couldn't we define this "empty" class in C code so that you can
>use the C API with it as well and just provide a C function to get a new
>instance?

+1

ISTM to be a companion to collections.namedtuple. IWBNI this new type was
also exposed in the collections module.

-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ericsnowcurrently at gmail

May 9, 2012, 5:16 PM

Post #24 of 55 (343 views)
Permalink
Re: sys.implementation [In reply to]

On Wed, May 9, 2012 at 10:39 AM, Barry Warsaw <barry [at] python> wrote:
> On May 08, 2012, at 09:03 PM, Eric Snow wrote:
>>Definitely tangled. †So, sys.implementation.version and
>>sys.implementation.lang_version? †Also, my inclination is to not have
>>a sys.version equivalent in sys.implementation for now, in the
>>interest of keeping things as bare-bones as possible to start.
>
> I think it would be fine, if PEP 421 was clear about the semantics of
> sys.implementation.version and was silent about trying to disentangle the
> semantics of sys.version. †IOW, the PEP can say that the semantics of
> sys.version are fuzzy, but not try to clear it up. †Then it would be explicit
> (as it already is) that sys.implementation.version describes the version of
> the implementation, not the version of the language compliance.
>
> If the latter is useful later, then it can use the PEP 421 described process
> to propose a new sys.implementation value that describes a language compliance
> variable.

Whoops. I meant that I'm okay with having sys.implementation.version
and sys.implementation.lang_version, both as analogs to
sys.version_info. My inclination is to not include the analog to
sys.version. However, with the way that you put it, I think you're
right that we could put off the lang_version attribute for later.

>>> †* I've said before that I think the keys in sys.implementation should be
>>> † locked down (i.e. not writable).
>>
>>I've been on and off about this. †It's certainly not too hard to do,
>>it makes sense, and I don't see a lot of reason not to do it. †I'll
>>give it a go.
>
> Maybe it doesn't matter. †We're all adults here. †I think there are two good
> choices. †Either the PEP explicitly describes sys.implementation as immutable,
> or it is silent about it. †IOW, I don't think the PEP should explicitly allow
> sys.implementation to be mutable.

Agreed.

-eric
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


larry at hastings

May 9, 2012, 5:47 PM

Post #25 of 55 (343 views)
Permalink
Re: sys.implementation [In reply to]

On 05/09/2012 09:53 AM, Barry Warsaw wrote:
> On May 09, 2012, at 11:09 AM, Brett Cannon wrote:
>
>> Sure, but couldn't we define this "empty" class in C code so that you can
>> use the C API with it as well and just provide a C function to get a new
>> instance?
> +1
>
> ISTM to be a companion to collections.namedtuple. IWBNI this new type was
> also exposed in the collections module.

I like Alex Martelli's approach, which I recall was exactly this:

class namespace:
def __init__(**kwargs):
self.__dict__ = kwargs


That means all the initializers you pass in to the constructor get
turned into members.


//arry/

First page Previous page 1 2 3 Next page Last page  View All Python dev 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.