[issue15476] Add "code object" to glossary

[Chris Jerdonek]

New submission from Chris Jerdonek :

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 

___
___
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 Jerdonek  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 

___
___
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 Jerdonek  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 

___
___
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]

Serhiy Storchaka  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 

___
___
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]

Serhiy Storchaka  added the comment:

Thank you for fast commiting.

--

___
Python tracker 

___
___
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 Krah  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 

___
___
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

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


--
nosy:  -storchaka

___
Python tracker 

___
___
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]

Georg Brandl  added the comment:

With the beta delayed as you say, I'm okay with this going in now.

--

___
Python tracker 

___
___
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]

Georg Brandl  added the comment:

OK, finally I think this can go in.

--

___
Python tracker 

___
___
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]

Georg Brandl  added the comment:

OK, demoting.

--
priority: release blocker -> deferred blocker

___
Python tracker 

___
___
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]

New submission from Ned Deily :

==
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 

___
___
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]

Martin v. Löwis  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 

___
___
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]

Roundup Robot  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 

___
___
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 Krah  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 

___
___
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]

Martin v. Löwis  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 

___
___
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]

Amaury Forgeot d'Arc  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 

___
___
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]

Mark Dickinson  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 

___
___
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]

Mark Dickinson  added the comment:

Also:  what's HAVE_LOG1P for this build?

--

___
Python tracker 

___
___
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]

STINNER Victor  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 

___
___
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]

STINNER Victor  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15478] UnicodeDecodeError on OSError

[STINNER Victor]

New submission from STINNER Victor :

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 

___
___
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]

STINNER Victor  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 

___
___
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]

Changes by STINNER Victor :


--
title: UnicodeDecodeError on OSError -> UnicodeDecodeError on OSError on 
Windows with undecodable (bytes) filename

___
Python tracker 

___
___
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]

STINNER Victor  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 

___
___
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]

Serhiy Storchaka  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 

___
___
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]

Changes by Serhiy Storchaka :


--
nosy: +mark.dickinson

___
Python tracker 

___
___
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]

Martin v. Löwis  added the comment:

Serhiy: this is safe to ignore.

--

___
Python tracker 

___
___
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]

Amaury Forgeot d'Arc  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 

___
___
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]

Nick Coghlan  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 

___
___
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]

Serhiy Storchaka  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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2771] Test issue

[Ezio Melotti]

Ezio Melotti added the comment:

test

--
keywords: +easy -patch
nosy:  -python-dev
priority:  -> low
resolution: fixed -> later

___
Python tracker 

___
___
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]

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 

___
___
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 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 

___
___
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 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 

___
___
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]

Meador Inge added the comment:

On Sat, Jul 28, 2012 at 3:27 AM, Serhiy Storchaka
 wrote:

> Serhiy Storchaka  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 

___
___
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]

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 

___
___
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]

Amaury Forgeot d'Arc added the comment:

IMO we should not ship 3.3 without a fix for this.

--
priority: normal -> high

___
Python tracker 

___
___
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

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +georg.brandl

___
Python tracker 

___
___
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

[Georg Brandl]

Changes by Georg Brandl :


--
priority: high -> release blocker

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Changes by Eric Snow :


--
versions: +Python 3.3

___
Python tracker 

___
___
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]

Changes by Eric Snow :


--
versions: +Python 3.3

___
Python tracker 

___
___
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]

Amaury Forgeot d'Arc added the comment:

Removing TYPE_INT64 was indeed the most reasonable choice.

--

___
Python tracker 

___
___
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]

Changes by Martin v. Löwis :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
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

[Martin v . Löwis]

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 

___
___
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]

Martin v. Löwis added the comment:

I put the complete removal of TYPE_INT64 into issue15480

--

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Martin v. Löwis added the comment:

Thanks for the patch, committed with slight modifications.

--
nosy: +loewis
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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 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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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__

[Łukasz Langa]

Changes by Łukasz Langa :


--
assignee: lukasz.langa -> sbt
stage: patch review -> commit review
versions:  -Python 2.7, Python 3.2

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Martin v. Löwis added the comment:

