classification
Title: add sys.implementation
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Arfrever, amaury.forgeotdarc, barry, brett.cannon, brian.curtin, eric.araujo, eric.snow, loewis, ncoghlan, python-dev, sbt
Priority: normal Keywords: patch

Created on 2012-04-26 05:16 by eric.snow, last changed 2012-06-04 21:49 by barry. This issue is now closed.

Files
File name Uploaded Description Edit
sys_implementation.diff eric.snow, 2012-04-26 05:16 implements sys.implementation and doc addition review
sys_implementation_2.diff eric.snow, 2012-04-27 07:31 implements sys.implementation, a test, and a doc addition review
issue14673_as_module.diff eric.snow, 2012-05-26 19:19
issue14673_as_type.diff eric.snow, 2012-05-26 19:19
issue14673_as_structseq.diff eric.snow, 2012-05-26 19:19
issue14673_as_simple_namespace.diff eric.snow, 2012-05-26 19:19
issue14673_docs_and_tests.diff eric.snow, 2012-05-26 19:20 documentation and tests for sys.implementation
issue14673_as_simple_namespace_2.diff eric.snow, 2012-05-31 06:11 review
issue14673_docs_and_tests_2.diff eric.snow, 2012-05-31 06:15 review
issue14673_full.diff eric.snow, 2012-06-01 05:06 updated patch including docs, tests, and types.SimpleNamespace review
issue14673_full_2.diff eric.snow, 2012-06-02 02:19 review
issue14673_full_3.diff eric.snow, 2012-06-02 06:49 up-to-date complete patch with all tests passing review
issue14673_full_4.diff eric.snow, 2012-06-02 23:33 updated docs for Amaury review
Messages (41)
msg159357 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-26 05:16
(see thread at http://mail.python.org/pipermail/python-ideas/2012-April/014878.html)

This is a patch to add sys.implementation to Python (with doc addition).  The main motivation is to have an explicit place to look for the name and version of the implementation for generating the import cache tag (a la PEP 3147).
msg159365 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2012-04-26 13:06
If it can contain a variable number of fields, I think it should be a dict rather than a tuple.
msg159377 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2012-04-26 15:12
*version* is a version tuple, in the format of :data:`sys.version_info`,
   which represents the version of the Python implementation, **not** the
   version of the Python specification it implements.

If that version number is specific to each VM, then I’m not sure we should mandate a specific format.
msg159390 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-26 16:07
@antoine - I wondered about that.  In the end I got something up to start with.

The list of fields in sys.implementation may change over time, unlike sys.version_info, et al.  However, during interpreter execution, I would expect that neither that list nor the contents would change.  The variability would only be between implementations and between versions of those implementations.

A dict would imply to me that it might vary during interpreter execution.  An immutable type makes it clear to me that it won't be changing.  I'm fine with a dict, though, if you think that's better.  Perhaps a dictproxy?
msg159393 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-26 16:17
@Éric - that's a good point.  I considered it for a little bit, but went with the quick and easy think to get it rolling.

There is a real benefit to mandating an API sys.implementation.version.  importlib would use that version to calculate the tag to use for cached modules.  Without a specified/uniform data structure, that job is trickier.

Having an explicit sys.implementation.cache_tag field would solve that, and the importlib code would check for that field first.  However, I didn't want to start off with that as a "required" field, considering that only CPython would take advantage of module caches (as far as I know).
msg159394 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-26 16:19
I'm going to write a PEP for this, after all.  I want to make sure that it's easy to access, in one place, these points that are coming up and their resolutions.
msg159415 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-26 19:11
If the main motivation for this is that importlib can use it, I fail to see the point to make it cross-implementation. Other implementations of Python may not use byte code files at all, or use different byte code syntaxes, or not use the marshal module to load byte code. So the part of importlib that deals with cached .pyc files will be specific to CPython, anyway - why make it a cross-implementation attribute?
msg159425 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-26 21:08
Thanks for bringing this up, Martin.

sys.implementation is about having an implementation-specific location (hence sys) to consolidate explicit values concerning the implementation.  It's partly about clarifying the run-time distinction between Python-the-language and Python-the-implementation.

'name' and 'version' are the initial fields in sys.implementation because they are the most obvious choices, and a good starting point.  If sys.implementation were available now we'd use it in importlib.  That's what has motivated me to pursue this.

You are correct that we can hard-code "cpython" in the bootstrap code to generate the cache tag.  And perhaps that would be a better use of time.  We can't just use platform.python_implementation(), however, since the frozen importlib can only use builtin modules.

I expect you're right that some of the importlib code (particularly w.r.t. cached modules) is CPython-specific.  However, I'm sure Brett has tried to minimize that subset of the module.  Maybe he knows if the other implementations have plans for using importlib or how it affects them.  If not, I'll ask around.

Regardless, importlib is not the only motivator here.  Right now platform.python_implementation() has to guess the implementation name.  Having the different implementations specify the name explicitly in the sys module would be an improvement without a lot of work.  Nick Coghlan has indicated that it would be useful for the test suite.

Ultimately, sys.implementation would become the source for information about a specific Python implementation.  Others could expound the point better, but as time goes by this will be more important.  This current effort would get the ball rolling.  Consequent to the concerns so far, I'll try to get a PEP out in the next couple days.
msg159435 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2012-04-26 23:52
So I'm w/ Antoine that a dict would be better so that the other VMs can add whatever they want into that object (e.g. Jython could specify what JVM they are running against) without causing confusion as to what some index means to each VM. The mutability of it is not important IMO.

As for the other implementations using importlib, they all plan to with (hopefully) no direct modification, but whether they support bytecode I don't know (I think Jython has talked about it, but who knows).

And pertaining to whether this is useful outside of importlib, I suspect it is. We already have 'jython' as an "OS" type to work around some differences. Adding this attribute would more clearly delineate when another VM is being used that might require working around some difference without overloading os.name (e.g. PyPy implementing something differently in their 1.7 release of Python 2.7 but is subsequently fixed in their 1.8 release).
msg159441 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-04-27 07:13
When I added sys.subversion, people requested that it shall contain the CPython string. When sys._mercurial was introduced, it copied that. So there are plenty of ways already to figure out that it is CPython which you are using.
msg159444 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-04-27 07:31
An updated patch using a dict.  (FYI, I have the PEP up on python-ideas.)
msg161223 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-20 18:44
FYI, the attached patches don't reflect the latest PEP.  I'll get an updated patch up in the next day or two.
msg161632 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-26 01:54
I've just attached 4 patches, one for each of the likeliest implementations.  All 4 ran the test suite successfully.

In my mind, the "simple namespace" one is the best fit.  However, it involves adding a new built-in type (though a private one).  If that is too controversial or too much new stuff to iron out for 3.3, I'd be okay with any of the others.  In reality I'd like to see that new namespace type added to Python, but that's a proposition I'll take up elsewhere.  :)
msg161679 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-26 19:22
I updated the patches so that (hopefully) the review link shows up.  I've also pulled out the doc/test diff into its own patch, since it was the same for all of them.
msg161960 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-05-30 14:55
One small test that I think is missing is a test that sys.implementation.version and sys.implementation.hexversion are equal (modulo format differences).
msg161963 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-05-30 15:30
I'm not a fan of using a module, and less of a fan of structseq, so I think I'll discount those two.  I'll play with namespace and type next.
msg161965 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-05-30 19:42
I'm inclined to go with the as_simple_namespace patch.  As you say, the pro are that this is a much better fit for this use case, while the con is that this does kind of sneak in a new type.  Given that the type is not exposed in the API, that doesn't bother me.  One other possibility would be to move all that code to sysmodule.c as static functions, and then it definitely won't be available outside sys.  

