Mailman 3 March 2013 - docs

[issue17351] Fixed python3 descriptor documentation example + removal of explicit "object" inheritance in docs
by Phil Elson March 11, 2013

March 11, 2013

New submission from Phil Elson: The example at http://docs.python.org/3.4/howto/descriptor.html#properties does not run due to the old style "raise AttributeError, message" form. This patch fixes the problem, and also goes through the docs to remove explicit sub-classing from "object". The only remaining instances of this now are: $> grep -r -E "class .*$object$\:" Doc/* Doc/howto/pyporting.rst: class UnicodeMixin(object): Doc/reference/compound_stmts.rst: class Foo(object): Doc/tools/sphinxext/pyspecific.py:class PyDecoratorMixin(object): Doc/whatsnew/2.6.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: class C(object): Doc/whatsnew/2.2.rst: >>> class C(object): Which are all (minus tools/sphinxext/pyspecific) referring to python2 in some context. I'm not bound to fixing the explicit object subclassing, so if it is better off not being here, that's fine. Cheers, ---------- assignee: docs@python components: Documentation files: pelson_doc_decorator.diff keywords: patch messages: 183458 nosy: docs@python, pelson, rhettinger priority: normal severity: normal status: open title: Fixed python3 descriptor documentation example + removal of explicit "object" inheritance in docs versions: Python 3.1 Added file: http://bugs.python.org/file29305/pelson_doc_decorator.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17351> _______________________________________

10 19

[issue763043] unable to specify another compiler
by Éric Araujo March 11, 2013

March 11, 2013

Éric Araujo added the comment: Starting with Python 2.3, environment variables like CC (familiar to people compiling C projects on unix) are respected. That’s what I think should be added to the distutils docs, maybe in the reference doc for build_ext, or in the narrative doc talking about extension modules. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue763043> _______________________________________

1 0

Re: [docs] os.rename documentation slightly inaccurate (issue 16278)
by rovitotv＠gmail.com March 11, 2013

March 11, 2013

Thanks for the review...I think the patch is getting better and better. Soon I should have this tested on Windows, hopefully tonight. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py File Lib/test/test_os.py (right): http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2209: class RenameTests(unittest.TestCase): On 2013/03/11 00:45:35, vstepanov wrote: > I have some comments to this patch. > I think would be better to add two separate test case RenameFileTests and > RenameDirTests or something like that. I actually like it in a single class because alot of the functionality is the same for testing the rename of a directory or file. If we separate it into two classes then I am afraid that we get lots of repeating which leads to DRY test cases. See earlier comments in issue. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2215: self.rename_src_file = "%s_%d_tmp" % ("test_rename_src_file", On 2013/03/11 00:45:35, vstepanov wrote: > All variables has prefix ``rename_`` (rename_src_file, rename_dst_file and so > on), so can use them without this prefix (just src_file, dst_file ...) Good point....this is a side effect from me moving over to a new class before it was in the FileTests directory. Now that we have a RenameTests class we can remove the rename_ in front of all the variables this will help readability. Thanks! http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2216: os.getpid()) On 2013/03/11 00:45:35, vstepanov wrote: > should not call this method everywhere, use a variable Yes that will be more efficient, thanks! http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2217: if os.path.exists(self.rename_src_file): On 2013/03/11 00:45:35, vstepanov wrote: > There is remove_file_or_directory method, use it for remove exist files/dirs. Good point, I don't know how I missed the remove_file_or_directory in setUp but I did. Thanks. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2220: os.write(fd, b"beans\n") On 2013/03/11 00:45:35, vstepanov wrote: > Really need to write many lines in a file and then split the text on the line in > tests? Perhaps enough only one. I got the original code from test_os.py line 111 in the TestWrite method. But it does not have to be that way I think the TestWrite method was testing writes with binary data, byte array data, and memory view data. This is actually easier to read and doing the split lines doesn't add any value. Thanks. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2277: if (os.path.isfile(file)): On 2013/03/11 00:45:35, vstepanov wrote: > outer parentheses are unnecessary Yes too much scheme sorry I missed those, they are gone now. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2289: self.assertRaises(OSError, os.rename, src, dst) On 2013/03/11 00:45:35, vstepanov wrote: > I do not see where `src` and `dst` variables are declared Oops I didn't catch that because I have not tested on Windows yet. I do plan to test on Windows soon maybe even tonight. My Windows partition is not setup correctly yet since I got my new computer back in October. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2295: self.remove_file_or_directory(self.rename_dst_file) On 2013/03/11 00:45:35, vstepanov wrote: > I think it would be better to create the files/directories in separate methods > and call them in tests methods instead of create them in setUp method and remove > in each test (except for those that are not removed in tests methods, they can > be left in the setUp). I have been wondering if there is a better approach to all of this. According to some of the CPython Committers we have to make the test case as WET as possible and not repeat ourselves. Before I was actually creating the files/directories in the test cases but was not using a method it took a lot of code. I could make a version that does that but use methods to create the files instead then measure the line count to see which solution is WETTEST. Let me think about this.... http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode23… Lib/test/test_os.py:2326: self.assertEqual(os.path.exists(self.rename_dst_directory), True) On 2013/03/11 00:45:35, vstepanov wrote: > There are unittest.TestCase.assertTrue and unittest.TestCase.assertFalse > methods. Yes I fixed some of them with V2 but V3 now has all of them fixed. Thanks. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode24… Lib/test/test_os.py:2402: src = self.rename_src_file + "does_not_exist" On 2013/03/11 00:45:35, vstepanov wrote: > I don't see where `src` and `dst` are used. You are correct I don't need those thanks! I will post a new version soon.... http://bugs.python.org/review/16278/

