On 27.04.2012 09:34, 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

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.
">

(original) (raw)



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

On 27.04.2012 09:34, 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

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@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org