OTOH, I do think this could eventually be a useful type to expose, however the current behavior of its repr filtering out _names would have to be removed in that case.  However, that's a useful filter for sys.implementation and it doesn't bother me, since you can always repr sys.implementation.__dict__ to get the whole thing.

On balance, my recommendation would be to keep it the way you have it, but perhaps mention this on python-dev, and watch the technicolor bikeshed go psychedelic.

A few other comments as we discussed in irc:

dir(sys.implementation) should return something useful, not traceback

There are a few PEP 7 violations, e.g. brace placements that should be fixed

I was looking at _namespace_init() and a few things bothered me.  I thought this might be superfluous and that you'd be able to just inline the PyDict_Update() calls, but now I'm not so sure.  AFAICT, Python's documentation is silent on whether *args and *kwds in a tp_init function can be NULL or not, and I definitely see cases where similar checks are made in other types.  So I think with that in mind, you must assume they *can* be NULL.  But then I'm not sure the assertions are useful or correct.  Take this scenario:

namespace_init() gets args==NULL.  Your assertion doesn't trigger, but PyObject_Size(NULL) sets an exception and returns -1.  Your conditional doesn't check for an error condition in PyObject_Size() so you'll incorrectly swallow (temporarily) that exception.  At the very least, you need to check for PyObject_Size() < 0.  Don't forget too that those assertions can get compiled away.