distutils are in Lib/distutils. Distutils2 has been removed from Python.

--

___
Python tracker 

___
___
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]

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 

___
___
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]

Antoine Pitrou added the comment:

Sounds totally overkill to me.

--
nosy: +pitrou

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Chris Jerdonek added the comment:

I don't have a problem with closing this as rejected if Victor agrees.

--

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Changes by Martin v. Löwis :


--
nosy:  -loewis

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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

[Ronan Lamy]

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 "", line 1, in 
  File "./foo/__init__.py", line 1, in 
__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 

___
___
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]

Eric Snow added the comment:

See issue14592 (particularly msg158466).

--
nosy: +eric.snow

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

Changes by Meador Inge :


--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
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

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

___
___
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]

Nick Coghlan added the comment:

s/not added/note added/

--

___
Python tracker 

___
___
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]

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 

___
___
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

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15295] Import machinery documentation

[Nick Coghlan]

Changes by Nick Coghlan :


--
hgrepos: +142

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15295] Import machinery documentation

[Nick Coghlan]

Nick Coghlan added the comment:

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 statement:

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'll use a couple of examples from the logging package to make this clear:

# Attribute access will fail for submodules that haven't been imported yet
>>> import logging
>>> logging.DEBUG
10
>>> logging.handlers
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'module' object has no attribute 'handlers'

# Direct imports will fail for attributes that are not submodules
>>> import logging.DEBUG
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'logging.DEBUG'
>>> import logging.handlers

# From imports check for an existing attribute first, but check for a submodule 
if the attribute is missing
>>> del sys.modules["logging"]
>>> del sys.modules["logging.handlers"]
>>> from logging import DEBUG
>>> from logging import handlers

Aside from this flaw, the new content in the import statement looks good. More 
on the import system section in a subsequent comment.

--

___
Python tracker 

___
___
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]

Georg Brandl added the comment:

Richard, can the issue be closed?

--
priority: release blocker -> critical

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15295] Import machinery documentation

[Nick Coghlan]

Nick Coghlan added the comment:

General comment:

runpy, pkgutil, et al should all get "See Also" links at the top pointing to 
the new import system section.

Import system intro:

As noted above, I suggest changing the name :)

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).

5.1 Packages:

Don't tease readers, just tell them: the defining characteristic of a package 
is that it is a module object with a __path__ attribute.

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

Also, I suggest adding a 5.1.3 Package Example subheading - currently you 
define an initialised package under the namespace package heading

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).

5.2.2 Finders and loaders:

The term "sys path finder" is incorrect as registered path hooks are invoked 
for both sys.path entries *and* package __path__ entries. I suggest "path entry 
finder". (I agree a longer name is needed to better distinguish them from 
metapath finders)

5.2.3 Import hooks:

While it does get cleared up in 5.2.4, this section could be clearer that the 
hooks *cannot* override the initial check of the module cache.

5.3.4 Metapath:

See above comment about clarifying that an import path is passed to 
find_module() rather than a filesystem path.

The description of the path importer is incorrect. It only knows how to scan an 
import path and interrogate the path hooks. It's the individual path entry 
finders that know how to do things like load modules from the filesystem or zip 
files.


5.2.5 Meta path loaders

I don't like the title here. There's no such thing as a meta path loader. there 
are only module loaders. Once they're created, it doesn't matter how you found 
them.

Clarify that the loader only has to remove the modules it inserted itself. 
Other modules that were loaded *successfully* as a side effect of the code 
execution will remain in the cache.

5.3 The Path Importer

As noted above, the path importer is *NOT* restricted to filesystem imports. 
All it cares about is arbitrary text sequences and path hooks. With the right 
path hook, you could use URLs or database connection strings as path entries.

5.5 References

I'd also point to PEP 328 (absolute imports by default and explicit relative 
import syntax) and PEP 338 (using the import system to find __main__)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue15295] Import machinery documentation

[Nick Coghlan]

Nick Coghlan added the comment:

Great start here Barry, I'll switch my checkout over to read/write access and 
start contributing fixes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com