1 0

Re: [docs] os.rename documentation slightly inaccurate (issue 16278)
by vitaliy.stepanov＠gmail.com March 10, 2013

March 10, 2013

some comments to the patch http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py File Lib/test/test_os.py (right): http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2209: class RenameTests(unittest.TestCase): I have some comments to this patch. I think would be better to add two separate test case RenameFileTests and RenameDirTests or something like that. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2215: self.rename_src_file = "%s_%d_tmp" % ("test_rename_src_file", All variables has prefix ``rename_`` (rename_src_file, rename_dst_file and so on), so can use them without this prefix (just src_file, dst_file ...) http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2216: os.getpid()) should not call this method everywhere, use a variable http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2217: if os.path.exists(self.rename_src_file): There is remove_file_or_directory method, use it for remove exist files/dirs. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2220: os.write(fd, b"beans\n") Really need to write many lines in a file and then split the text on the line in tests? Perhaps enough only one. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2277: if (os.path.isfile(file)): outer parentheses are unnecessary http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2289: self.assertRaises(OSError, os.rename, src, dst) I do not see where `src` and `dst` variables are declared http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode22… Lib/test/test_os.py:2295: self.remove_file_or_directory(self.rename_dst_file) I think it would be better to create the files/directories in separate methods and call them in tests methods instead of create them in setUp method and remove in each test (except for those that are not removed in tests methods, they can be left in the setUp). http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode23… Lib/test/test_os.py:2326: self.assertEqual(os.path.exists(self.rename_dst_directory), True) There are unittest.TestCase.assertTrue and unittest.TestCase.assertFalse methods. http://bugs.python.org/review/16278/diff/7565/Lib/test/test_os.py#newcode24… Lib/test/test_os.py:2402: src = self.rename_src_file + "does_not_exist" I don't see where `src` and `dst` are used. http://bugs.python.org/review/16278/

1 0

[issue8318] Deprecation of multifile inappropriate or incomplete
by Terry J. Reedy March 10, 2013

March 10, 2013

Changes by Terry J. Reedy <tjreedy(a)udel.edu>: ---------- stage: needs patch -> committed/rejected _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8318> _______________________________________