I think I'd rather see a PyTuple_Size(args) conditional here for the args parameter.  If it's not a tuple, you'll get an exception set, so check for size < 0.  If size > 0, then you can set the TypeError and return -1 explicitly.

Similarly, just call PyDict_Update(kwds) and return its value.  If kwds is neither a dict nor has a .keys() method (including if its NULL), an exception will be set so everything should work correctly (see _PyObject_CallMethodId() in abstract.c, which is what PyDict_Update() boils down to).

At least, I'm nearly certain that's safe :)

Moving on...

namespace_repr() also has some PEP 7 violations (brace position, extra blank lines).  Please fix these.

Is it ever possible to get into namespace_repr() with ns->ns_dict being NULL?  I think it's impossible.  You might rewrite the if (d == NULL) check with an assertion.

I think you're leaking the PyList_New(0) that you put in `pairs` after you PyUnicode_Join() it.  PyUnicode_Join() doesn't decref its second argument and your losing the original referenced object when you assign `pairs` to its result.

I find the mix of inline error returns and `goto error` handling in namespace_repr() somewhat confusing.  I wonder if it would be more readable (and thus auditable) if there was consistent use of `goto error` with more XDECREFs?  If you feel like it, please try that out.

That's it for now.  Please submit another patch for the as_simple_namespace case and I'll take another look.  Also, if you send a message to python-dev about the introduction of the namespace object, I'll follow up with my support of that option.

Thanks, this is looking great!
msg161969 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-05-30 20:52
History with dictproxy means I'm also OK with "new type by stealth".
Perhaps add some tests to check "type(sys.implementation)()" does something
sane?
msg161981 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-31 06:11
Thanks for taking the time for the review, Barry.  Again, sorry I broke the review link.  It shouldn't be a problem any more.

> Barry A. Warsaw <barry@python.org> added the comment:
>
> I'm inclined to go with the as_simple_namespace patch.  As you say,
> the pro are that this is a much better fit for this use case, while
> the con is that this does kind of sneak in a new type.  Given that
> the type is not exposed in the API, that doesn't bother me.  One
> other possibility would be to move all that code to sysmodule.c as
> static functions, and then it definitely won't be available outside
> sys.
>
> OTOH, I do think this could eventually be a useful type to expose,
> however the current behavior of its repr filtering out _names would
> have to be removed in that case.  However, that's a useful filter for
> sys.implementation and it doesn't bother me, since you can always
> repr sys.implementation.__dict__ to get the whole thing.
>
> On balance, my recommendation would be to keep it the way you have
> it, but perhaps mention this on python-dev, and watch the technicolor
> bikeshed go psychedelic.

:)  I'll bring it up on python-dev.

>
> A few other comments as we discussed in irc:
>
> dir(sys.implementation) should return something useful, not traceback

Not sure what I was doing to block the lookup from object, but it's working now.

So...Fixed.

>
> There are a few PEP 7 violations, e.g. brace placements that should
> be fixed

Done.

>
> I was looking at _namespace_init() and a few things bothered me.  I
> thought this might be superfluous and that you'd be able to just
> inline the PyDict_Update() calls, but now I'm not so sure.  AFAICT,
> Python's documentation is silent on whether *args and *kwds in a
> tp_init function can be NULL or not, and I definitely see cases where
> similar checks are made in other types.  So I think with that in
> mind, you must assume they *can* be NULL.  But then I'm not sure the
> assertions are useful or correct.

Yeah, they're mostly an artifact of copying code.  However, I'm glad they triggered your explanation. ;)

> Take this scenario:
>
> namespace_init() gets args==NULL.  Your assertion doesn't trigger,
> but PyObject_Size(NULL) sets an exception and returns -1.  Your
> conditional doesn't check for an error condition in PyObject_Size()
> so you'll incorrectly swallow (temporarily) that exception.  At the
> very least, you need to check for PyObject_Size() < 0.  Don't forget
> too that those assertions can get compiled away.
>
> I think I'd rather see a PyTuple_Size(args) conditional here for the
> args parameter.  If it's not a tuple, you'll get an exception set, so
> check for size < 0.  If size > 0, then you can set the TypeError and
> return -1 explicitly.

Pretty sure I understand.  Let me know if my new patch says otherwise.  <wink>

So...Done.

