On 27.04.2012 09:34, 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. > > 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4