1 0

[issue8318] Deprecation of multifile inappropriate or incomplete
by Terry J. Reedy March 10, 2013

March 10, 2013

Changes by Terry J. Reedy <tjreedy(a)udel.edu>: ---------- resolution: -> out of date status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8318> _______________________________________

1 0

[issue763043] unable to specify another compiler
by Terry J. Reedy March 10, 2013

March 10, 2013

Terry J. Reedy added the comment: Is this still relevant, or should it be closed? I no 0 idea what either of you think should be changed in the docs and where, and I suspect the same would be true of any other non-disutils expert, so if a patch is needed, it should come from one you two (Matthias?). Meththias, you are not marked as having a Contributor Agreement on file. Paper forms were lost some years ago. I had to re-submit too. It is even easier now. http://www.python.org/psf/contrib/ ---------- nosy: +terry.reedy versions: -Python 3.1 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue763043> _______________________________________

1 0

In re's named group the name cannot contain unicode characters (issue 14462)
by ezio.melotti＠gmail.com March 10, 2013

March 10, 2013

The patch also needs a versionchanged in the docs to say that unicode names are supported too. http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py File Lib/test/test_re.py (right): http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode197 Lib/test/test_re.py:197: re.compile('(?P<𝔘𝔫𝔦𝔠𝔬𝔡𝔢>x)(?P=𝔘𝔫𝔦𝔠𝔬𝔡𝔢)(?(𝔘𝔫𝔦𝔠𝔬𝔡𝔢)y)') Writing non-BMP chars directly in the source is a bit risky -- some editors might not deal well with it, and in the past we had bugs with pyc files too. http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode198 Lib/test/test_re.py:198: self.assertRaises(re.error, re.compile, '(?P<©>x)') Maybe add a comment that mentions why this fails (or something like "# check that valid identifiers works" at the top). http://bugs.python.org/review/14462/diff/7181/Lib/test/test_re.py#newcode203 Lib/test/test_re.py:203: self.assertRaises(re.error, re.sub, '(?P<a>x)', r'\g<©>', 'xx') Do these tests cover all the cases you changed in re.py? http://bugs.python.org/review/14462/

1 0

[issue14489] repr() function link on the built-in function documentation is incorrect
by H Xu March 10, 2013

March 10, 2013