>
> Similarly, just call PyDict_Update(kwds) and return its value.  If
> kwds is neither a dict nor has a .keys() method (including if its
> NULL), an exception will be set so everything should work correctly
> (see _PyObject_CallMethodId() in abstract.c, which is what
> PyDict_Update() boils down to).

Done.  This was a case of prematurely optimizing.

>
> At least, I'm nearly certain that's safe :)
>
> Moving on...
>
> namespace_repr() also has some PEP 7 violations (brace position,
> extra blank lines).  Please fix these.

Done.

>
> Is it ever possible to get into namespace_repr() with ns->ns_dict
> being NULL?  I think it's impossible.  You might rewrite the if
> (d == NULL) check with an assertion.

Done.

>
> I think you're leaking the PyList_New(0) that you put in `pairs`
> after you PyUnicode_Join() it.  PyUnicode_Join() doesn't decref its
> second argument and your losing the original referenced object when
> you assign `pairs` to its result.

Good Catch.  Fixed.

>
> I find the mix of inline error returns and `goto error` handling in
> namespace_repr() somewhat confusing.  I wonder if it would be more
> readable (and thus auditable) if there was consistent use of `goto
> error` with more XDECREFs?  If you feel like it, please try that out.

I've given it a go.  :)

>
> That's it for now.  Please submit another patch for the
> as_simple_namespace case and I'll take another look.  Also, if you
> send a message to python-dev about the introduction of the namespace
> object, I'll follow up with my support of that option.
>
> Thanks, this is looking great!

Thanks again for all your support through this process!
msg161982 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-31 06:21
> History with dictproxy means I'm also OK with "new type by stealth".
> Perhaps add some tests to check "type(sys.implementation)()" does
> something sane?

Test added.  Here's what happens:

  >>> cls = type(sys.implementation)
  >>> cls()
  namespace()
  >>> cls(x=1, y=2)
  namespace(x=1, y=2)

Though it's not immediately a problem, "vars(cls(x=1, y=2))" returns "{}", while "ns=cls(x=1, y=2); vars(ns)" returns "{'x': 1, 'y': 2}"!

Certainly it's a corner case, but it could indicate a more sinister problem.  Regardless, I'll track down the root cause and fix it.  As far as I can tell, this odd behavior does not impact sys.implementation.
msg161983 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-05-31 06:23
@Barry: FWIW, the kwds passed to namespace_init was NULL when no keyword arguments were used.  Easy enough to handle though.
msg162047 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-01 04:10
This patch incorporates types.SimpleNamespace and makes the repr show all attributes.  Tests and docs for types.SimpleNamespace are also included.

The patch skips 3 tests (which I added) that are failing.  One has a segfault due to a recursive repr (where I had a hunch that something funny would happen).  One is a situation that I mentioned earlier in this ticket.  However, the third one was entiredly unexpected.

None of these pathologies impact sys.implementation.  I will be working on fixing them regardless.  If you want to wait until I fix the corner cases, I'm fine with that.  However, the patch should be good to go as far as sys.implementation is concerned.
msg162049 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-01 05:06
Guess I should have tested the docs before posting the patch. ;)
msg162081 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-01 17:20
Looking great, you're almost there!  I remviewed issue14673_as_simple_namespace_2.diff and issue14673_full.diff.  Reitveld makes it *so* much easier :)
msg162098 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-01 18:53
sorry, I should have been more clear.  issue14673_full.diff is not simply a merging of the two previous patches, but rather their merger, plus SimpleNamespace, plus removing the "public" restriction from the repr.  I may have a small tweak or two as well.
msg162099 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-01 18:55
On Jun 01, 2012, at 06:53 PM, Eric Snow wrote:

>sorry, I should have been more clear.  issue14673_full.diff is not simply a
>merging of the two previous patches, but rather their merger, plus
>SimpleNamespace, plus removing the "public" restriction from the repr.  I may
>have a small tweak or two as well.

Ah dang.  I'd say just double check both of my sets of comments, disregard the
ones that are no longer relevant and push an update for the _full.diff.  I'll
do one final review and/or just commit it for you.
msg162100 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-01 18:57
I'll get a new patch up tonight.
msg162118 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-02 02:17
Applied all but one of the recommended changes.  Thanks, Barry!
msg162119 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-02 02:19
this time against TIP.
msg162125 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-02 06:49
I've ironed out all 3 of my new tests that were still failing.
msg162127 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2012-06-02 08:03
Some remarks:

