[issue15364] sysconfig confused by relative paths
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c2618b916081 by Ned Deily in branch 'default': Issue #15364: Fix test_srcdir for the installed case. http://hg.python.org/cpython/rev/c2618b916081 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15364 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1859] textwrap doesn't linebreak on \n
Serhiy Storchaka storch...@gmail.com added the comment: def wrap_paragraphs(text, width=70, **kwargs): return [line for para in text.splitlines() for line in textwrap.wrap(para, width, **kwargs) or ['']] -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1859 ___ ___ 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 ericsnowcurren...@gmail.com added the comment: Awesome addition, Barry! Bless you for slogging through this. Here are some thoughts (prepare one grain of salt for each): * (glossary.rst) finder: should also reference PEP 420. * (glossary.rst) module: s/contain/containing/ * (glossary.rst) path importer: I like that you pointed out this specific metapath importer, but aren't path importers something else? [2] Perhaps the metapath importer doesn't need to be in the glossary. Then again I like the entry, though I'd change :term:`finder` / :term:`loader` to metapath importer. Maybe just a different term would work, like sys path subsystem. Regardless, it is certainly the big dog in the import machinery and deserves special attention. * (glossary.rst) sys path finder: having sys is a nice touch, making it more distinct and more explicit. * (importlib.rst) I could have sworn that find_loader() and resolve_name() were public... * (importlib.rst) module_repr() is nice. * (importlib.rst) SourceFileLoader.load_module(): What about when the name does not match? * (import_machinery.rst) import machinery: really nice intrro! * (import_machinery.rst) import machinery, end of first paragraph: Note that importlib.import_module() is the recommended method of calling the import machinery. * (import_machinery.rst) import machinery, third paragraph: though there is the side effects of the module getting added to sys.modules, and of parent modules getting imported (if not bound). * (import_machinery.rst) package, second paragraph: generally implies further explanation which doesn't materialize. Perhaps s/modules generally do not contain other modules or packages/modules do not naturally contain other modules or packages/ or something like that? * (import_machinery.rst) I like that you make it clear that even packages are not strictly a FS-based construct. * (import_machinery.rst) how about a section devoted just to the attributes of modules and packages, perhaps expanding upon or supplanting the related entries in the data model reference page? * (import_machinery.rst) Namespace packages: while provided by a separate vendor installed container does convey the broad possibilities, it's nearly equivalent to separate sys.path entries in practice (and in the example). Regardless, separate vendor installed container could be clarified. * (import_machinery.rst) Searching, paragraph 1: don't forget importlib.import_module()! :) * (import_machinery.rst) The module cache: A gotcha snuck in under the old machinery that may or may not be worth noting. [3] * (import_machinery.rst) nice point about messing around with sys.modules. * (import_machinery.rst) I like the sound of import protocol. * (import_machinery.rst) Meta path loaders, end of paragraph 2: The finder could also be a classmethod that returns an instance of the class. * (import_machinery.rst) Meta path loaders: reload() is no longer a builtin function. * (import_machinery.rst) Meta path loaders: If the load fails, the loader needs to remove any modules... is a pretty exceptional case, since the modules is not in charge of its parent or children, nor of import statements executed for it. Is this a new requirement? * (import_machinery.rst) Meta path loaders: too bad there isn't something like __origin__ for the case where __file__ doesn't make semantic sense, but you still want to record where the module came from. * (import_machinery.rst) I'm surprised __name__ isn't required. * (import_machinery.rst) __loader__ is finally getting the respect it deserves (after nearly 10 long years)! * (import_machinery.rst) Meta path loaders: what should __package__ be set to for a top-level module? * (import_machinery.rst) Meta path loaders: s/it should execute the module's code/the loader should execute the module's code/. * (import_machinery.rst) Module reprs: perhaps s/``loader.module_repr(module)``/``module.__loader__.module_repr(module)``/ * (import_machinery.rst) Module reprs: how does module.__qualname__ fit in? * (import_machinery.rst) module.__path__: s/are consulted/is consulted/ ? * (import_machinery.rst) The Path Importer: as noted above, this seems like a new usage of path importer, a term which carries other meaning already. It's an important and distinct thing though, worthy of its own name. * (import_machinery.rst) sys path finders, third paragraph: maybe put a reference to the site module? * (import_machinery.rst) sys path finders, last paragraph: s/it is used to load/that's what the import machinery uses to load/. * (import_machinery.rst) NullImporter (issue15473)? I though Brett had a plan for taking it to the gallows... * (import_machinery.rst) Diagrams? Brett again. :) He put together some nice ones a few years back. * (import_machinery.rst) * (import_machinery.rst) * (simple_stmts.rst) a wonderful improvement! * (simple_stmts.rst) the from list can include submodules which must be imported
[issue15457] consistent treatment of generator terminology
Terry J. Reedy tjre...@udel.edu added the comment: Up until today, I had assumed that it was the generator.__next__ method that was associated with the compiled body. But in writing my response, I investigated and discovered def gf(): yield None gf().gi_code is gf.__code__ True Then i realized that the simple call protocal -- a callable is an object with an executable __call__ method -- makes the magic simpler than I thought. Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code). Since code objects are referred to in various places (compile(), exec(), probably def statement doc), I agree that there should be a minimal glossary entry. One can't really understand generator functions and generators without knowing that def statements create both a function object and an attached code object, but that they can operate somewhat separately. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15457] consistent treatment of generator terminology
Terry J. Reedy tjre...@udel.edu added the comment: I will try to read your new patch when I am fresher. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15476] Add code object to glossary
New submission from Chris Jerdonek chris.jerdo...@gmail.com: This issue is to add code object to the documentation glossary, as discussed in issue 15457 regarding the documentation around generators. This can be a minimal entry that links to the details here, for example-- http://docs.python.org/reference/datamodel.html#the-standard-type-hierarchy specifically: http://docs.python.org/dev/reference/datamodel.html#index-52 -- assignee: docs@python components: Documentation keywords: easy messages: 166633 nosy: cjerdonek, docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Add code object to glossary type: enhancement versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15476 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15457] consistent treatment of generator terminology
Chris Jerdonek chris.jerdo...@gmail.com added the comment: I created issue 15476 to add code object to the glossary. Generator functions must have a special __call__ method that simply creates and returns a generator instance with the code object attached (instead of executing the code). Just to be sure, is this the same as what you were saying in your previous comment? The gf does this# by setting the gi_code attribute of instances to the code object compiled from its body. (Or perhaps it calls the generator class with its code object as parameter. In any case, this is what the special gf.__call__ method does instead of executing its code attribute. Since you're not sure whether the gi_code attribute is meant to be public, it may be best not to mention it explicitly in the docs. This is consistent with what I have done in the latest patch. Thanks in advance for reviewing the update. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15457 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek chris.jerdo...@gmail.com added the comment: We may also add a function to change these limits at runtime. This sounds like a good idea. Is there already an issue for this? If not, I could create one. Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that the test should work for long install paths independent of the setting's value. I wonder if there is a way to adjust the test so that the file name can still be checked in such a scenario (i.e. so that we do not simply add or '...' logic to the regular expression). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15402] Correct __sizeof__ support for struct
Serhiy Storchaka storch...@gmail.com added the comment: issue15456 efficiently demonstrates that the current style can detect bugs which testing with object.__sizeof__ can't. Hmm, I see this as a counterexample. The bug *was not detected* with the current style of testing. But if you insist, I began to translation tests to more tedious style. I hope that issue 15467 patch will be accepted, it is slightly reduce tediousity. However, not all of the tests can be written in this style. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15456] Correct __sizeof__ support for code objects
Serhiy Storchaka storch...@gmail.com added the comment: Thank you for fast commiting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15456 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Stefan Krah stefan-use...@bytereef.org added the comment: Thanks, Nick! I'll move the function declaration back to abstract.h. Waiting for Georg's input. -- It seems to me that #14330 is a blocker that will only be fixed on Monday. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14973] restore python2 unicode literals in ur strings
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: -storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14973 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Georg Brandl ge...@python.org added the comment: With the beta delayed as you say, I'm okay with this going in now. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Georg Brandl ge...@python.org added the comment: OK, finally I think this can go in. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1692335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14578] importlib doesn't check Windows registry for paths
Georg Brandl ge...@python.org added the comment: OK, demoting. -- priority: release blocker - deferred blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
New submission from Ned Deily n...@acm.org:
==
FAIL: testAtanSign (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 526, in testAtanSign
self.assertComplexIdentical(cmath.atan(z), z)
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 96, in assertComplexIdentical
self.assertFloatIdentical(x.imag, y.imag)
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 86, in assertFloatIdentical
self.fail(msg.format(x, y))
AssertionError: floats -0.0 and 0.0 are not identical: zeros have different
signs
==
FAIL: testAtanhSign (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 533, in testAtanhSign
self.assertComplexIdentical(cmath.atanh(z), z)
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 95, in assertComplexIdentical
self.assertFloatIdentical(x.real, y.real)
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 86, in assertFloatIdentical
self.fail(msg.format(x, y))
AssertionError: floats 0.0 and -0.0 are not identical: zeros have different
signs
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 382, in test_specific_values
msg=error_message)
File
/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/test/test_cmath.py,
line 128, in rAssertAlmostEqual
'got {!r}'.format(a, b))
AssertionError: atan1000: atan(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(-0.0, -0.0)
Received value insufficiently close to expected value.
--
Failures seen across various compilers and deployment targets and running the
tests with the same binaries on earlier OS X versions do not fail.
FWIW, the Apple-supplied Python 2.7.2 in 10.8 (that's the most recent version
supplied) also has a test_cmath failure:
==
FAIL: test_specific_values (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py,
line 352, in test_specific_values
msg=error_message)
File
/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/test/test_cmath.py,
line 94, in rAssertAlmostEqual
'got {!r}'.format(a, b))
AssertionError: atan: atan(complex(0.0, 0.0))
Expected: complex(0.0, 0.0)
Received: complex(0.0, -0.0)
Received value insufficiently close to expected value.
--
Is there any reason to not consider this a platform bug? If it is, what should
the bug report be?
--
messages: 166642
nosy: mark.dickinson, ned.deily
priority: normal
severity: normal
status: open
title: test_cmath failures on OS X 10.8
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15477
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Martin v. Löwis mar...@v.loewis.de added the comment: I suggest the opposite: never emit TYPE_INT64 at all. For compatibility, we can still support reading it in 3.3 (and drop that support in 3.4). -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8fbbc7c8748e by Stefan Krah in branch 'default': Issue #12834: Fix PyBuffer_ToContiguous() for non-contiguous arrays. http://hg.python.org/cpython/rev/8fbbc7c8748e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Stefan Krah stefan-use...@bytereef.org added the comment: All right, 3.3 is fixed. Re-targeting for 3.2 and 2.7. -- priority: release blocker - normal versions: +Python 3.1 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Martin v. Löwis mar...@v.loewis.de added the comment: Here is a patch to stop generating TYPE_INT64. Ok for 3.30b2? -- keywords: +patch priority: high - release blocker Added file: http://bugs.python.org/file26553/marshal.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Here is a patch that write TYPE_INT64 on most platforms (where either long or long long is 64bit). It is admittedly much larger than Martin's... -- Added file: http://bugs.python.org/file26554/marshal_use_int64.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Mark Dickinson dicki...@gmail.com added the comment: Judging by previous reports of this type, it's probably either a bug in the platform math library or a compiler optimization bug (or possibly a combination of the two: one previous OS X bug involved calls to sin / cos being 'optimized' to a badly implemented single call to cexp). I assume the failure still happens in debug mode? If so, a math library bug seems more likely. Are there any math module failures? It's not immediately obvious what the bug is, since the cmath module functions are not just simple wrappers around library functions. In this case it looks like either atan2 or log1p is doing the wrong thing with signs of zeros. What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0 and -0.0 respectively.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Mark Dickinson dicki...@gmail.com added the comment: Also: what's HAVE_LOG1P for this build? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor victor.stin...@gmail.com added the comment: We may also add a function to change these limits at runtime. This sounds like a good idea. Is there already an issue for this? If not, I could create one. There is no such issue. You can create it: add me to the nosy list. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
STINNER Victor victor.stin...@gmail.com added the comment: Regardless of whether MAX_STRING_LENGTH is increased, my instinct is that the test should work for long install paths independent of the setting's value. I wonder if there is a way to adjust the test so that the file name can still be checked in such a scenario (i.e. so that we do not simply add or '...' logic to the regular expression). The purpose of the test is to check that the traceback is correct: it's important to check that the filename ends with threading.py. If you don't know in which file the bug occured, the traceback is useless. Changing the MAX_STRING_LENGTH should be enough to fix this issue before Python 3.3 final. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15478] UnicodeDecodeError on OSError
New submission from STINNER Victor victor.stin...@gmail.com: On Windows, if an OS error fails, the filename type is bytes and the filename cannot be decoded: Python raises an UnicodeDecodeError instead of an OSError. The problem is that Python decodes the filename to fill OSError.filename field. See the issue #15441 for the initial report. There are different options to solve this issue: - always keep the filename parameter unchanged, so OSError.filename can be a str or a bytes string, depending on the input parameter - try to decode the filename from the filesystem encoding, or keep the filename unchanged: OSError.filename is only a bytes string if the filename cannot be decoded - don't fill OSError.filename (= None) if the filename cannot be decoded - use surrogateescape, replace or backslashreplace error handler to decode the filename This issue is specific to Windows: on other plaforms, the filename is decoded using the surrogateescape error handler and so decoding the filename cannot fail. I don't know if OSError.filename is only used to display more information to the user, or if it is used to do another operation on the file (ex: os.chmod). I like solutions keeping the filename unchanged, because it does not loose information, and the user can decide how to handle the undecodable filename. I don't like the option trying to decode the filename or keeping it unchanged it decoding fails, because applications will work in most cases, but crash when someone comes with an unusual code page, a special USB key, or a filename with a non-ASCII character. So the best option is maybe to always keep the bytes filename unchanged. Such change cannot be done anymore in Python 3.3, it's too late to test it correctly. -- components: Unicode, Windows messages: 166652 nosy: ezio.melotti, flox, haypo, ishimoto, loewis, tim.golden priority: normal severity: normal status: open title: UnicodeDecodeError on OSError versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15441] test_posixpath fails on Japanese edition of Windows
STINNER Victor victor.stin...@gmail.com added the comment: I still would prefer if only one issue at a time gets fixed, in particular if the two issues require independent changes. Sorry, you are right: I created the issue #15478 for the general fix, and we will use this issue to fix test_genericpath. This issue can be fixed in Python 3.3, whereas #15478 will have to wait for Python 3.4 beause it's an major change and may break a lot of code. It's better to wait the next release to test such change correctly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15441 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename
Changes by STINNER Victor victor.stin...@gmail.com: -- title: UnicodeDecodeError on OSError - UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15478] UnicodeDecodeError on OSError on Windows with undecodable (bytes) filename
STINNER Victor victor.stin...@gmail.com added the comment: In Python 2, it looks like open(arg) does pass its filename argument unchanged to OSError constructor (so it can be bytes or unicode). OSError.filename is always bytes for os.chdir() on UNIX, but OSError.filename can be bytes or unicode for os.chdir() on Windows. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15478 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Serhiy Storchaka storch...@gmail.com added the comment: I can see yet another problem under the hood. Marshalling will output different data on platforms with a different representation of negative numbers. Worse still, these data are non-portable, written on one platform will be read incorrectly on the other. Mark, time for your inquisitor sword. -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +mark.dickinson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Martin v. Löwis mar...@v.loewis.de added the comment: Serhiy: this is safe to ignore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Are there really platforms which don't use two's complement? (If there are, I'm not sure to want to share binary data with them. Same for EBCDIC) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14330] don't use host python, use host search paths for host compiler
Nick Coghlan ncogh...@gmail.com added the comment: Everything is still building happily for me on Fedora, so I suggest looking at the Debian/Ubuntu multiarch support (which is the origin of the dpkg-architecture call). Background in http://bugs.python.org/issue11715 -- nosy: +barry, ncoghlan resolution: fixed - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14330 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15467] Updating __sizeof__ tests
Serhiy Storchaka storch...@gmail.com added the comment: I asked in Python-Dev, and if I understood the answers correctly, we can make changes to 2.7 and 3.2 without fear. For 3.3 risk is higher, so we need to be more attentive. However patch for 3.3 contains not only the potential improvements for other tests, but also bug fixes (I think these bugs should cause tests failure on the platforms where sizeof(Py_ssize_t) != sizeof(long) or sizeof(Py_ssize_t) != sizeof(void*)). Of cause, if Georg Brandl not vetoes this. -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15467 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2771] Test issue
Ezio Melotti added the comment: test -- keywords: +easy -patch nosy: -python-dev priority: - low resolution: fixed - later ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2771 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
New submission from Chris Jerdonek: This issue is to allow the MAX_STRING_LENGTH limit defined in Python/traceback.c to be changed at runtime, as discussed in issue 15463, as well as the two related limits: #define MAX_STRING_LENGTH 100 #define MAX_FRAME_DEPTH 100 #define MAX_NTHREADS 100 http://hg.python.org/cpython/file/ddf15cd9be4a/Python/traceback.c#l16 -- messages: 11 nosy: cjerdonek, haypo priority: normal severity: normal status: open title: Allow MAX_STRING_LENGTH limits to be changed at runtime type: enhancement versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: There is no such issue. You can create it: add me to the nosy list. I created issue 15479 to allow the limits to be changed at runtime. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: The purpose of the test is to check that the traceback is correct: it's important to check that the filename ends with threading.py. I agree with you. That is why I argued against including or '...' logic in the current test. Changing the MAX_STRING_LENGTH should be enough to fix this issue before Python 3.3 final. That is fine. However, I should also point out that the current test is not sufficient to test on all systems/installs that this issue has been fixed. It would be good to add such a test (i.e. one that can, for example, simulate a long install path). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15402] Correct __sizeof__ support for struct
Meador Inge added the comment: On Sat, Jul 28, 2012 at 3:27 AM, Serhiy Storchaka rep...@bugs.python.org wrote: Serhiy Storchaka storch...@gmail.com added the comment: issue15456 efficiently demonstrates that the current style can detect bugs which testing with object.__sizeof__ can't. Hmm, I see this as a counterexample. The bug *was not detected* with the current style of testing. I disagree. It wasn't *directly* detected -- the test broke because of the new structure field that was added and not because of the new dynamic memory allocation that was added. Even so, the fact that the test broke *at all* should have thrown a warning flag up in the developer's mind to reevaluate how the size is calculated. If the test were written using your object.__sizeof__ method, then the test would not have broken *at all* and therefore it might not have even crossed the developers mind to verify whether the sizeof calculation is correct. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Roundup Robot added the comment: New changeset 68e2690a471d by Richard Oudkerk in branch 'default': Issue #1692335: Move initial args assignment to BaseException.__new__ http://hg.python.org/cpython/rev/68e2690a471d -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1692335 ___ ___ 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
Amaury Forgeot d'Arc added the comment: IMO we should not ship 3.3 without a fix for this. -- priority: normal - high ___ 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 Ezio Melotti ezio.melo...@gmail.com: -- nosy: +georg.brandl ___ 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 Georg Brandl ge...@python.org: -- priority: high - release blocker ___ 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
[issue15466] Python/importlib.h is different on 32bit and 64bit
Eric Snow added the comment: I suggest the opposite: never emit TYPE_INT64 at all. For compatibility, we can still support reading it in 3.3 (and drop that support in 3.4). +1 essentially we maintain the status quo -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Roundup Robot added the comment: New changeset 461e84fc8c60 by Martin v. Löwis in branch 'default': Issue #15466: Stop using TYPE_INT64 in marshal, http://hg.python.org/cpython/rev/461e84fc8c60 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Changes by Eric Snow ericsnowcurren...@gmail.com: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ 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: -- versions: +Python 3.3 ___ 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
[issue15466] Python/importlib.h is different on 32bit and 64bit
Amaury Forgeot d'Arc added the comment: Removing TYPE_INT64 was indeed the most reasonable choice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Changes by Martin v. Löwis mar...@v.loewis.de: -- resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15480] Drop TYPE_INT64 from marshal in Python 3.4
New submission from Martin v. Löwis: As a follow-up of issue15466, TYPE_INT64 can be deleted in Python 3.4. -- messages: 166670 nosy: loewis priority: deferred blocker severity: normal status: open title: Drop TYPE_INT64 from marshal in Python 3.4 versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15480 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Martin v. Löwis added the comment: I put the complete removal of TYPE_INT64 into issue15480 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Eric Snow added the comment: Looks like the Misc/NEWS entry got truncated. Also, does this change need a new PYC magic number (now in Lib/importlib/_bootstrap.py)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Martin v. Löwis added the comment: For the truncation, see ec7267fa8b84. I don't see why a new pyc magic number should be necessary. Python continues to support the existing files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Roundup Robot added the comment: New changeset fe29a657bde9 by Martin v. Löwis in branch 'default': Issue #15431: Add _freeze_importlib project to regenerate importlib.h on Windows. http://hg.python.org/cpython/rev/fe29a657bde9 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Martin v. Löwis added the comment: Thanks for the patch, committed with slight modifications. -- nosy: +loewis resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Amaury Forgeot d'Arc added the comment: Comments about PyImport_FrozenModules linkage have not been addressed. Now the build is failing on all Unix machines... -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ 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
New submission from Eric Snow: issue15110 introduced a new private function, _exec_module(), to the default loaders in Lib/importlib/_bootstrap.py. Doing so helped hide importlib frames from the traceback. A related fix is likely required for issue15425. Should some general form of exec_module() be an official part of the loader API (in importlib.abc.Loader). If a loader subclasses one of the default ones, it already gets the behavior for free. Otherwise it does not benefit from the cleaner traceback (unless the author is savvy to the _exec_module() implementation detail). Though the use of Loader._exec_module() to strip tracebacks is an implementation detail of CPython, having a public Loader.exec_module() would allow other implementations to perform a similar action. And if we found a way to move remove_importlib_frames to importlib then all the better. (Looking into traceback API improvements is on my to-do list.) As a bonus, Loader.exec_module() would also allow loaders that wrap other loaders (yes, esoteric) to manage the execution portion of loading. I haven't given this part a lot of thought, so it may not be much of a bonus (or could even be a negative). From the perspective of caution, the import machinery is already pretty complicated. It may not be advisable to add to that even in this little way. -- assignee: eric.snow components: Interpreter Core messages: 166677 nosy: amaury.forgeotdarc, brett.cannon, eric.snow, pitrou priority: normal severity: normal status: open title: Add exec_module() as part of the import loader API type: enhancement versions: Python 3.4 ___ 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
[issue14578] importlib doesn't check Windows registry for paths
Roundup Robot added the comment: New changeset bd58c421057c by Martin v. Löwis in branch 'default': Issue #14578: Support modules registered in the Windows registry again. http://hg.python.org/cpython/rev/bd58c421057c -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14578] importlib doesn't check Windows registry for paths
Martin v. Löwis added the comment: Amaury's patch nearly worked; committed with slight modifications. -- dependencies: -Cannot build importlib.h on Windows resolution: - fixed status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14578 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15463] test_faulthandler can fail if install path is too long
Chris Jerdonek added the comment: Here is a patch to the tests that allows the tests to pass when the install path is long while still checking that file names show up correctly in the traceback. One advantage of this patch's approach is that it provides a way to test the rendering of long paths on all systems/installs. Simply create a test case by setting the scriptname to, for example-- scriptname = 'test_long_file_path_' + 200 * 'x' This patch is just an illustration for discussion purposes and is not meant as a final patch. Also, this patch does not fix the issue of the file names of long paths not getting rendered (which can be addressed by setting the limit to 500 as we discussed). However, as I have noted this patch provides a way to test such a fix. -- keywords: +patch Added file: http://bugs.python.org/file26555/issue-15463-1.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15463 ___ ___ 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: Perhaps this should be split into two issues, as the fix will likely be different for the two. For the first part (SyntaxError), my initial impression is that this will require a similar fix, or extension of it, to the one in issue15110. That fix was limited just to the execution of the module, while this problem happens earlier (during the compilation step in SourceLoader.get_code()). For the second part, it is all about failures during the execution of an import that was initiated during the import of another module. That traceback is definitely less than helpful. A better traceback would is doable. For both (and maybe for issue15110) we should explore using exception chaining to separate the import portion from the rest. I see about working on a patch later this evening. -- nosy: +eric.snow ___ 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
[issue15110] strange Tracebacks with importlib
Eric Snow added the comment: Issue15425 is related. I'm looking into an exception chaining approach that could be applied for this issue too. -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15110 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Antoine Pitrou added the comment: To be clear, the build fails when importlib needs to be frozen again: $ touch Lib/importlib/_bootstrap.py $ make make Modules/_freeze_importlib make[1] : on entre dans le répertoire « /home/antoine/cpython/default » gcc -pthread -c -Wno-unused-result -g -O0 -Wall -Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o Modules/_freeze_importlib.o Modules/_freeze_importlib.c gcc -pthread -o Modules/_freeze_importlib Modules/_freeze_importlib.o Modules/getbuildinfo.o Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o Parser/parser.o Parser/bitset.o Parser/metagrammar.o Parser/firstsets.o Parser/grammar.o Parser/pgen.o Parser/myreadline.o Parser/parsetok.o Parser/tokenizer.o Objects/abstract.o Objects/accu.o Objects/boolobject.o Objects/bytes_methods.o Objects/bytearrayobject.o Objects/bytesobject.o Objects/cellobject.o Objects/classobject.o Objects/codeobject.o Objects/complexobject.o Objects/descrobject.o Objects/enumobject.o Objects/exceptions.o Objects/genobject.o Objects/fileobject.o Objects/floatobject.o Objects/frameobject.o Objects/funcobject.o Objects/iterobject.o Objects/listobject.o Objects/longobject.o Objects/dictobject.o Objects/memoryobject.o Objects/methodobject.o Objects/moduleobject.o Objects/namespaceobject.o Objects/object.o Objects/obmalloc.o Objects/capsule.o Objects/rangeobject.o Objects/setobject.o Objects/sliceobject.o Objects/structseq.o Objects/tupleobject.o Objects/typeobject.o Objects/unicodeobject.o Objects/unicodectype.o Objects/weakrefobject.o Python/_warnings.o Python/Python-ast.o Python/asdl.o Python/ast.o Python/bltinmodule.o Python/ceval.o Python/compile.o Python/codecs.o Python/dynamic_annotations.o Python/errors.o Python/frozenmain.o Python/future.o Python/getargs.o Python/getcompiler.o Python/getcopyright.o Python/getplatform.o Python/getversion.o Python/graminit.o Python/import.o Python/importdl.o Python/marshal.o Python/modsupport.o Python/mystrtoul.o Python/mysnprintf.o Python/peephole.o Python/pyarena.o Python/pyctype.o Python/pyfpe.o Python/pymath.o Python/pystate.o Python/pythonrun.o Python/pytime.o Python/random.o Python/structmember.o Python/symtable.o Python/sysmodule.o Python/traceback.o Python/getopt.o Python/pystrcmp.o Python/pystrtod.o Python/dtoa.o Python/formatter_unicode.o Python/fileutils.o Python/dynload_shlib.o Python/thread.o Modules/config.o Modules/getpath.o Modules/main.o Modules/gcmodule.o Modules/_threadmodule.o Modules/signalmodule.o Modules/posixmodule.o Modules/errnomodule.o Modules/pwdmodule.o Modules/_sre.o Modules/_codecsmodule.o Modules/_weakref.o Modules/_functoolsmodule.o Modules/operator.o Modules/_collectionsmodule.o Modules/itertoolsmodule.o Modules/_localemodule.o Modules/_iomodule.o Modules/iobase.o Modules/fileio.o Modules/bytesio.o Modules/bufferedio.o Modules/textio.o Modules/stringio.o Modules/zipimport.o Modules/faulthandler.o Modules/symtablemodule.o Modules/xxsubtype.o -lpthread -ldl -lutil -lm Modules/_freeze_importlib.o: In function `main': /home/antoine/cpython/default/Modules/_freeze_importlib.c:37: undefined reference to `PyImport_FrozenModules' Python/import.o: In function `find_frozen': /home/antoine/cpython/default/Python/import.c:978: undefined reference to `PyImport_FrozenModules' collect2: ld a retourné 1 code d'état d'exécution make[1]: *** [Modules/_freeze_importlib] Erreur 1 make[1] : on quitte le répertoire « /home/antoine/cpython/default » make: *** [Python/importlib.h] Erreur 2 -- priority: high - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Roundup Robot added the comment: New changeset 7967cb63e50e by Martin v. Löwis in branch 'default': Issue #15431: Declare PyImport_FrozenModules conditionally on Unix only. http://hg.python.org/cpython/rev/7967cb63e50e -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15466] Python/importlib.h is different on 32bit and 64bit
Eric Snow added the comment: I don't see why a new pyc magic number should be necessary. Python continues to support the existing files. Good point. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15466 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Roundup Robot added the comment: New changeset deb421baf671 by Martin v. Löwis in branch 'default': Issue #15431: Drop _freeze_importlib from all build configurations, http://hg.python.org/cpython/rev/deb421baf671 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Changes by Łukasz Langa luk...@langa.pl: -- assignee: lukasz.langa - sbt stage: patch review - commit review versions: -Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1692335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15431] Cannot build importlib.h on Windows
Martin v. Löwis added the comment: The last commits should address Amaury's concerns. _freeze_importlib must now be built manually, followed by a build of pythoncore. Interestingly, the builds failed only once. When rebuilding, the builds succeeded as no attempt to build freeze_importlib was made. After the last change to freeze_importlib, they again built it, and that seems to work now. Tentatively closing the issue again. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15355] generator.__next__() docs should mention exception if already executing
Chris Jerdonek added the comment: Terry, if when reviewing my patch for issue 15457, you also have time to review this much simpler patch (also in the documentation on generators), I would appreciate it. If not, that's okay. -- nosy: +terry.reedy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Chris Jerdonek added the comment: Is there any way I could assist in closing this, perhaps by preparing patches for the Distutils and Distutils2 components? Can someone point me to where the changes to those components should be made (e.g. where they are located)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Ned Deily added the comment:
I assume the failure still happens in debug mode?
Yes
Are there any math module failures?
No
What do math.log1p(0.0) and math.log1p(-0.0) give? (Answers *should* be 0.0
and -0.0 respectively.)
math.log1p(0.0)
0.0
math.log1p(-0.0)
0.0
sysconfig.get_config_var('HAVE_LOG1P')
1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15477
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Martin v. Löwis added the comment: distutils are in Lib/distutils. Distutils2 has been removed from Python. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15438] document that math.pow is inappropriate for integers
Antoine Pitrou added the comment: Changing the incredible issue title :-) -- title: Incredible issue in math.pow - document that math.pow is inappropriate for integers ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15438 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
Antoine Pitrou added the comment: Sounds totally overkill to me. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Chris Jerdonek added the comment: Thanks, Martin. Should Distutils2 be removed from the Components list of the tracker form, then? Or was Éric referencing a third-party location? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Martin v. Löwis added the comment: Should Distutils2 be removed from the Components list of the tracker form, then? No. Please stick to one issue at a time, and distutils2 may come back (google for details). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15479] Allow MAX_STRING_LENGTH limits to be changed at runtime
Chris Jerdonek added the comment: I don't have a problem with closing this as rejected if Victor agrees. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15479 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Mark Dickinson added the comment: math.log1p(0.0) 0.0 math.log1p(-0.0) 0.0 Ah, that would do it, then. It looks as though the system's log1p function is buggy, in the sense that it doesn't follow C99 Annex F (F.9.3.9). It also doesn't agree with what 'man log1p' says on my OS X 10.6 Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.' I'm puzzled about one thing, though: there's a test for this problem in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in this case---in that case, the two testAtanSign and testAtanhSign tests are skipped. So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being defined on this machine; I'm not sure why---there may be a compiler optimization kicking in in the configure test. (Is this clang or gcc, BTW?) So definitely worth a bug report, I'd say, though perhaps it's too much to hope for a fix within the lifetime of 10.8. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Chris Jerdonek added the comment: No. Please stick to one issue at a time, and distutils2 may come back (google for details). I was asking only to determine whether to create a new issue -- not to have that issue addressed here. It seems to me there are missing words in the text, and it needs porting to the packaging docs. Okay, I misunderstood and thought there was more to do. Since Martin said packaging has been removed, all that is left is to add Éric's requested modifications to 3.3 (and make the collected change to 2.7 and 3.2). Patch attached. The commit message can be something like: Issue #15231: minor adjustment to prior fix committed in f315cfa22630 regarding, update PyPI upload doc to say --no-raw passed to rst2html.py. I included a Misc/NEWS entry since that was left out of the previous commit. Also, incidentally, there was a typo in the issue number of the commit message for the previous commit, which explains why Roundup did not post here. -- Added file: http://bugs.python.org/file26556/issue-15231-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15477] test_cmath failures on OS X 10.8
Ned Deily added the comment: It also doesn't agree with what 'man log1p' says on my OS X 10.6 Macbook: under 'SPECIAL VALUES', it says: 'log1p(+-0) returns +-0.' That manpage is unchanged for 10.8. I'm puzzled about one thing, though: there's a test for this problem in the configure script, and LOG1P_DROPS_ZERO_SIGN should be defined in this case---in that case, the two testAtanSign and testAtanhSign tests are skipped. So it looks as though LOG1P_DROPS_ZERO_SIGN isn't being defined on this machine; I'm not sure why---there may be a compiler optimization kicking in in the configure test. Ah, this rings a bell and points out yet another issue: 1. The configure test is working properly: when run on 10.8, LOG1P_DROPS_ZERO_SIGN is set to 1. However, something I just ran into recently, the unittest skip idiom using sysconfig.get_config_vars results - as is being used here in test_cmath - doesn't seem to work properly. I see it is used in test_math and test_subprocess as well. I'll look into that. 2. These types of run-time tests based on configure-time tests are problematic for binary installations of Python, like the OS X installers. For example, the OS X installers are built on earlier versions of OS X where a configuration test (like this one) may have one result but not necessarily the same result on all supported target configurations where the binary Pythons may be installed. And, in general, multiple-architecture builds, in particular, OS X universal builds may have different configuration values per architecture embedded in one executable (i386 vs x86_64 or i386 vs ppc or i386 vs x86_64 vs ppc) that are not reflected in the single architecture ./configure results. I guess it's time to open an issue on that can of worms. (Is this clang or gcc, BTW?) It's clang which is now the only supported option with Xcode 4.4 on either 10.7 or 10.8. More importantly, 10.8 is the first OS X release which itself was built with clang; 10.7 was built with the transitional llvm-gcc compiler. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15477 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Martin v. Löwis added the comment: I won't be able to work on this for the next few months. This took too much time already. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15231] update PyPI upload doc to say --no-raw passed to rst2html.py
Changes by Martin v. Löwis mar...@v.loewis.de: -- nosy: -loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15231 ___ ___ 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: Here's a trivial patch that demonstrates what I mean. Yet, in light of exception chaining, I wonder if we should consider actually making ImportError supercede the inner exception. I'll still try coming up with something similar, but propagates the inside exception. -- keywords: +patch Added file: http://bugs.python.org/file26557/ImportError_is_king.diff ___ 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
[issue9035] os.path.ismount on windows doesn't support windows mount points
Atsuo Ishimoto added the comment: Patch to expose GetVolumePathName() and implementation of ismount(). Tested on Windows7/XP. -- keywords: +patch Added file: http://bugs.python.org/file26558/issue9035.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9035 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15355] generator.__next__() docs should mention exception if already executing
Meador Inge added the comment: Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods. From looking at the code it seems that the patch is correct and that '__next__', 'send', 'throw', and 'close' can all raise the already executing exception via 'gen_send_ex'. Documenting this behavior seems reasonable, but you should probably mention what exception gets raises. BTW, you don't need to make the Misc/NEWS changes a part of your patches. A core dev will write that for you and since Misc/NEWS is changed so much it might conflict and make patches harder to apply across similar branches (say 3.2 and 3.3). -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6471] errno and strerror attributes incorrectly set on socket errors wrapped by urllib
Catherine Devlin added the comment: It's very hard to tell what ought to be done here, since Lib/urllib/request.py throws URLErrors with a great variety of order and number of arguments, and it's not clear how URLError (in Lib/urllib/error.py) intends to handle them. However, in this case, AbstractHTTPHandler.do_open is instantiating URLError with another exception instance, and that exception contains .errno and .strerror. URLError puts the entire error instance into ``reason``, where the information is hidden away as .reason.strno and .reason.strerror. In the name of keeping this information available rather than hiding it, I'm attaching a patch that adds to URLError.__init__: if hasattr(reason, errno): self.errno = reason.errno if hasattr(reason, strerror): self.strerror = reason.strerror Again, I'm not sure this is the most logical approach because I can't find a consistent pattern in the ways URLError is instantiated. -- keywords: +patch nosy: +catherine Added file: http://bugs.python.org/file26559/keeperrdata.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6471 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15482] __import__() change between 3.2 and 3.3
New submission from Ronan Lamy:
I noticed a change in the behaviour of __import__() between 3.2 and 3.3. It
looks like in 3.2 __import__() does a Py2-style combo relative/absolute import.
Here's a minimal test case:
$ ls foo
bar.py __init__.py __pycache__
$ cat foo/__init__.py
__import__('bar', globals(), locals())
$ python3.3 -c import foo
Traceback (most recent call last):
File string, line 1, in module
File ./foo/__init__.py, line 1, in module
__import__('bar', globals(), locals())
ImportError: No module named 'bar'
$ python3.2 -c import foo
$
I believe that 3.3 is correct and that 3.2 is wrong but can't be changed now,
so I suppose that 3.2 should just document the actual behaviour of __import__()
and 3.3 should document the change.
(The context is that I encountered issue 15434. This looks related, but I'm not
sure it is.)
--
assignee: docs@python
components: Documentation, Interpreter Core
messages: 166706
nosy: Ronan.Lamy, brett.cannon, docs@python, ncoghlan
priority: normal
severity: normal
status: open
title: __import__() change between 3.2 and 3.3
versions: Python 3.2, Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15482
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15482] __import__() change between 3.2 and 3.3
Eric Snow added the comment: See issue14592 (particularly msg158466). -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15482] __import__() change between 3.2 and 3.3
Nick Coghlan added the comment: The specific bug is that, in 3.2, the claimed default (level=0) is not accurate: the default is actually (level=-1), as it was in 2.x. The import statement passes level=0 explicitly (as it does in 2.x when from __future__ import absolute_import is in effect). The docstring in 3.2 is accurate, the prose documentation is incorrect. In 3.3, the docstring is currently wrong, but the prose documentation is correct. However, it should have a versionchanged: 3.3 not added, indicating that the default import level has finally been brought into compliance with the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15402] Correct __sizeof__ support for struct
Roundup Robot added the comment: New changeset 37554bda2014 by Meador Inge in branch '2.7': Issue #15402: Simplify Struct.__sizeof__ and make tests more precise. http://hg.python.org/cpython/rev/37554bda2014 New changeset 97dd2090a36c by Meador Inge in branch '3.2': Issue #15402: Simplify Struct.__sizeof__ and make tests more precise. http://hg.python.org/cpython/rev/97dd2090a36c New changeset 0eedf56f9a38 by Meador Inge in branch 'default': Issue #15402: Simplify Struct.__sizeof__ and make tests more precise. http://hg.python.org/cpython/rev/0eedf56f9a38 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15402] Correct __sizeof__ support for struct
Changes by Meador Inge mead...@gmail.com: -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15402 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15475] Correct __sizeof__ support for itertools
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15475 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15482] __import__() change between 3.2 and 3.3
Nick Coghlan added the comment: s/not added/note added/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15482 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15355] generator docs should mention already-executing exception
Chris Jerdonek added the comment: Hmmm, in your original description you say that the 'generator.__next__' documentation should be changed, but in the patch the note applies to all generator methods. Thanks, Meador. Yes, I realized that later. Retitling now. I will also add the exception type. I wasn't sure if that was implementation-specific. BTW, you don't need to make the Misc/NEWS changes Certainly -- will do from now on. Thanks for telling me. I had thought I was helping. New patch attached. -- title: generator.__next__() docs should mention exception if already executing - generator docs should mention already-executing exception Added file: http://bugs.python.org/file26560/issue-15355-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15355 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15469] Correct __sizeof__ support for deque
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12834] memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays
Nick Coghlan added the comment: Was the point that memoryview.tobytes() has a known data corruption bug in 3.2 and 2.7 raised in the previous discussion? I'm pretty sure I had forgotten about it, and I don't remember it coming up in the thread. The trickiest aspect of a backport of the new implementation is that we need to preserve the C ABI - extensions compiled against any maintenance release should work with all maintenance releases in that series. The new APIs aren't a major problem - just sprinkle a few underscores around to mark them as private on the older versions (I've certainly done that before when a bug fix genuinely needed something that qualified as a new feature: implemented a private version to use in fixing the bug on the maintenance branch, then promote that to a public API on trunk) -- priority: normal - high title: PyBuffer_ToContiguous() incorrect for non-contiguous arrays - memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for non-contiguous arrays ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12834 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15473] importlib no longer uses imp.NullImporter
Nick Coghlan added the comment: See the porting notes: http://docs.python.org/dev/whatsnew/3.3.html#porting-python-code With the removal of the implicit default finder, the 3.3 semantics are that both None *and* imp.NullImporter mean There is no importer for this path. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15473 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15452] Eliminate the use of eval() in the logging config implementation
Nick Coghlan added the comment: I know ast.literal_eval() isn't enough - that's why I suggested the addition of ast.lookup_eval() in the opening post. As far as your other suggestion goes, don't reinvent crypto badly - if you want to provide authentication support in listener(), provide a hook that allows the application to decide whether or not to accept the configuration before it gets applied. They can then choose there own authentication mechanism based on their own needs, and handle any appropriate security updates. Some will choose a simple shared secret, some may choose to require a cryptographic signature, some may pass the entire payload in an encrypted form. However, this isn't an either/or situation - we can, and should, do both (i.e. provide a hook that allows the application to preauthenticate the configuration before it is applied, as well as replacing the use of eval() with something more limited like str.format lookup syntax). The right security mindset is to set up defence in depth, not trust one particular layer of defence to handle all possible varieties of attack. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15452 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15451] PATH is not honored in subprocess.Popen in win32
Grissiom Gu added the comment: Thank you for everyone participated in this issue. I learnt a lot from you. But I observe that the same script(with proper modification of file names) works very well under Linux. After I dive into the source code, I found Python use execvpe to invoke the child process which _will_ use the PATH variable to search the executable. So I think this is a inconsistent behavior at least. So I think we should either notify the user that this API is inconsistent or just fix the Popen call in windows. Prepending the new PATH to the env of current process and than call CreateProcess is just a patch within 10 lines, I think. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15451 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