New submission from H Xu <xuhdev(a)gmail.com>: The `repr()` built-in function link in this page [ http://docs.python.org/library/functions.html ] should link to the built-in version of `repr()`. It should link to: http://docs.python.org/library/functions.html#repr However, it links to here: http://docs.python.org/library/repr.html#module-repr ---------- assignee: docs@python components: Documentation messages: 157462 nosy: H.Xu, docs@python priority: normal severity: normal status: open title: repr() function link on the built-in function documentation is incorrect versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue14489> _______________________________________

6 11

Re: [docs] os.rename documentation slightly inaccurate (issue 16278)
by rovitotv＠gmail.com March 10, 2013

March 10, 2013

Ezio, Thanks for the review it was excellent. I got most of them fixed and will post a new version soon. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py File Lib/test/test_os.py (right): http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode55 Lib/test/test_os.py:55: # Tests creating TESTFN and os.rename On 2013/03/04 18:15:16, ezio.melotti wrote: > I think it would be better to make a separate class for os.rename. The changes > to setUp/tearDown are only needed for the new tests, but they are executed for > all the old tests too, and that's not necessary. I agree I only put it in the FileTests class because there was a single test that already existing in that class. A new class will make it much cleaner, good suggestion. Will be implemented in next version. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode62 Lib/test/test_os.py:62: self.rename_src_file = "%s_%d_tmp" % ("test_rename_src_file", \ On 2013/03/04 18:15:16, ezio.melotti wrote: > All the \ are useless and should be removed (or possibly replaced by an extra > set of ()). I thought those were required but you are right they are not needed so I removed. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode85 Lib/test/test_os.py:85: if (os.path.exists(self.rename_dst_directory + "/file.txt")): On 2013/03/04 18:15:16, ezio.melotti wrote: > Shouldn't this use os.path.join()? > Also "/file.txt" is repeated over and over -- it would be better to use a > variable instead. I used os.path.join() and I made a variable all good suggestions. Thanks! http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode125 Lib/test/test_os.py:125: os.rmdir(self.rename_src_directory) On 2013/03/04 18:15:16, ezio.melotti wrote: > This could be rewritten as: > files = [support.TESTFN, self.rename_src_file, ...] > for file in files: > if os.path.exists(file): > os.unlink(file) > > for the dirs you can have the same 4 lines with rmdir instead, or check if they > are files or dir and use the same loop. Done.....this is a terrific way to perform the same functions but with fewer lines of code. Thank you. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode161 Lib/test/test_os.py:161: @support.cpython_only On 2013/03/04 18:15:16, ezio.melotti wrote: > Why are this cpython_only? > Does the behavior depend on the CPython implementation or on the OS and/or > underlying posix function? Nope, the original test case had this so I included it. But if you think it is ok I removed it. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode164 Lib/test/test_os.py:164: (sys.platform == 'win32') ), \ On 2013/03/04 18:15:16, ezio.melotti wrote: > All the \ should be removed, and there are also 4 sets of () that are not > necessary and could be removed as well. Ok I removed both the \ and the (). I personally think the () make code clearer. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode165 Lib/test/test_os.py:165: 'test specific to windows or linux or darwin only') On 2013/03/04 18:15:16, ezio.melotti wrote: > Is this because you only tested it on these platforms? > I would run it on other platforms too, and possibly add specific skips if they > fail there (unless of course the failure is caused by a bug that should be > fixed). > If the skip is really necessary I would create a new skip decorator and use > that, instead of repeating this over and over. I only have access to Mac OS X, Linux, and Windows but would be glad to try on other platforms if I can get access. I removed this code for now. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode167 Lib/test/test_os.py:167: if ((sys.platform == 'darwin') or (sys.platform.startswith == "linux")): On 2013/03/04 18:15:16, ezio.melotti wrote: > All the () are unnecessary and should be removed. Done....sorry about that just a personal preference. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode171 Lib/test/test_os.py:171: [b"beans", b"bacon", b"eggs", b"spam"]) On 2013/03/04 18:15:16, ezio.melotti wrote: > PEP8 says that this should either be indented as > > self.assertEqual(fobj.read().splitlines(), > [b"beans", b"bacon", b"eggs", b"spam"]) > > or as > > self.assertEqual( > fobj.read().splitlines(), > [b"beans", b"bacon", b"eggs", b"spam"]) > > http://www.python.org/dev/peps/pep-0008/#indentation Yep that is taken care of in the next version. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode185 Lib/test/test_os.py:185: os.unlink(self.rename_dst_file) # delete rename_dst_file On 2013/03/04 18:15:16, ezio.melotti wrote: > Shouldn't the setUp/tearDown already take care of this? setUp/teadDown does in most cases. But for cases when destination doesn't exist the destination file must be removed. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode369 Lib/test/test_os.py:369: self.assertRaises(OSError, os.rename, self.rename_src_file, \ On 2013/03/04 18:15:16, ezio.melotti wrote: > self.assertRaises() can be used as a context manager too, to make the code more > readable. Ummmm....I will have to research context manager. http://bugs.python.org/review/16278/diff/7518/Lib/test/test_os.py#newcode396 Lib/test/test_os.py:396: self.assertEqual(os.path.exists(self.rename_dst_directory), True) On 2013/03/04 18:15:16, ezio.melotti wrote: > self.assertTrue(os.path.exists(self.rename_dst_directory)) Done....I think the code you suggested is better thanks! http://bugs.python.org/review/16278/

1 0