- From the docs, I could not understand the difference between sys.implementation.version and sys.version_info.  When can they differ?

- _PyNamespace_New should be a public API function.  From Python code, SimpleNamespace is public.

- I agree that _PyNamespace_Type could stay private (it's an implementation detail), in this case PyAPI_DATA is not necessary.

- SimpleNamespace should support weak references.
msg162186 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-02 23:02
> - From the docs, I could not understand the difference between
> sys.implementation.version and sys.version_info.  When can they differ?

I'll make an update.  As an example, PyPy is at version 1.8 which implements the Python 2.7 language.  In that case sys.version_info would be (2, 7, 3, 'final', 0) while sys.implementation.version might be (1, 8, 0, 'final', 0).

One confusing part is that for CPython they are exactly the same.  I think there's room for improvement with the versioning of the language specification itself, but one thing at a time!  :)

> - _PyNamespace_New should be a public API function.  From Python code,
> SimpleNamespace is public.
> - I agree that _PyNamespace_Type could stay private (it's an
> implementation detail), in this case PyAPI_DATA is not necessary.

Agreed, though I'd like to see sys.implementation go in first and take action on the PyNamespace type/API in a separate issue.

> - SimpleNamespace should support weak references.

I'll admit that I haven't used weakrefs a ton and am not familiar with the use cases.  However, the fact that most of the builtin types do not support weak references gives me pause to simply adding it.

I'd like more discussion on this, but in a separate issue so that it doesn't hold up sys.implementation.
msg162215 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-03 16:05
On Jun 02, 2012, at 11:33 PM, Eric Snow wrote:

>Added file: http://bugs.python.org/file25804/issue14673_full_4.diff

Hi Eric.  I'm ready to do a final review and merge this in, but I just want to
be sure I'm looking at the right file.  Is full_4.diff the most up-to-date
patch, and is it complete (i.e. contains all code, docs, and tests)?
msg162217 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-03 16:09
On Jun 02, 2012, at 08:03 AM, Amaury Forgeot d'Arc wrote:

>- _PyNamespace_New should be a public API function.  From Python code,
>- SimpleNamespace is public.

This is a separate discussion.  I'm not opposed, but I don't think this should
be addressed in this patch.

>- SimpleNamespace should support weak references.

Again, this could be addressed separately.
msg162227 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-03 18:35
> Is full_4.diff the most up-to-date
> patch, and is it complete (i.e. contains all code, docs, and tests)?

Yep.  :)
msg162261 - (view) Author: Roundup Robot (python-dev) Date: 2012-06-04 13:52
New changeset 9c445f4695c1 by Barry Warsaw in branch 'default':
Eric Snow's implementation of PEP 421.
http://hg.python.org/cpython/rev/9c445f4695c1
msg162262 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-04 13:55
I'm resolving this as Fixed since I've just committed the code to 3.3, but I'm also leaving its status open and assigning it to mvl for verification of the Windows build.  Martin, if you'd rather not do that, please unassign it from yourself.  I've also added Brian to the nosy list.
msg162279 - (view) Author: Richard Oudkerk (sbt) * (Python committer) Date: 2012-06-04 17:35
The Windows buildbots were failing compilation.

I've added Object/namespaceobject.c and Include/namespaceobject.h to PCbuild/pythoncore.vcxproj in changeset ee7cd7d51ed6.
msg162289 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2012-06-04 20:23
I think Richard fixed it already, thanks.
msg162297 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2012-06-04 21:39
presumably PEP 421 can be marked as final now?
msg162299 - (view) Author: Barry A. Warsaw (barry) * (Python committer) Date: 2012-06-04 21:49
On Jun 04, 2012, at 09:39 PM, Eric Snow wrote:

>presumably PEP 421 can be marked as final now?

Done.
History
Date User Action Args
2012-06-04 21:49:57barrysetmessages: + msg162299
2012-06-04 21:39:46eric.snowsetmessages: + msg162297
2012-06-04 20:23:14loewissetstatus: open -> closed
assignee: loewis ->
messages: + msg162289
2012-06-04 17:35:02sbtsetnosy: + sbt
messages: + msg162279
2012-06-04 13:55:20barrysetnosy: + brian.curtin
messages: + msg162262

