New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support kw=Collection(task) in addition to Collection('kw', task) #528
Comments
That sounds accidental to me. Based on the traceback I'm betting it has to do with the overhaul for |
Suspect this is missed in our test suite because the fixtures I use for testing I can confirm we have a test about the actual kwarg-key-is-the-name behavior and it's passing, so this is either limited to |
Cool, when I tweak that test fixture I'm getting a big bunch of errors all resembling yours or with same presumed root (a None instead of a string). Thanks for the report...patch should be in soon. |
Think this is due to an annoying modeling discrepancy: the fact that a task or collection can be added to a Collection multiple times, and thus there are two ways to "name" these objects - the dictionary key they are attached as at a given point, and/or their own internal/intrinsic name. Most of the time, namespace-crawling functionality is concerned only with the former: something is requesting lookup of eg This is why, for example, in @tuukkamustonen's case, actually invoking However, the new list functionality at one point looks at the latter name - the object's intrinsic name - and in the case under examination, it's None (because, as Tuukka stumbled upon, that's driven entirely by whether the inner The naive fix is to modify the object when it's being given as a kwarg value - but this is misleading because as noted above, that's a big no-no (mutating an object you were given by your caller) in general. And in specifics, it would be problematic for us if the object were to be attached elsewhere in the tree later (the name would just get overwritten a second time). So I'm 99% sure the right fix is to not reference |
Have that mostly solved but there is another minor add-on problem (I think more an issue with my test than reality), the now-not-a-module subcollection I tweaked lost its docstring, because...I'm handing in the raw collection and not the module. Technically I should fix this by updating my test output assertions to not expect help text for that particular subcollection, but it makes me realize that there is no way to specify the help for a collection this way - the help functionality has been written assuming one is using module trees. I'll probably hack it up now to save myself some work, but it means there needs to be a spinoff feature ticket. |
This is fixed now on master. Doing some unrelated release oriented tasks now but I'll push to GH soon. PyPI release should be within a day or two, hopefully. |
…sic names Also happens to end up simplifying the overall recursion loop too.
Pre-0.23 supported:
But now it fails (on py3.5 at least) to:
Now we have to give the namespace as str parameter to
Collection
as in:Was this change intended or accidental? I liked to old way more (rather kwarg than positional string arg).
The text was updated successfully, but these errors were encountered: