the rust library we're using for an ordered set/map actually cites the python implementation

nice

https://docs.python.org/3.6/whatsnew/3.6.html#new-dict-implementation ->

The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon (this may change in the future, but it is desired to have this new dict implementation in the language for a few releases before changing the language spec to mandate order-preserving semantics for all current and future Python implementations; this also helps preserve backwards-compatibility with older versions of the language where random iteration order is still in effect, e.g. Python 3.5).

yep

honestly, it makes sense for it to be explicitly requested anyway

seems like they should have an

ordereddict

builtin type that you can rely on that w/

yep, exactly.

ya

@rough-minister-58256: test semantics question.

for https://github.com/pantsbuild/pants/issues/4401 per test, we create one Scheduler/BuildGraph (lazily if requested)

because we don't do any filesystem invalidation, most of the operations involved in parsing additional targets from disk are cached

ie, if you call

BaseTest.target

repeatedly, it used to re-list the filesystem each time it went looking for a target

(because the BuildFileParser did)

now, because the Scheduler is caching most of that, the test needs to create all on disk state before triggering any parsing

as an example,

self.target('src/thrift/storage')

in https://github.com/pantsbuild/pants/blob/master/tests/python/pants_test/backend/project_info/tasks/test_filedeps.py#L114 triggers BUILD file parsing to find that target

i see

then, the additional targets created later in that method will not be located

the reason i ask about this is: 1) it was interesting to track down, and i imagine it would be interesting for the next person to track down if they triggered parsing before they'd finished putting things on disk

could we do implicit invalidation in the test methods somewhere?

2) on the other hand, it's probably more performant, and a reasonable thing to do

we could: but the alternative i've been thinking of is just to reorder harness creation in all cases, so that we can actually use the caching

ah

sgtm

iff possible

tho it might be nice to be exercising invalidation a bit?

one thing that comes to mind is that it might be possible to formalize the whole "harness with a bunch of files" concept a bit

hm. so invalidate for created files?... um, yea. i guess that would be totally reasonable.

yeah like implicit call to invalidate in the helper method that creates the files

and still allow for some amount of caching.