assignee: loewis
resolution: fixed
2012-06-04 13:52:07python-devsetnosy: + python-dev
messages: + msg162261
2012-06-03 18:35:55eric.snowsetmessages: + msg162227
2012-06-03 16:09:59barrysetmessages: + msg162217
2012-06-03 16:05:52barrysetmessages: + msg162215
2012-06-02 23:33:20eric.snowsetfiles: + issue14673_full_4.diff
2012-06-02 23:02:28eric.snowsetmessages: + msg162186
2012-06-02 08:03:29amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg162127
2012-06-02 06:49:18eric.snowsetfiles: + issue14673_full_3.diff

messages: + msg162125
2012-06-02 02:19:10eric.snowsetfiles: + issue14673_full_2.diff

messages: + msg162119
2012-06-02 02:18:04eric.snowsetfiles: - issue14673_full_2.diff
2012-06-02 02:17:10eric.snowsetfiles: + issue14673_full_2.diff

messages: + msg162118
2012-06-01 18:57:44eric.snowsetmessages: + msg162100
2012-06-01 18:55:26barrysetmessages: + msg162099
2012-06-01 18:53:28eric.snowsetmessages: + msg162098
2012-06-01 17:20:55barrysetmessages: + msg162081
2012-06-01 05:07:01eric.snowsetfiles: - issue14673_full.diff
2012-06-01 05:06:46eric.snowsetfiles: + issue14673_full.diff

messages: + msg162049
2012-06-01 04:10:20eric.snowsetfiles: + issue14673_full.diff

messages: + msg162047
2012-05-31 06:23:50eric.snowsetmessages: + msg161983
2012-05-31 06:21:57eric.snowsetmessages: + msg161982
2012-05-31 06:15:12eric.snowsetfiles: + issue14673_docs_and_tests_2.diff
2012-05-31 06:11:44eric.snowsetfiles: + issue14673_as_simple_namespace_2.diff

messages: + msg161981
2012-05-30 20:52:54ncoghlansetmessages: + msg161969
2012-05-30 19:42:34barrysetmessages: + msg161965
2012-05-30 15:30:08barrysetmessages: + msg161963
2012-05-30 14:55:56barrysetmessages: + msg161960
2012-05-26 19:22:01eric.snowsetmessages: + msg161679
2012-05-26 19:20:47eric.snowsetfiles: + issue14673_docs_and_tests.diff
2012-05-26 19:20:38eric.snowsetfiles: - issue14673_as_simple_namespace.diff
2012-05-26 19:20:29eric.snowsetfiles: - issue14673_as_structseq.diff
2012-05-26 19:20:20eric.snowsetfiles: - issue14673_as_type.diff
2012-05-26 19:20:09eric.snowsetfiles: - issue14673_as_module.diff
2012-05-26 19:19:59eric.snowsetfiles: + issue14673_as_simple_namespace.diff
2012-05-26 19:19:48eric.snowsetfiles: + issue14673_as_structseq.diff
2012-05-26 19:19:37eric.snowsetfiles: + issue14673_as_type.diff
2012-05-26 19:19:19eric.snowsetfiles: + issue14673_as_module.diff
2012-05-26 07:24:14pitrousetnosy: - pitrou
2012-05-26 01:55:17eric.snowsetnosy: + barry
2012-05-26 01:54:58eric.snowsetmessages: + msg161632
2012-05-26 01:47:31eric.snowsetfiles: + issue14673_as_simple_namespace.diff
2012-05-26 01:47:20eric.snowsetfiles: + issue14673_as_structseq.diff
2012-05-26 01:47:06eric.snowsetfiles: + issue14673_as_type.diff
2012-05-26 01:46:52eric.snowsetfiles: + issue14673_as_module.diff
2012-05-20 18:44:23eric.snowsetmessages: + msg161223
2012-04-27 07:31:23eric.snowsetfiles: + sys_implementation_2.diff

messages: + msg159444
2012-04-27 07:13:40loewissetmessages: + msg159441
2012-04-26 23:52:01brett.cannonsetmessages: + msg159435
2012-04-26 21:08:10eric.snowsetnosy: + brett.cannon
messages: + msg159425
2012-04-26 19:11:37loewissetnosy: + loewis
messages: + msg159415
2012-04-26 16:19:06eric.snowsetmessages: + msg159394
2012-04-26 16:17:19eric.snowsetmessages: + msg159393
2012-04-26 16:07:51eric.snowsetmessages: + msg159390
2012-04-26 15:12:12eric.araujosetnosy: + eric.araujo
messages: + msg159377
2012-04-26 14:48:52Arfreversetnosy: + Arfrever
2012-04-26 13:06:32pitrousetnosy: + ncoghlan, pitrou
messages: + msg159365
2012-04-26 05:16:11eric.snowcreate