This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author thomas.holmes
Recipients brett.cannon, pitrou, r.david.murray, roysmith, thomas.holmes
Date 2010-01-27.03:39:17
SpamBayes Score 2.52132e-13
Marked as misclassified No
Message-id <1264563558.94.0.462329670656.issue7325@psf.upfronthosting.co.za>
In-reply-to
Content
I agree, I do not feel like the precise changes to the tests feel completely ideal.  I feel that this problem stems from the fact that the nameCheck function as originally written doesn't seem to completely serve its originally intended purpose.

The original issue that caused the modifications of the tests were as follows:

* After adding "test_abs_path()" namecheck would pass the test when it should actually fail due to the original assert performing os.path.abspath() on both paths.  The obviously solution to this seemed to be to take the abspath of the user supplied path (the variable dir in this function) relative or otherwise and compare to ndir which is derived from the passed in "name" variable, populated by the mkdtemp call.

* The second issue is a somewhat complex case of those asserts passing the atypical odd calls of nameCheck from the "test__RandomNameSequence" suite.  Without absolute pathing of both parameters in the new first assert this test began to fail.  This is because the original call was self.namecheck(<file name>, '', '', '').  These empty parameters when called with os.path.abspath() would return valid paths and these asserts would succeed.  As a result, the abspath(join()) call built a proper path into the "name" parameter allowing the tests to pass in this case.

* For the sake of cleanliness I decided it made more sense to split the two apart.  Make one assert that specifically verifies the path the file/folder is being placed in is both absolute and matching and one that will pass the file name.  Perhaps the old first assert (or second assert in the patch) can actually be removed but I think it may be getting properly tested against in one of the other test classes.

I am quite confident there is a much better way to accomplish this but I did not wish to change _too_ much of the test on my first stab at this.

I appreciate your feedback very much.  I will work on setting up the 2.7 environment for working on issues that span the 2x/3x gap.
History
Date User Action Args
2010-01-27 03:39:19thomas.holmessetrecipients: + thomas.holmes, brett.cannon, roysmith, pitrou, r.david.murray
2010-01-27 03:39:18thomas.holmessetmessageid: <1264563558.94.0.462329670656.issue7325@psf.upfronthosting.co.za>
2010-01-27 03:39:17thomas.holmeslinkissue7325 messages
2010-01-27 03:39:17thomas.holmescreate