[issue15502] Meta path finders and path entry finders are different, but share an ABC
Eric Snow added the comment: Yeah, but right now the API of importlib.abc.Finder is strictly find_module(name, path=None). I would expect that to remain the same for MetaPathFinder (bikeshedding aside :). So what would be left in importlib.abc.Finder if the ultimate plan is that PathEntryHandler would not implement find_module()? Would it simply be an alias to MetaPathFinder? I agree with the plan, but wonder if a common base class is warranted. The connection to finder in PEP 302 is nice, but rather superfluous in a practical context. Having a Finder class is necessary at this point for backward-compatibility, but I don't see how it is different from the more appropriately named MetaPathFinder. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Eric Snow added the comment: For instance, http://buildbot.python.org/all/builders/x86%20XP-4%203.x/builds/7214/steps/test/logs/stdio 4 cases of ImportError: No module named '_parent_foo'. Failing on import _parent_foo.bar and from _parent_foo import bar. Unfortunately I don't have an XP system set up on which to debug this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15481] Add exec_module() as part of the import loader API
Eric Snow added the comment: This isn't going to be worth it. -- resolution: - rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15481 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
STINNER Victor added the comment: I noticed when building with VC++ 2010 Express on the PGI/PGO builds that it warns about PGO not being available. Even if PGO is not available, wrap_binaryfunc() and wrap_binaryfunc_l() functions get the same address when Python is compiled in PGUpdate mode. (I tried Visual C++ 2010 Express). The issue was seen at least with the following versions: Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32 Python 3.2 (which version exactly?) Python 3.3b.01, MSVC v16.00 64 bits (AMD 64) on win32 So the issue was also reproduced with old Python versions compiled with Visual C++ 2008, and I'm not sure that the ICF optimization is only enabled in Profile-Guided (PG*) modes. If we choose to change Visual Studio options instead of changing the mode, we may also try /Gy- option: http://msdn.microsoft.com/en-us/library/xsa71f43.aspx -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment:
I'm looking at the docs. Started with the HOWTO (Doc/howto/ipaddress.rst)
This example:
net4 = ipaddress.ip_network('192.0.2.0/24')
for x in net4.iterhosts():
print(x)
Seems to be wrong:
...
Traceback (most recent call last):
File stdin, line 1, in module
AttributeError: 'IPv4Network' object has no attribute 'iterhosts'
I wonder if it simply needs to iterate the net4 object itself.
--
nosy: +eli.bendersky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14814
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: P.S. I intend to prepare patch(es) eventually, but I will document the problems I find here, in case anyone is interested to discuss. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Ah, probably hosts() replaced iterhosts() -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Attaching a patch for the howto -- Added file: http://bugs.python.org/file26612/ipaddr_howto.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Martin v. Löwis added the comment: Do we even use PGO to the fullest extent? Does someone actually build an instrumented Python, run training inputs on it, and then rebuild with the training data to take advantage of the profile-guided optimizations? Yes, I do, on every release of Python. The test set includes at the minimum Tools\pybench\pybench.py -n1 -C1 --with-gc. I used to also include Lib\test\regrtest.py. Now, some recently added tests have slowed this down so much that this is not feasible anymore in PGI mode. This issue wouldn't have been reported in the first place if this feature wasn't used; see also msg107124. I don't mind just not doing it anymore; it speeds up the release process. If not, then I doubt PGO is buying us anything anyway. It was originally added because people reported measurable speedups when profile-guided optimization is used, for VS 2008. I noticed when building with VC++ 2010 Express on the PGI/PGO builds that it warns about PGO not being available. I don't know what version we build our Python release bits with. I do, of course, have at least a professional edition of Visual Studio to make the Python releases available from www.python.org. More specifically, my VS 2008 installation is Professional; my VS 2010 installation is Ultimate. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
New submission from Stefan Krah: _decimal does not build in PGUpdate mode. I didn't notice this because I've always used the Release mode so far: msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64 msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=x64 C:\Users\stefan\pydev\cpython\PCbuild\pcbuild.sln (default target) (1) - C:\Users\stefan\pydev\cpython\PCbuild\_decimal.vcxproj (default target) (10) - (Link target) - LINK : fatal error LNK1181: cannot open input file 'C:\Users\stefan\pydev\cpython\PCbuild\\amd64\python33.lib' [C:\Use rs\stefan\pydev\cpython\PCbuild\_decimal.vcxproj] -- components: Extension Modules messages: 166970 nosy: brian.curtin, loewis, skrah priority: release blocker severity: normal stage: needs patch status: open title: _decimal does not build in PGUpdate mode type: compile error versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Stefan Krah added the comment: Martin v. L??wis rep...@bugs.python.org wrote: If not, then I doubt PGO is buying us anything anyway. It was originally added because people reported measurable speedups when profile-guided optimization is used, for VS 2008. For libmpdec/64-bit I've measured huge speedups in the order of 50% (with training data). This led me to believe that the main optimizations for x64 are only available with PGO, perhaps as a distinguishing feature from the Express versions. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: FWIW I would prefer this HOWTO to be part of the document itself. Splitting a document to two parts and keeping them separated is problematic exactly for the same reasons as external documentation in general - it can be forgotten when things get updated. HOWTOs are good to discuss concepts that don't pertain to a specific modules, and so there is no other natural place to place them. Tutorials that only discuss a single module belong in its doc page together with the reference - I think there are plenty of examples in the stdlib docs where this is the case. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15507] test_subprocess assumes SIGINT is not being ignored.
Richard Oudkerk added the comment: Couldn't the preexec_fn argument of Popen be used instead? -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: The docs don't mention that addresses can also be packed in bytes -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Nick Coghlan added the comment: No, the HOWTO should be separate. Having them in the same document makes for something that is worse as both a tutorial and as an API reference (just look at argparse). Yes, that means there are three places to update (code, reference, tutorial). There are three places to update regardless - the only question is whether two of those places are jammed awkwardly into the same file. Handling this will hopefully become more natural as the howto/tutorial section of the docs grows larger. The main problem with the ipadddress docs at the moment is extracting the docstrings for the methods and including them in the reference docs in a sane way (i.e. without excessive duplication of material, as Terry and I discussed above). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Martin v. Löwis added the comment: I can't reproduce this. It builds fine for me. Are you sure you did PGInstrument before? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Martin v. Löwis added the comment: Also, can you try building from the GUI, rather than from the command line? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Changes by Martin v. Löwis mar...@v.loewis.de: -- priority: release blocker - normal ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15512] Correct __sizeof__ support for parser
New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for ST objects in parser module. -- components: Interpreter Core, Library (Lib) files: parser_sizeof.patch keywords: patch messages: 166978 nosy: benjamin.peterson, storchaka priority: normal severity: normal status: open title: Correct __sizeof__ support for parser type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26613/parser_sizeof.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15512] Correct __sizeof__ support for parser
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file26614/parser_sizeof-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15512 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15513] Correct __sizeof__ support for pickle
New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for Pickler and Unpickler in pickler module. -- components: Library (Lib) files: pickle_sizeof-3.3.patch keywords: patch messages: 166979 nosy: alexandre.vassalotti, pitrou, storchaka priority: normal severity: normal status: open title: Correct __sizeof__ support for pickle type: behavior versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file26615/pickle_sizeof-3.3.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15513] Correct __sizeof__ support for pickle
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file26616/pickle_sizeof-3.2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15513] Correct __sizeof__ support for pickle
Changes by Serhiy Storchaka storch...@gmail.com: Added file: http://bugs.python.org/file26617/pickle_sizeof-2.7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Stefan Krah added the comment: _decimal-pgo.diff sort of solves the problem. It might be a good idea to regenerate _decimal.vcproj using the GUI. I've created it in true Unix fashion by modifying an existing vcproj... I'm always building using the command line. If you say that the GUI build works, I trust you of course. :) -- keywords: +patch Added file: http://bugs.python.org/file26618/_decimal-pgo.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15514] Correct __sizeof__ support for cpu_set
New submission from Serhiy Storchaka: Here is a patch that implements correct __sizeof__ for cpu_set class in os module. This is 3.3-only issue. -- components: Library (Lib) files: cpu_set_sizeof.patch keywords: patch messages: 166981 nosy: loewis, storchaka priority: normal severity: normal status: open title: Correct __sizeof__ support for cpu_set type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file26619/cpu_set_sizeof.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15514 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15507] test_subprocess assumes SIGINT is not being ignored.
Richard Oudkerk added the comment: Couldn't the preexec_fn argument of Popen be used instead? Actually, since Python 3.2 you can just use restore_signals=True. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Changes by Stefan Krah stefan-use...@bytereef.org: -- keywords: +needs review -patch stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Stefan Krah added the comment: Using MSVC Professional 2010 and the GUI, I'm getting the same error: 1) Select PGInstrument|x64. Clean the solution. 2) Select PGUpdate|x64. Clean the solution. 3) Select PGInstrument|x64. Build the solution. 4) Select PGUpdate|x64. Build the solution. - error. Note that PCbuild\amd64\python33.lib is not present, i.e. I did not build Release|x64. This isn't a dependency I hope? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Serhiy Storchaka added the comment: If this issue is not yet closed, here are a patch with few edits: using int.to_bytes/from_bytes instead struct.pack/unpack and using enumerate() instead range(len()). -- Added file: http://bugs.python.org/file26620/ipaddress-modernize.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
Hynek Schlawack added the comment: So, IMHO if someone calls os.makedirs with a mode != 0o777, they expect to have the directories having those modes afterward. So raising no error if they exist and have the wrong mode would be a plain bug. Python 3.3 already has a helpful error message: FileExistsError: [Errno 17] File exists (mode 777 != expected mode 755): 'foo' and it also handles the sticky issue gracefully: http://hg.python.org/cpython/file/3a08d766eee3/Lib/os.py#l270 So this are an non-issues for 3.3. I'm not sure if it's severe enough to be back ported to 3.2. So there’s only one thing left: the docs are wrong and should be fixed about exist_ok's behavior for both 3.2 3.3. That said, I see the rationale for fixing the permissions but we can't just change os.makedirs at this point. So I'd propose to add a fix_permissions bool flag that would allow the no matter what the state is now, I want dir x with permissions y, do whatever is necessary workflow. Opinions? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: I disagree about the HOWTO vs. doc thing, but I don't see it as a major issue so I won't dwell on it. I'm now in the process of throwing together a patch for the reference doc - also bundling the address objects together, the network objects together, etc. BTW I saw there was disagreement about whether packed bytes should be accepted as addresses. ATM they are in the code, so should this be documented? I want to provide a precise documentation of what exactly is a valid address. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] VS 2010 Professional: _decimal does not build in PGUpdate mode
Stefan Krah added the comment: Ok, Microsoft dropped PGO support in VS 2010 Professional. In VS 2008 *Professional* it was present. So I'll jump through the hoops of the marketing department and install Ultimate. The patch is of limited value then: _decimal does build in the Professional edition using PGUpdate, but using that mode is probably pointless. -- title: _decimal does not build in PGUpdate mode - VS 2010 Professional: _decimal does not build in PGUpdate mode ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15486] Standardised mechanism for stripping importlib frames from tracebacks
Roundup Robot added the comment: New changeset 62033490ca0f by Nick Coghlan in branch 'default': Close #15486: Simplify the mechanism used to remove importlib frames from tracebacks when they just introduce irrelevant noise http://hg.python.org/cpython/rev/62033490ca0f -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Roundup Robot added the comment: New changeset 8a0eb395e725 by Nick Coghlan in branch 'default': Issue #15425: Don't rely on the assumption that the current working directory is on sys.path (this will hopefully appease the XP buildbots) http://hg.python.org/cpython/rev/8a0eb395e725 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Changes by Nick Coghlan ncogh...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Alright, attaching an attempt at improving the reference docs. This only handles the address objects for now: 1. Grouping address objects together, network objects together, interface objects together 2. Explain that everything IPv4Address exposes is also exposed by IPv6Address 3. Document v4's attributes in a generic manner 4. Document v6's specific attributes 5. Document operators 6. Precisely define the address format(s) accepted by the constructors If this looks good to folks, I can commit and then proceed to similarly explaining the network and interface objects. -- Added file: http://bugs.python.org/file26621/ipaddr_refdoc.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15498] Eliminate the use of deprecated OS X APIs in getpath.c
Ronald Oussoren added the comment: Removing the dependency on NSLookupAndBindSymbol (and related APIs) is easier than I expected. The attached patch (issue15498-v1.txt) uses dladdr to get symbol information for Py_Initialize and that information includes the path for the library where that symbol is located (that is the framework). The patch has seen only light testing, in particular: I've verified that the library path has the expected value, but haven't run the full test suite set. TODO: - Run test full test suite with a framework build (both before and after installing) - Likewise for a regular unix build - Likewise for a regular unix build with --enable-shared This patch should work on OSX 10.4 or later, and may also work on OSX 10.3, the manpage for dladdr is not entirely clear on whether or not the symbol is available in libSystem on OSX 10.3. -- keywords: +needs review stage: needs patch - patch review Added file: http://bugs.python.org/file26622/issue15498-v1.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15498 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13759] Python 3.2.2 Mac installer version doesn't accept multibyte character in interactive mode
Ronald Oussoren added the comment: To reproduce this issue you could use the Unicode Hex Input input source (enable this in the Language Text prefpane, switch between sources either using CMD-space or the menu bar icon). I can あ by keeping ALT pressed and typing 3042. This works fine with a self-built version of 3.2 (tip of tree), I haven't tested the 3.2 binary installer (yet). -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13759 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11486] Add option to not install into /Applications
Changes by Ronald Oussoren ronaldousso...@mac.com: -- keywords: +needs review versions: +Python 3.4 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13371] Some Carbon extensions don't build on OSX 10.7
Ronald Oussoren added the comment: Patch is already applied (ages ago), forgot to close this issue. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13371 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Nick Coghlan added the comment: Thanks Eli, that looks like a great start to me. And yeah, the separate vs integrated tutorial argument is an ongoing one that isn't going to be resolved by this issue :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Stefan Krah added the comment: Well, I have Ultimate now and encounter the same problem. Also, when I start PCbuild\x64-pgi\python.exe it exits immediately without displaying an error. The PC\VS9.0 PGUpdate build works fine. -- title: VS 2010 Professional: _decimal does not build in PGUpdate mode - _decimal does not build in PGUpdate mode ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12507] tkSimpleDialog problem
Ronald Oussoren added the comment: Closing because this issue is a bug in Tk, not a bug in Python. -- resolution: - wont fix stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Brett Cannon added the comment: While saying default path importer vs. meta path finder somewhat muddles the term importer, it definitely gets the point across that PathFinder does a lot more than any other default meta path finder. While _we_ might know that import does nothing more than call a method on sys.meta_path and has no concept of sys.path and friends, most people will consider the default path importer as part of import's semantics and thus not make the distinction. IOW I like Nick's suggestion. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Martin v. Löwis added the comment: Make sure you clean all build directories; then rebuild. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: On Jul 29, 2012, at 05:10 AM, Nick Coghlan wrote: I would title the new section Import system rather than Import machinery as it is meant to be a specification documentation rather than an implementation description. Import system it is. The statement that from X import A only performs a single import lookup is incorrect. The trick is that if A, B or C refers to a submodule of X then it will be imported. I think I see where you and Eric are coming from on this. Actually, I don't think I changed the existing text in this regard, but probably once I refactored out all the details, it reads in such a way as to be confusing. I've tweaked the text under the import statement to hopefully be more clear. It could probably still use improvement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Martin v. Löwis added the comment: clean = manually delete, e.g. from explorer -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Thanks Nick. I've addressed your review comments and will be pushing the doc update. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Roundup Robot added the comment: New changeset 586eb57e06ba by Eli Bendersky in branch 'default': Issue #14814: reorganize ipaddress documentation and document all attributes of IPv[46]Address objects http://hg.python.org/cpython/rev/586eb57e06ba -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Roundup Robot added the comment: New changeset 07ddf5ecaafa by Eli Bendersky in branch 'default': Issue #14814: fix some typos in howto/ipaddress.rst http://hg.python.org/cpython/rev/07ddf5ecaafa -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: By the way, Nick, was not this module intended to be introduced as provisional in 3.3? At least PEP 411 lists it as one of the candidates. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14803] Add feature to allow code execution prior to __main__ invocation
Chris Jerdonek added the comment: However, the -C option doesn't cover the case of *implicit* invocation of subprocesses. This is where the PYTHONRUNFIRST suggestion comes in Would a more general solution than PYTHONRUNFIRST be something like a suitably named PYTHONRUNINSTEAD? This would be an arbitrary script to run in place of python any time python was invoked. Alternatively (and less powerfully), it could be a default set of command options to pass to the Python executable. Both of these seem more general than PYTHONRUNFIRST because the 'runas' command could itself be `python -C $PYTHONRUNFIRST ` unless -E is specified, then -C $PYTHONRUNFIRST would be implied. To be honest, I *don't* think this latter capability should be built into the core implementation so that it doesn't inadvertently affect invocation of other applications (like hg) It seems what you're saying is that you'd want PYTHONRUNFIRST to run only in special situations, rather than as the default. Is there a sense then in which a functionality inverse to -E could be provided? The idea would be that, when running Python, you could somehow instruct that an option like PYTHONRUN* would take effect only for the subprocesses spawned by the main process you're invoking (kind of like a context manager for the invocation of Python itself)? The advantage of this approach would be that a special PYTHONRUNFIRST setting wouldn't take effect unless you explicitly say so. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Eric Snow added the comment: Part of the problem with the import nomenclature is that PEP 302 doesn't really nail it down and mixes the terms up a bit. This is understandable considering it broken ground in some regard. However, at this point we have a more comfortable relationship with the import system. Would it be feasible to lightly update PEP 302 to have a more concrete and consistent use of import terminology? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15511] _decimal does not build in PGUpdate mode
Stefan Krah added the comment: Building from a fresh tree enables successful launching of PCbuild\x64-pgi\python.exe, but _decimal is still not built. I literally ran the following commands, so anyone can paste them into a command window and see for themselves: # cpython is a pristine clone hg clone cpython cpython-test cd cpython-test C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\vcvarsall.bat x64 msbuild PCbuild\pcbuild.sln /p:Configuration=PGInstrument /p:Platform=x64 msbuild PCbuild\pcbuild.sln /p:Configuration=PGUpdate /p:Platform=x64 C:\Users\stefan\pydev\cpython-test\PCbuild\_decimal.vcxproj (default target) (10) - (Link target) - LINK : fatal error LNK1181: cannot open input file 'C:\Users\stefan\pydev\cpython-test\PCbuild\\amd64\python33. lib' [C:\Users\stefan\pydev\cpython-test\PCbuild\_decimal.vcxproj] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15511 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: On Jul 29, 2012, at 06:09 AM, Nick Coghlan wrote: runpy, pkgutil, et al should all get See Also links at the top pointing to the new import system section. I've put an XXX in the import.rst file for this, but I probably won't get to adding all the cross references. Others can take that on once this lands. Opening section should refer to importlib.import_module(). Any mentions of __import__ should point out that its API is designed for the convenience of the interpreter, and thus it's a pain to use directly. However, we should also document explicitly that, unlike the import statement and calling __import__ directly, importlib.import_module will ignore any module level replacements of __import__. Replacing builtins.__import__ won't reliably override the entire import system (due to module level __import__ definitions, most notably importlib.__import__) and other tools that work with the process global import state directly (e.g. pkgutil, runpy). While I've added a mention of import_module() in several places, I don't think the above detail is appropriate for the introduction. I don't want to overload folks with all those details before they understand the basics of Python's import model. I would much rather add a section that goes into more detail about coarsely overriding the import system, and there we can discuss replacing built-in __import__() along with its implications and caveats, including any behavior changes in Python 3.3 with the adoption of importlib. I probably won't get to that so feel free to add such a section later. Since we have the privilege of defining *the* standard terminology for old-style packages, I suggest we use the term initialised packages (since having an __init__.py is what makes them special). We should also note explicitly that an initialised package can also behave as a namespace package, by setting __path__ appropriately in __init__.py I don't like the term initialized package (even with the Americanized spelling :), because the term initialized means set to the value or put in the condition appropriate to the start of an operation, which clearly refers to both types of packages. What about concrete package? In a sense, namespace packages are virtual, so the opposite of that would be concrete. OTOH, while regular package may still not be the right term, it might be good enough. The bike shed is already looking pretty tie-died. Finally, I think this section needs to explicitly define the terms *import path* and *path entry*. The meta path docs later refer to find_module() accepting a module name and path, and the reader could be forgiven for thinking that meant a filesystem path, when it is actually an import path (which is a sequence of path entries, which may themselves by filesystem paths). This is getting somewhere. I like using the term path importer for the thing that PathFinder is. (path finder doesn't quite do it for me, but maybe I'm clouded by same term used as a car model. ;) What we have are several default finders, one that knows how to locate frozen modules, one that knows how to locate built-in modules, and one that knows how to search an import path (which consists of path entries). This latter finder is the path importer and it has further extensibility so that new types of path entries can be used. A path entry is a location to search for modules, and sequences of path entries exist on import paths. When a search occurs, typically the import path is taken from sys.path, but for subpackages, it is taken from the __path__ attribute of its parent package. This seems to make for much better reading, and while I've worded it differently to fit better in the flow of the documentation, it's terminology that feels more right to me. Thanks! -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Stefan Krah added the comment: Here's a patch based on the analysis. All test cases given here now raise TypeError. -- keywords: +patch Added file: http://bugs.python.org/file26623/issue8847.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Serhiy Storchaka added the comment: Do I understand correctly that for each Python subobject must be one of the following: 1) or it is visited in tp_traverse; 2) or it is accounted in __sizeof__ together with all its subobjects (if they cannot leak out)? PyAccu can contains not only Unicode objects, but at least an instance of a Unicode subtype, which can has a reference to StringIO object, creating a cycle. Does this mean that PyAccu should be visited in tp_traverse and not be accounted in __sizeof__? Or should we tighten the control and ensure that PyAccu contains only exact Unicode objects? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Ronald Oussoren added the comment: MacOSX provides functionality simular to os.startfile in the LaunchServices framework. I've tried to prototype a startfile implementation using this framework, (see issue3177-os_startfile_macosx.txt) but I'm not too happy about it because the APIs don't actually work as expected. In particular: * The patch implements open (default), edit, print and explore actions. * open and explore work fine * edit does not work as I'd expect because the function used to retrieve the default editor for a file returns the default application that can open the file, not necessarily one that claims to be an editor for the file-type. As an example, 'os.startfile(file.html, edit)' starts Safari instead of an editor. * print works for some file type, but not others (depending on whether or not the target application implements the required AppleScript API) * execute is untested, I haven't found an application yet that claims this role. Other notes: * This patch links Python with the ApplicationServices framework (which contains the LaunchServices framework) * Because the API uses Apple's application frameworks users might get annoying crashes when calling this function in a subprocess. * The code attached code is a prototype, it should be correct w.r.t. resource management, but isn't fully baked yet. One example of that is the use of a generic RuntimeError exception to signal problems, others are the lack of documentation and tests. -- nosy: +ronaldoussoren Added file: http://bugs.python.org/file26624/issue3177-os_startfile_macosx.txt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3177 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10812] Add some posix functions
Ronald Oussoren added the comment: msg126598 says that waitid is broken on MacOSX. In what way it is broken? The code is currently disabled for OSX without any indication why this is so, that makes it hard to know how to test if new OSX releases (like the just released OSX 10.8) fix waitid. -- nosy: +ronaldoussoren ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Eric Snow added the comment: Looks like both XP buildbots are happy now. (one is failing, but not for test_import). -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15425] Another strange Tracebacks with importlib
Changes by Eric Snow ericsnowcurren...@gmail.com: -- status: open - pending ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15425 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15507] test_subprocess assumes SIGINT is not being ignored.
Thomas Wouters added the comment: No, using preexec_fn leaves all kinds of races when mixing threads and processes (which is a bad idea, but people still sometimes do.) And no, restore_signals doesn't fix this; restore_signals only resets the signals the *Python interpreter itself* ignored: SIGFPE, SIGXFZ and SIGFSZ (and it defaults to True anyway.) It doesn't affect other signals at all, even if Python code ignored them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10812] Add some posix functions
Ronald Oussoren added the comment: To elaborate: when I remove the !defined(__APPLE__) tests from posixmodule.c test_posix passes on OSX 10.8, including test_waitid. I have no idea if this means that waitid is no longer broken in OSX 10.8 or that test_posix doesn't trigger the issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10812] Add some posix functions
Ross Lagerwall added the comment: I can't actually remember why I disabled waitid for OS X - that was message was rather a long time ago :-( Unfortunately, I don't currently have access to an OS X machine to test it. A google search shows the following comment in the v8 javascript engine: // We're disabling usage of waitid in Mac OS X because it doens't work for us: // a parent process hangs on waiting while a child process is already a zombie. // See http://code.google.com/p/v8/issues/detail?id=401. Do you have access to test an older release like Leopard? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Jesús Cea Avión added the comment: I think this is a bug. Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-) I am worried about changing a behaviour that somebody is depending of. Opinions? Adding a couple of persons I think that could have an opinion about this. -- nosy: +gward, jcea, twouters versions: +Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9803] IDLE closes with save while breakpoint open
Roundup Robot added the comment: New changeset 47536beb7453 by Andrew Svetlov in branch '3.2': Issue #9803: Don't close IDLE on saving if breakpoint is open. http://hg.python.org/cpython/rev/47536beb7453 New changeset 28c935ded243 by Andrew Svetlov in branch 'default': Issue #9803: Don't close IDLE on saving if breakpoint is open. http://hg.python.org/cpython/rev/28c935ded243 New changeset 8f1a8e80f330 by Andrew Svetlov in branch '2.7': Issue #9803: Don't close IDLE on saving if breakpoint is open. http://hg.python.org/cpython/rev/8f1a8e80f330 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9803] IDLE closes with save while breakpoint open
Andrew Svetlov added the comment: Thanks, Roger! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9803 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Chris Jerdonek added the comment: Could you possibly write a patch for 2.7, 3.2 and 3.3?. With a test :-) I would be happy to write a patch with tests (I think there may be a few edge cases we would want to test here). Should be ready within the next one or two days. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10812] Add some posix functions
Ronald Oussoren added the comment: I have VMs with earlier versions of OSX (at least 10.5 and 10.6). I cannot run those right now because they use enough resources to interfere with other activities. I'll try to test later this week. BTW. I'd prefer to make waitid available on OSX unless it is totally non-functional. I'm not convinced that the Google problem is a good enough reason to avoid exposing the function. If it is disabled there should be a clear description of why that is, preferable in the form of a (configure) test. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15454] Allow dircmp.report() output stream to be customized
Chris Calloway added the comment: At the PyOhio sprints, I noticed this issue and found it interesting for low hanging fruit. First I went to make tests for this enhancement, only to find that report(), report_partial_closure(), and report_full_closure did not already have tests. In adding tests for these methods, I also found that dircmp is only tested for one directory level, leaving out coverage for a pretty wide swath of dircmp. The first patch I'm submitting here is just for the report methods for the level of dircmp testing which already exists. A subsequent patch will test the report methods a couple of directory levels deep to get full coverage for report_full_closure(). Even if this enhancement is not accepted, the report methods do need tests. I'm putting this patch here in advance of any other work to get feedback on the flavor of tests I have given the report methods on the existing one directory level of dircmp testing before proceeding with any deeper testing. The tests in this patch all pass with the existing filecmp code without adding any significant execution time to test_filecmp. Any deeper testing of dircmp will also have to not be necessarily comprehensive, as the permutations of test inputs start to become too time-consuming. setUp and tearDown may also need some refactoring for deeper testing. Should adding tests for the report methods be a separate issue from this enhancement? -- keywords: +patch Added file: http://bugs.python.org/file26625/issue-15454-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15454 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14814] Implement PEP 3144 (the ipaddress module)
Eli Bendersky added the comment: Attaching part 1 of the patch for documenting the network objects. Contains general introduction, detailed documentation of constructors and all attributes. Left to document: methods, operations (like iterating, in, comparison operators) -- Added file: http://bugs.python.org/file26626/ipaddr_refdoc_network.1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
New submission from Caleb Rouleau: Version info: 2.7.1 (r271:86832, Feb 7 2011, 11:33:02) [MSC v.1500 64 bit (AMD64)] The program included never prints done because it never returns from re.match(). -- Caleb Rouleau -- components: Regular Expressions files: RegexBug.py messages: 167024 nosy: crouleau, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: Regular expression match does not return versions: Python 2.7 Added file: http://bugs.python.org/file26627/RegexBug.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15454] Allow dircmp.report() output stream to be customized
Chris Jerdonek added the comment: Should adding tests for the report methods be a separate issue from this enhancement? Yes, I would create separate issues for this. I would even recommend separating this into one issue for the report() methods (could be done first), and another issue for adding tests for additional directory levels (see additional note below). Any deeper testing of dircmp will also have to not be necessarily comprehensive, as the permutations of test inputs start to become too time-consuming. setUp and tearDown may also need some refactoring for deeper testing. For testing additional directory levels, you may want to wait until after issue 15403 is complete, which is slated for (hopefully) shortly after the 3.3 release. That issue will add functions for the easy creation of arbitrarily nested directories of files, etc. You will see I made a comment there about application to the filecmp tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15454 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15450] Allow dircmp.subdirs to behave well under subclassing
Changes by Chris Jerdonek chris.jerdo...@gmail.com: -- nosy: +cbc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15450 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Terry J. Reedy added the comment: I presume the previously crashing test cases should be added to the test suite, to detect reversion. Is there a method (faulthandler?) to keep tests going, or stop gracefully, when adding a once-crasher that could revert? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12370] Use of super overwrites use of __class__ in class namespace
Changes by Chris Rebert pyb...@rebertia.com: -- nosy: +cvrebert ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12370 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11486] Add option to not install into /Applications
Ned Deily added the comment: That would be nice although if you use your documented trick in Mac/README: ./configure --enable-framework=/Users/ronald/Library/Frameworks everything including the Applications directory is installed relative to the frameworks directory, so, in this case, /Users/ronald/Applications. It seems to work really well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
Matthew Barnett added the comment: That's because it uses a pathological regular expression (catastrophic backtracking). The problem lies here: (\\?[\w\.\-]+)+ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: On Jul 30, 2012, at 09:41 PM, Brett Cannon wrote: As for the diagram(s), I have attached the overall PDF that I still have from my original Omnifgraffle file (which I don't have a license to anymore) that I built my PyCon 2008 presentation with. It's probably outdated at this point. I will have to redo them for my PyCon Argentina/Brasil (maybe US?) import talks anyway. Thanks. This isn't quite the level I was looking for, but we can add a diagram later. (I think I've improved the discussion on __package__ based on your feedback and PEP 366. Thanks!) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: On Jul 31, 2012, at 12:28 AM, Eric Snow wrote: You ask in [2] whether path importer refers specifically to the callables on sys.path_hooks. Can you site a reference for this? I found one reference in PEP 302 to path importer but it's hard to tell exactly what that is referring to. Unfortunately not. There aren't many people that use import hook terminology and I already have a terrible memory. :) Regardless, I find path importer a little too ambiguous. Dang. I've grown to really like path importer for the thing on sys.meta_path that provides sys.path and related functionality. It seems appropriate given the observation that we're talking about sys.path or __path__ and what this thing does is manage that corner of the import subsystem. Thinking about Nick's suggestion then, the callables on sys.path_hooks would be path entry finders since they are given a chance to find modules for each entry on the import path (be it sys.path or __path__). I think this terminology holds together well, and I think I'm going to land it as such. Then we can promote this terminology as we talk about the import system in other documentation. * (glossary.rst) sys path finder: having sys is a nice touch, making it more distinct and more explicit. TBH, I'm not crazy about the term sys path finder either but I couldn't think of anything better. What don't you like about the sys path thingee names? I find them to be nice and explicit. I'll mull this over some more. Nick put his finger on it. sys path implies that only sys.path is involved, whereas __path__ is also involved. * (import_machinery.rst) Meta path loaders, end of paragraph 2: The finder * could also be a classmethod that returns an instance of the class. I don't understand what you're suggesting here. Yeah, that was poorly worded. I'd meant to suggest that you could document the alternative to find_module() and load_module() being regular methods of the same object. For instance: class MyMetaHook: @classmethod def find_module(cls, name, path=None): return cls() def load_module(self, name): raise ImportError(You lose!) Thus, the finder is the class, and the loader is the instance. While true, it's not required in the specification, so I'd like to leave this out. Smart Pythonistas can figure details like that out. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
Tim Peters added the comment: Matthew is right: the nested quantifiers can cause this to take a very long time when the regexp doesn't match. Note that the example cannot match, because nothing in the regexp can match the space before warning in the example string. But the nested quantifiers cause it to _try_ an enormous number of futile attempts. Under Python 2.7.1, it eventually does return, but it took over 15 minutes when I tried it on my laptop. Friedl's book Mastering Regular Expressions is a book-length treatment of how to write regexps that don't take forever when they fail to match, and that's highly recommended. Or start a discussion on comp.lang.python, and I'm sure someone will help you flesh out exactly what it is you do and don't want to match, and how to write a regexp that performs well on both matching and non-matching text (the bug tracker isn't an appropriate place for this). -- nosy: +tim_one resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Eric Snow added the comment: Well, I'm more -0 than -1 on path importer, though I do like default path importer better. As to the rest, sounds good to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Antoine Pitrou added the comment: Here's a patch based on the analysis. All test cases given here now raise TypeError. I think we want to add those tests to the test suite as well. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15490] Correct __sizeof__ support for StringIO
Antoine Pitrou added the comment: Does this mean that PyAccu should be visited in tp_traverse and not be accounted in __sizeof__? Or should we tighten the control and ensure that PyAccu contains only exact Unicode objects? IMO, the latter. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15490 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
Caleb Rouleau added the comment: Thanks for the help. Apologies for the poor understanding of regular expressions. Closing this issue. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Stefan Krah added the comment: Antoine Pitrou rep...@bugs.python.org wrote: I think we want to add those tests to the test suite as well. What's a good place? Shall we just add one of the tests to test_tuple? Also, the only person to run the tests with the PGO build will probably be Martin just before the releases. :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8847] crash appending list and namedtuple
Antoine Pitrou added the comment: Antoine Pitrou rep...@bugs.python.org wrote: I think we want to add those tests to the test suite as well. What's a good place? Shall we just add one of the tests to test_tuple? Sounds good. And another of them to test_list perhaps as well :) Also, the only person to run the tests with the PGO build will probably be Martin just before the releases. :) True, but other people may still run them *after* the release. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8847 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
Serhiy Storchaka added the comment: Make a distinction between a large number of infinity. You have a bad regexp, the matching time depends exponentially on the length of the string. Try with short strings. Use the regexp r(\w:)(\\?[\w\.\-]+)((\\[\w\.\-]+)*)(\.[\w ]+): . It's not a bug. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15502] Meta path finders and path entry finders are different, but share an ABC
Brett Cannon added the comment: So I think Nick has the inheritance inverted and I would have Finder inherit from everything to stay backwards-compatible and to ease future deprecation (which could potentially happen starting in Python 3.3), although my approach weakens the usefulness of the ABCs to the point that Nick is probably right in the end. =) Ideally you would have MetaPathFinder which has find_module(fullname, path). Nnotice there is no default value for path since meta path finders always have something passed in for 'path', even if it's None. The other ABC would be PathImporter which defines find_loader(fullname). Notice how 'path' is no longer defined as it isn't used by PathFinder when calling a path importer. importlib.abc.Finder would then inherit from both MetaPathFinder and PathImporter. This is because if someone wants to be compatible with both Python 3.2 and 3.3 without any trickery, they will want to simply inherit from Finder for either a meta path finder or a path importer. Otherwise in Python 3.2 you would have to do some conditional work or define a fake e.g. MetaPathFinder ABC in order to inherit from the new ABCs. Finder would have find_module(fullname, path=None) defined but returning None by default. It would also inherit from PathImporter, but this is where it gets tricky since importlib decides whether to call find_loader() based on whether find_loader() is defined, which means PathImporter couldn't require it to instantiated. Otherwise some hack will be needed in Finder for it to claim that find_loader() is defined but while still failing a hasattr() check (which I can't think of how to do; maybe some insane metaclass which temporarily sets find_loader() so abstractmethod doesn't complain but then isn't defined in the end so __getattr__ still raises an AttributeError?). IOW I don't see an ideal situation here and we will probably want to do what Nick suggested. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15502 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: I think I was unclear in my previous follow up. Here are the objects involved, taken from the glossary. import path A list of locations (or :term:`path entries path entry`) that are searched by the :term:`path importer` for modules to import. During import, this list of locations usually comes from :data:`sys.path`, but for subpackages it may also come from the parent package's ``__path__`` attribute. meta path finder A finder returned by a search of :data:`sys.meta_path`. Meta path finders are related to, but different from :term:`path entry finders path entry finder`. path entry A single location on the :term:`import path` which the :term:`path importer` consults to find modules for importing. path entry finder A :term:`finder` returned by a callable on :data:`sys.path_hooks` (i.e. a :term:`path entry hook`) which knows how to locate modules given a :term:`path entry`. path entry hook A callable on the :data:`sys.path_hook` list which returns a :term:`path entry finder` if it knows how to find modules on a specific :term:`path entry`. path importer One of the default :term:`meta path finders meta path finder` which searches an :term:`import path` for modules. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Antoine Pitrou added the comment: Shouldn't it be committed already? I don't see the point of refining documentation in a separate repo rather than in the main repo. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15515] Regular expression match does not return
Matthew Barnett added the comment: It's probably inappropriate for me to mention that the alternative 'regex' module on PyPI completes promptly, so I won't. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15515 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15516] exception-handling bug in PyString_Format
New submission from Tom Tromey:
In gdb we supply a class whose nb_int method can throw
an exception.
A user wrote code like this:
return '%x' % value
... where value was an instance of this class.
This caused funny exception behavior later on.
You can see the original report here:
http://sourceware.org/bugzilla/show_bug.cgi?id=14320
I tracked down the odd behavior to this code in
stringobject.c:PyString_Format:
iobj = PyNumber_Int(v);
if (iobj==NULL) iobj = PyNumber_Long(v);
Here, PyNumber_Int fails and sets the exception.
I think this ought to be cleared before calling
PyNumber_Long. In our case, PyNumber_Long succeeds,
and the program keeps executing until something happens
to call PyErr_Occurred.
I think this patch ought to fix the problem:
diff -r e0eb7dea245f Objects/stringobject.c
--- a/Objects/stringobject.cMon Jul 30 04:07:49 2012 -0700
+++ b/Objects/stringobject.cTue Jul 31 13:58:07 2012 -0600
@@ -4489,7 +4489,10 @@
}
else {
iobj = PyNumber_Int(v);
-if (iobj==NULL) iobj = PyNumber_Long(v);
+if (iobj==NULL) {
+ PyErr_Clear();
+ iobj = PyNumber_Long(v);
+ }
}
if (iobj!=NULL) {
if (PyInt_Check(iobj)) {
I haven't written a test case yet; David Malcolm suggested I file
a bug here first.
--
components: None
messages: 167043
nosy: tromey
priority: normal
severity: normal
status: open
title: exception-handling bug in PyString_Format
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15516
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15516] exception-handling bug in PyString_Format
Changes by Dave Malcolm dmalc...@redhat.com: -- nosy: +dmalcolm ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15516] exception-handling bug in PyString_Format
Antoine Pitrou added the comment: Hi, and thank you for reporting. The diagnosis looks good, please proceed and add a test case if possible. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15516 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Barry A. Warsaw added the comment: On Jul 31, 2012, at 03:21 AM, Eric Snow wrote: 1. default path importer (a.k.a PathFinder), +1, although currently I am refraining from using default when describing this thing. 2. path hook (lives on sys.path_hooks), I have called these path entry hooks 3. path entry handler (finder look-alike that a path hook returns), I still call these path entry finders. I understand the ambiguity, and despite supporting a slightly different protocol than meta path finders, they still serve the role of finding a loader for a module. So for now, I'm keeping path entry finder, though I'll leave the door slightly open to persuasion. :) 4. module loader (business as usual). I've pulled Loaders out into a separate higher level section because as you say, the loader API is the same for the things returned by both meta path finders and path entry finders. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Roundup Robot added the comment: New changeset c933ec7cafcf by Barry Warsaw in branch 'default': Address substantially all of Eric Snow's comments in issue #15295, except for http://hg.python.org/cpython/rev/c933ec7cafcf New changeset d5317b8f455a by Barry Warsaw in branch 'default': - Issue #15295: Reorganize and rewrite the documentation on the import system. http://hg.python.org/cpython/rev/d5317b8f455a -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15295] Import machinery documentation
Changes by Barry A. Warsaw ba...@python.org: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15295 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15510] textwrap.wrap('') returns empty list
Chris Jerdonek added the comment: Attaching patch with test cases. I added 6 new tests: *test_empty_string test_whitespace_trailing *test_drop_whitespace__all_whitespace *test_initial_indent__empty_string test_subsequent_indent__trailing_whitespace test_subsequent_indent__long_indent The starred ones fail with the current code (the test cases are similar to the snippets I included in my first comment). The others fail under a certain incorrect implementation of this issue. (I'm adding them to increase coverage of edge cases and to protect against future regressions.) -- keywords: +patch stage: - patch review Added file: http://bugs.python.org/file26628/issue-15510-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15510 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
