-
-
Notifications
You must be signed in to change notification settings - Fork 315
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
Fix #3156: Modify Dictionary implementation to match docs #3211
Conversation
Can you take a look at the travis failure? |
I looked earlier, and don't know what to say. It is the trickiest test change, the one where I had to resort to using a set to be able to check efficiently, but... it passes everything I've run it on here, and all the other CI builds, so I'm mystified at the moment. Is there anything different I should know about for that build? |
ab72328
to
0c78590
Compare
Documentation for Dictionary(): "Returns a dictionary object containing copies of all of the construction variables in the environment. If there are any variable names specified, only the specified construction variables are returned in the dictionary." However, in the existing implementation, if called with no arguments it directly returns the internal dictionary of the construction environment, the one it uses to implement its dictionary-like behavior (matches docs); if a single key argument is passed it returns the value for that key; if multiple keys are passed it returns a list of the matching values. In neither of the latter two case does it return a dict object. This change in Environment.py aligns the behavior with the docs. Since all the tests are coded to the actual behavior, rather than the documented behavior, none demonstrated any problem, which is only seen if a user themselves uses Dictionary() as documented. All the tests which depend on the old behavior thus needed some adjustment. The normal pattern follows this example: env['FOO'] = 'foo' assert env.Dictionary('FOO') == 'foo' which breaks when Dictionary returns a dict instead of value. That can change to either of two following forms - the former is more like the origial intent, but the second pattern has been chosen because it looks less awkward, except for a few cases that seemed to be testing specifically the limiting of the returned Dictionary by giving it a specific number of keys: assert env.Dictionary('FOO')['FOO'] == "foo" assert env.Dictionary()['FOO'] == "foo" A couple of internal tests define dummy classes which implement their own version of Dictionary. These needed updating as well. If the dummy took no args, it was left alone (BuilderTests.py, FSTests.py, NodeTests.py). If the dummy ignored args it still does so, but got a comment line to that effect. If it takes one key argument it builds a one-item dict (SubstTests.py, msvsTests.py), if it takes *args like the main Dictionary it got the change of the original (ProgTests.py), and if it took args but did something special (FortranTests.py, IDLTests.py) it was adjusted to be sure it was still returning a dict object. I'm not clear if the cases where a dummy Dictionary does not have the same signature as the real Dictionary are correct, but there are enough changes here already, we could look at that topic separately. Fixes SCons#3156 Signed-off-by: Mats Wichmann <mats@linux.com>
0c78590
to
d830eb0
Compare
Since the last time this was built, Travis and Appveyor run more tests, and that turned up some missed locations that needed updating. Signed-off-by: Mats Wichmann <mats@linux.com>
6dfc00f
to
125f1ff
Compare
Since the last time this was built, Travis and Appveyor run more tests, and that turned up some missed locations that needed updating. Signed-off-by: Mats Wichmann <mats@linux.com>
125f1ff
to
68c74cd
Compare
Since the last time this was built, Travis and Appveyor run more tests, and that turned up some missed locations that needed updating. Signed-off-by: Mats Wichmann <mats@linux.com>
68c74cd
to
bb3b2a4
Compare
Since the last time this was built, Travis and Appveyor run more tests, and that turned up some missed locations that needed updating. Signed-off-by: Mats Wichmann <mats@linux.com>
Since the last time this was built, Travis and Appveyor run some new tests (lex) which needed the Dictionary usage update. Also adjust some of the asserts - fixed the set test for fetching more than a single key-value pair via Dictionary, and added the expression to raise to several assert statements. Signed-off-by: Mats Wichmann <mats@linux.com>
bb3b2a4
to
4ef3f8b
Compare
I can withdraw this PR so it doesn't clutter up the list. See issue #3156 for discussion. |
Withdrawn in favor of #3423 |
Documentation for
Dictionary()
: "Returns a dictionary object containing copies of all of the construction variables in the environment. If there are any variable names specified, only the specified construction variables are returned in the dictionary." However, in the existing implementation, if called with no arguments it directly returns the internal dictionary of the construction environment, the one it uses to implement its dictionary-like behavior (matches docs); if a single key argument is passed it returns the value for that key; if multiple keys are passed it returns a list of the matching values. In neither of the latter two case does it return a dict object. This change inEnvironment.py
aligns the behavior with the docs.Since all the tests are coded to the actual behavior, rather than the documented behavior, no tests demonstrated any problem, which is only seen if a user themselves uses
Dictionary
as documented. All the tests which depend on the old behavior thus needed some adjustment. The normal pattern follows this example:which breaks when
Dictionary
returns a dict instead of the value. That can change to either of two following forms - the former is more like the origial intent, but the second pattern has been chosen because it looks less awkward, except for a few cases that seemed to be testing specifically the limiting of the returned Dictionary by giving it a specific number of keys:A couple of internal tests define dummy classes which implement their own version of
Dictionary
. These needed updating as well. If the dummy took no args, it was left alone (BuilderTests.py
,FSTests.py
,NodeTests.py
). If the dummy ignored args it still does so, but got a comment line to that effect. If it takes one key argument it builds a one-item dict (SubstTests.py
,msvsTests.py
), if it takes*args
like the mainDictionary
it got the change of the original (ProgTests.py
), and if it took args but did something special (FortranTests.py
,IDLTests.py
) it was adjusted to be sure it was still returning a dict object. I'm not clear if the cases where a dummyDictionary
does not have the same signature as the realDictionary
are correct, but there are enough changes here already, we could look at that topic separately.Fixes #3156
Signed-off-by: Mats Wichmann mats@linux.com
Contributor Checklist:
master/src/CHANGES.txt
directory (and read theREADME.txt
in that directory)