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
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
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/
*
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
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
___
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--
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).
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
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
Serhiy Storchaka storch...@gmail.com added the comment:
Thank you for fast commiting.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15456
___
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
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: -storchaka
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14973
___
___
Python-bugs-list
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
___
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
___
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
___
New submission from Ned Deily n...@acm.org:
==
FAIL: testAtanSign (test.test_cmath.CMathTests)
--
Traceback (most recent call last):
File
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
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
--
___
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
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
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
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
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
___
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.
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
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
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
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
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
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
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +mark.dickinson
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
___
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
___
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
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,
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
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
___
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
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
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
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.
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
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
___
Changes by Ezio Melotti ezio.melo...@gmail.com:
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
Changes by Georg Brandl ge...@python.org:
--
priority: high - release blocker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
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
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
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15466
___
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15425
___
___
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
___
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
___
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
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
___
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)?
--
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
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
___
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
Antoine Pitrou added the comment:
Sounds totally overkill to me.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15479
___
___
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
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
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
___
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
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
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,
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
___
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
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
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
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',
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,
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
Eric Snow added the comment:
See issue14592 (particularly msg158466).
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15482
___
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).
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
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
___
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15475
___
___
Python-bugs-list
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
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
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15469
___
___
Python-bugs-list
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
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.
--
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
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
1 - 100 of 102 matches
Mail list logo
