Re: [Python-Dev] [Python-checkins] cpython (2.7): PDB now will properly escape backslashes in the names of modules it executes.
Hi Jason,
> http://hg.python.org/cpython/rev/f7dd5178f36a
> branch: 2.7
> user:Jason R. Coombs
> date:Thu Nov 17 18:03:24 2011 -0500
> summary:
> PDB now will properly escape backslashes in the names of modules it
> executes. Fixes #7750
> diff --git a/Lib/test/test_pdb.py b/Lib/test/test_pdb.py
> +class Tester7750(unittest.TestCase):
I think we have an unwritten rule that test class and method names
should tell something about what they test. (We do have things like
TestWeirdBugs and test_12345, but I don’t think it’s a useful pattern to
follow :) Not a big deal anyway.
> +# if the filename has something that resolves to a python
> +# escape character (such as \t), it will fail
> +test_fn = '.\\test7750.py'
> +
> +msg = "issue7750 only applies when os.sep is a backslash"
> +@unittest.skipUnless(os.path.sep == '\\', msg)
> +def test_issue7750(self):
> +with open(self.test_fn, 'w') as f:
> +f.write('print("hello world")')
> +cmd = [sys.executable, '-m', 'pdb', self.test_fn,]
> +proc = subprocess.Popen(cmd,
> +stdout=subprocess.PIPE,
> +stdin=subprocess.PIPE,
> +stderr=subprocess.STDOUT,
> +)
> +stdout, stderr = proc.communicate('quit\n')
> +self.assertNotIn('IOError', stdout, "pdb munged the filename")
Why not check for assertIn(filename, stdout)? (In other words, check
for intended behavior rather than implementation of the erstwhile bug.)
BTW, I’ve just tested that giving a message argument to assertNotIn (the
third argument), unittest still displays the other arguments to allow
for easier debugging. I didn’t know that, it’s cool!
> +def tearDown(self):
> +if os.path.isfile(self.test_fn):
> +os.remove(self.test_fn)
In my own tests, I’ve become fond of using “self.addCleanup(os.remove,
filename)”: It’s shorter that a tearDown and is right there on the line
that follows or precedes the file creation.
> if __name__ == '__main__':
> test_main()
> +unittest.main()
This looks strange.
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] how to find the file path to an extension module at init time?
Stefan Behnel, 15.11.2011 09:01: "Martin v. Löwis", 15.11.2011 01:33: An approach similar to _Py_PackageContext should be possible. Yes, and a "_Py_ModuleImportContext" would be rather trivial to do. Could that go into 3.3? If somebody contributes a patch: sure. Ok, cool. Patch(es) uploaded to the bug tracker. http://bugs.python.org/issue13429 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] _PyImport_FindExtensionObject() does not set _Py_PackageContext
Stefan Behnel, 13.11.2011 19:48: I noticed that _PyImport_FindExtensionObject() in Python/import.c does not set _Py_PackageContext when it calls the module init function for module reinitialisation. However, PyModule_Create2() still uses that variable to figure out the fully qualified module name. Was this intentionally left out or is it just an oversight? Assuming it was an oversight, I attached a patch to ticket 13429 on the bug tracker. http://bugs.python.org/issue13429 Stefan ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-11-11 - 2011-11-18) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3115 ( +5) closed 22097 (+41) total 25212 (+46) Open issues with patches: 1330 Issues opened (32) == #12246: Support installation when running from an uninstalled Python http://bugs.python.org/issue12246 reopened by eric.araujo #13193: test_packaging and test_distutils failures http://bugs.python.org/issue13193 reopened by eric.araujo #13384: Unnecessary __future__ import in random module http://bugs.python.org/issue13384 reopened by rhettinger #13386: Document documentation conventions for optional args http://bugs.python.org/issue13386 opened by ezio.melotti #13390: Hunt memory allocations in addition to reference leaks http://bugs.python.org/issue13390 opened by pitrou #13393: Improve BufferedReader.read1() http://bugs.python.org/issue13393 opened by pitrou #13394: Patch to increase aifc lib test coverage with couple of minor http://bugs.python.org/issue13394 opened by Oleg.Plakhotnyuk #13396: new method random.getrandbytes() http://bugs.python.org/issue13396 opened by amaury.forgeotdarc #13397: Option for XMLRPC clients to automatically transform Fault exc http://bugs.python.org/issue13397 opened by rhettinger #13398: _cursesmodule does not build, doesn't find Python.h on Solaris http://bugs.python.org/issue13398 opened by automatthias #13399: Don't print traceback for unrecognized actions, commands and o http://bugs.python.org/issue13399 opened by Arfrever #13400: packaging: build command should accept --compile, --no-compile http://bugs.python.org/issue13400 opened by Arfrever #13401: test_argparse fails with root permissions http://bugs.python.org/issue13401 opened by Arfrever #13402: Document absoluteness of sys.executable http://bugs.python.org/issue13402 opened by eric.araujo #13403: Option for XMLPRC Server to support HTTPS http://bugs.python.org/issue13403 opened by rhettinger #13404: Add support for system.methodSignature() to XMLRPC Server http://bugs.python.org/issue13404 opened by rhettinger #13405: Add DTrace probes http://bugs.python.org/issue13405 opened by jcea #13407: tarfile.getnames misses members again http://bugs.python.org/issue13407 opened by sengels #13408: Rename packaging.resources back to datafiles http://bugs.python.org/issue13408 opened by eric.araujo #13410: String formatting bug in interactive mode http://bugs.python.org/issue13410 opened by jayanth #13411: Hashable memoryviews http://bugs.python.org/issue13411 opened by pitrou #13412: Symbolic links omitted by os.listdir on some systems http://bugs.python.org/issue13412 opened by alexreg #13413: time.daylight incorrect behavior in linux glibc http://bugs.python.org/issue13413 opened by dimonb #13414: test_strftime failed on OpenBSD http://bugs.python.org/issue13414 opened by rpointel #13415: del os.environ[key] ignores errors http://bugs.python.org/issue13415 opened by haypo #13417: faster utf-8 decoding http://bugs.python.org/issue13417 opened by pitrou #13418: Embedded Python memory leak http://bugs.python.org/issue13418 opened by Asesh #13420: newer() function in dep_util.py discard changes in the same se http://bugs.python.org/issue13420 opened by d.amian #13421: PyCFunction_* are not documented anywhere http://bugs.python.org/issue13421 opened by jcea #13424: Add examples for openâs new opener argument http://bugs.python.org/issue13424 opened by eric.araujo #13425: http.client.HTTPMessage.getallmatchingheaders() always returns http://bugs.python.org/issue13425 opened by stachjankowski #13429: provide __file__ to extension init function http://bugs.python.org/issue13429 opened by scoder Most recent 15 issues with no replies (15) == #13421: PyCFunction_* are not documented anywhere http://bugs.python.org/issue13421 #13417: faster utf-8 decoding http://bugs.python.org/issue13417 #13413: time.daylight incorrect behavior in linux glibc http://bugs.python.org/issue13413 #13408: Rename packaging.resources back to datafiles http://bugs.python.org/issue13408 #13403: Option for XMLPRC Server to support HTTPS http://bugs.python.org/issue13403 #13402: Document absoluteness of sys.executable http://bugs.python.org/issue13402 #13401: test_argparse fails with root permissions http://bugs.python.org/issue13401 #13400: packaging: build command should accept --compile, --no-compile http://bugs.python.org/issue13400 #13397: Option for XMLRPC clients to automatically transform Fault exc http://bugs.python.org/issue13397 #13372: handle_close called twice in poll2 http://bugs.python.org/issue13372 #13369: timeout with exit code 0 while re-running failed tests http://bugs.python.org/issue13369 #13354: tcpserver should document non-threaded long-living connections http:
[Python-Dev] Committing PEP 3155
Hello, I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it? (*) "Qualified name for classes and functions" http://www.python.org/dev/peps/pep-3155/ Thank you Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote: >I haven't seen any strong objections, so I would like to go ahead and >commit PEP 3155 (*) soon. Is anyone against it? > >(*) "Qualified name for classes and functions" >http://www.python.org/dev/peps/pep-3155/ I'm still not crazy about the attribute name, although I appreciate you including the discussion in the PEP. Have you identified a BDFOP that might be able to pronounce on the choice? Or perhaps Guido would like to weigh in? The PEP says that the qualified name deliberately does not include the module name, but it doesn't explain why. I think it should (explain why). I'd like the PEP to explain why this is a better solution than re-establishing introspectability that was available through unbound methods. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
On Fri, 18 Nov 2011 18:15:28 -0500 Barry Warsaw wrote: > On Nov 18, 2011, at 09:14 PM, Antoine Pitrou wrote: > > >I haven't seen any strong objections, so I would like to go ahead and > >commit PEP 3155 (*) soon. Is anyone against it? > > > >(*) "Qualified name for classes and functions" > >http://www.python.org/dev/peps/pep-3155/ > > I'm still not crazy about the attribute name, although I appreciate you > including the discussion in the PEP. Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which may seem weird at first sight :) > Have you identified a BDFOP that might > be able to pronounce on the choice? No. Perhaps I was irenic in hoping that no opposition == no need to get an official pronouncement :-) > The PEP says that the qualified name deliberately does not include the module > name, but it doesn't explain why. I think it should (explain why). > > I'd like the PEP to explain why this is a better solution than re-establishing > introspectability that was available through unbound methods. I've added explanations for these two points. Do they satisfy your expectations? cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
On Nov 19, 2011, at 12:54 AM, Antoine Pitrou wrote: >I've added explanations for these two points. Do they satisfy your >expectations? Yep, thanks. -Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
I haven't seen any strong objections, so I would like to go ahead and commit PEP 3155 (*) soon. Is anyone against it? I'm not against it, but I have some questions. Does you a working implementing? Do you have a patch for issue #9276 using __qualname__? Maybe not a fully working patch, but a proof-of-concept? Could you add examples on instances? I suppose that it gives the same result than classes: C.__qualname__ == C().__qualname__ C.f.__qualname__ == C().f.__qualname__ Le 19/11/2011 00:15, Barry Warsaw a écrit : > I'd like the PEP to explain why this is a better solution than > re-establishing introspectability that was available through > unbound methods. __qualname__ works also on nested functions. Is it a new feature? Or was it already possible in Python 2 to compute the qualified name? Victor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Committing PEP 3155
19.11.11 01:54, Antoine Pitrou написав(ла): Well, the other propositions still seem worse to me. "Qualified" is reasonably accurate, and "qualname" is fairly short and convenient (I would hate to type "__qualifiedname__" or "__qualified_name__" in full). In the same vein, we have __repr__ which may seem weird at first sight :) What about __reprname__? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
