Terry J. Reedy added the comment:
Yes, new issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
___
Python-bugs-list mailing list
New submission from Steven Barker:
While working on a fix for issue 1234674, I found that the first test method in
Lib/test/test_filecmp.py (FileCompareTestCase.test_matching) has switched up
messages in its AssertEquals calls. The first two asserts have the message that
should belong to the
STINNER Victor added the comment:
Similar(?) issue #20526:
Modules/gcmodule.c:379: visit_decref: Assertion `((gc)-gc.gc_refs (1)) !=
0' failed.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21435
Roundup Robot added the comment:
New changeset 358a12f4d4bc by Victor Stinner in branch 'default':
Issue #21233: Fix _PyObject_Alloc() when compiled with WITH_VALGRIND defined
http://hg.python.org/cpython/rev/358a12f4d4bc
--
___
Python tracker
New submission from Berker Peksag:
Since imp.reload() was deprecated in issue 18193, the reload fixer (added in
issue 11797) needs to be updated to use importlib.reload() instead of
imp.reload().
--
components: 2to3 (2.x to 3.x conversion tool)
files: reload-fixer.diff
keywords: patch
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21444
___
___
Python-bugs-list mailing list
Changes by Mark Dickinson dicki...@gmail.com:
--
title: __len__ can't return big numbers - __len__
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21444
___
Changes by Mark Dickinson dicki...@gmail.com:
--
title: __len__ - __len__ can't return big numbers
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21444
___
Mark Dickinson added the comment:
Whoops; sorry -- accidental title change by typing `__len__` into something
that wasn't the search box.
Stupid fingers...
(I suspect this issue is a duplicate of an existing issue.)
--
nosy: +mark.dickinson
___
eryksun added the comment:
Nevermind, strike seems to work; it doesn't work without the \?? prefix. I
stupidly assumed the DeviceIoControl call would validate the substitute name.
Of course it doesn't; it happily creates a broken junction. Opening the
junction with CreateFile fails with
Tim Golden added the comment:
Thanks, eryksun: failed experiments are still useful data for future
reference!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18314
___
Roundup Robot added the comment:
New changeset 4ebf97299b18 by Tim Golden in branch 'default':
Issue21440 Use support.rmtree in test_zipfile test_tarfile
http://hg.python.org/cpython/rev/4ebf97299b18
--
nosy: +python-dev
___
Python tracker
Roundup Robot added the comment:
New changeset 2b18f6c37a68 by Tim Golden in branch 'default':
Issue21393 Use CryptReleaseContext to release Crypt handle on Windows
http://hg.python.org/cpython/rev/2b18f6c37a68
--
___
Python tracker
Matthias Klose added the comment:
what happens here:
PYTHONPATH=$(pwd) python3.4 -X faulthandler -S -m compileall
Skipping current directory
Listing '/home/packages/python/3.4/x'...
Compiling '/home/packages/python/3.4/x/foo.py'...
Listing '/usr/lib/python3.4/'...
Listing
Zachary Ware added the comment:
Declaring oldsize as Py_ssize_t instead of size_t at Objects/bytesobject.c:2812
takes care of the warning, but I'm not comfortable saying that's a correct
change.
--
___
Python tracker rep...@bugs.python.org
Changes by Zachary Ware zachary.w...@gmail.com:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21442
___
___
Python-bugs-list
Tim Golden added the comment:
Use CryptReleaseContext to release Crypt handle on Windows
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21393
Changes by Tim Golden m...@timgolden.me.uk:
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21440
___
R. David Murray added the comment:
Well, it would be 3.5, so there's plenty of time yet. We are hoping for an
answer from Tim Peters, but if we don't get one someone else will review it as
time allows. Pinging the issue like this was good; do it again in another
month if there's no further
R. David Murray added the comment:
Mark: I thought it was too, but the two I noted were the closest I could find.
Maybe you'll find something even more on point :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21444
Roundup Robot added the comment:
New changeset faaa8d569664 by Zachary Ware in branch '3.4':
Issue #21366: Document the fact that ``return`` in a ``finally`` clause
http://hg.python.org/cpython/rev/faaa8d569664
New changeset 685f92aad1dc by Zachary Ware in branch 'default':
Issue #21366:
Roundup Robot added the comment:
New changeset 7fabe3652ee0 by Zachary Ware in branch '2.7':
Issue #21366: Document the fact that ``return`` in a ``finally`` clause
http://hg.python.org/cpython/rev/7fabe3652ee0
--
___
Python tracker
Zachary Ware added the comment:
Done. Thanks pointing out just how redundant that parenthetical was (I don't
know how that slipped through my brain...), David. And thank you Jon for the
report!
--
resolution: - fixed
stage: patch review - resolved
status: open - closed
versions:
Brett Cannon added the comment:
I don't think that's necessarily obvious since that will make your code tied to
Python 3.4.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21446
___
akira added the comment:
If `len()` signature can't be changed to return Python int objects (unlimited)
then the OverflowError may contain the actual `.length`
property instead (based on msg66459 by Antoine Pitrou)
operator.length():
def length(sized):
Return the true (possibly
Andreas Gäer added the comment:
Is there any progress to the question if the problem should be fixed in
os.symlink or in tarfile?
Because this currently seems to break installing source packages that contain
symlinks with pip under Windows.
Try: pip install networkx==1.8.1 for example
Yury Selivanov added the comment:
Thanks, I'll take a look at the patch.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1218234
___
___
R. David Murray added the comment:
Note that there has never been a strict correspondence between
linecache/getsource, the module in memory, and the code on disk. If the file
is changed before a traceback is generated, for example, you will get the new
source. That doesn't mean fixing the
Tim Golden added the comment:
Well PyBytes_GET_SIZE is documented as returning a Py_ssize_t so I'd say it's
perfectly valid.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21442
___
Roundup Robot added the comment:
New changeset 6234f4caba57 by Zachary Ware in branch 'default':
Issue #21442: Fix MSVC compiler warning introduced by issue21377.
http://hg.python.org/cpython/rev/6234f4caba57
--
___
Python tracker
Roundup Robot added the comment:
New changeset 6234f4caba57 by Zachary Ware in branch 'default':
Issue #21442: Fix MSVC compiler warning introduced by issue21377.
http://hg.python.org/cpython/rev/6234f4caba57
--
nosy: +python-dev
___
Python tracker
Zachary Ware added the comment:
I should have looked a little harder, thanks Tim!
--
assignee: - zach.ware
resolution: - fixed
stage: needs patch - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
Tim Golden added the comment:
To be honest I can't get excited about this one. The only sensible change is to
remove the rather specific comment about ValueError and just leave the fact
that only certain signals are valid.
Because the C code defines module-level constants on the basis of
Tim Golden added the comment:
Ok, so to move this forward we have essentially two proposals:
1) Add a remove_readonly flag
2) Add a doc example which shows how to use the onerror handler to remove a
recalcitrant file.
I'm -0.5 on (1) because it feels like Windows-specific clutter; and +0 on
Tim Golden added the comment:
Fixed by issue9291
--
resolution: - duplicate
stage: - resolved
status: open - closed
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20758
Changes by Tim Golden m...@timgolden.me.uk:
--
nosy: -tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1528593
___
___
Python-bugs-list
Changes by Ned Deily n...@acm.org:
--
nosy: +bquinlan
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21423
___
___
Python-bugs-list mailing list
New submission from Ryder Lewis:
Intermittently, when using asyncio.wait_for() with asyncio.open_connection() to
cancel the open_connection() task after a timeout period, an
asyncio.futures.InvalidStateError is raised. It seems to be a race condition,
if the open_connection() call succeeds
Ned Deily added the comment:
I don't have a *really* strong opinion against it. It's just that I find the
current plethora of configuration flags to be non-intuitive and confusing (and
there are plenty of open issues agreeing with that sentiment) and adding
another with the name
Ronald Oussoren added the comment:
I share Ned's sentiment on this. The amount of information exposed through
sysconfig is too large as it is because a lot of that information is only
useful during the built of python itself. I'm pretty sure that have been
patches in the past where users
Mark Dickinson added the comment:
That's pretty evil. :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21444
___
___
Python-bugs-list mailing
Ryder Lewis added the comment:
Another run raised a different exception,
again running ./example.py http://www.yahoo.com/
Timed out with 0.05-second timeout
HTTP header HTTP/1.0 301 Redirect
HTTP header Date: Tue, 06 May 2014 18:58:53 GMT
HTTP header Connection: close
HTTP header Via: http/1.1
Tim Golden added the comment:
In thread_nt.h:EnterNonRecursiveMutex the millisecond version (here: 2148000)
of the seconds you passed in are converted to microseconds (so: 214800).
This is then passed to condvar.h:PyCOND_TIMEDWAIT which expects a long, whose
32-bit limit is 2147483647. So
Tim Golden added the comment:
Fixed in 3.4 and later; 3.3 is no longer accepting patches
--
resolution: - fixed
stage: - resolved
status: open - closed
versions: +Python 3.4 -Python 3.3
___
Python tracker rep...@bugs.python.org
Tim Golden added the comment:
Closing, as no-one's come back after my -0 for 6 months.
--
resolution: - wont fix
stage: commit review - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5717
Tim Golden added the comment:
Zach -- you've done most of the work on the VS projects lately. Would you mind
having a look at this one to see if it's still relevant, please?
--
nosy: +zach.ware
___
Python tracker rep...@bugs.python.org
New submission from jader fabiano:
Use email.parser to catch the mime's header,when a mime has attachments the
process is consuming 100% of the CPU. And It can take until four minutes to
finish the header parser.
--
components: email
messages: 218008
nosy: barry, jader.fabiano,
R. David Murray added the comment:
Can you provide more details on how to reproduce the problem, please? For
example, a sample message and the sequence of python calls you use to parse it.
--
___
Python tracker rep...@bugs.python.org
Tim Golden added the comment:
This is essentially superseded now by the work done over on distutils-sig and
by the PyPA. (Which has included considering the differeng terminology of
installation vs other paths on Windows vs Unix).
--
resolution: - wont fix
stage: needs patch -
Changes by Ned Deily n...@acm.org:
--
nosy: +giampaolo.rodola, gvanrossum, haypo, pitrou, yselivanov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21447
___
jader fabiano added the comment:
I am openning a file and I am passing the File Descriptor to this function
Parse().parse( fp ):
This file has two attachments
Example:
self.fileDescriptor( file, 'rb')
headers = Parser().parse(self.fileDescriptor )
#Here the process starts to consume 100% of the
jader fabiano added the comment:
Sorry!
Correct line
self.fileDescriptor = open( file, 'rb')
2014-05-06 16:51 GMT-03:00 jader fabiano rep...@bugs.python.org:
jader fabiano added the comment:
I am openning a file and I am passing the File Descriptor to this function
Parse().parse( fp ):
Changes by Ned Deily n...@acm.org:
--
stage: - needs patch
title: asyncoio logging documentation clarifications. - asyncio logging
documentation clarifications
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21443
R. David Murray added the comment:
We'll need the data file as well. This is going to be a data-dependent issue.
With a 12MB body, I'm guessing there's some decoding pathology involved, which
may or may not have been already fixed in python3.
To confirm this you could use HeaderParser
jader fabiano added the comment:
No, The file has 12Mb, because It has attachments. I am going to show an
example.
You can use a file thus:
Date: Tue, May 10:27:17 6 -0300 (BRT)
From: em...@email.com.br
MIME-Version: 1.0
To: exam...@example.com
Subject:example
Content-Type: multipart/mixed;
R. David Murray added the comment:
Sorry, I was using RFC-speak. A message is divided into 'headers' and 'body',
and all of the attachments are part of the body in RFC terms. But think of it
as 'initial headers' and 'everything else'. Please either attach the full
file, and/or try your
R. David Murray added the comment:
Also to clarify: HeaderParser will *also* read the entire message, it just
won't look for MIME attachments in the 'everything else', it will just treat
the 'everything else' as arbitrary data and record it as the payload of the top
level Message object.
Zachary Ware added the comment:
Still relevant, insofar as having Perl available is relevant. That is, you
only need Perl available if you're using vanilla OpenSSL sources, not if you're
using sources pulled from svn.python.org (which most people should do, I would
think). I have never had
Guido van Rossum added the comment:
The second error is easy to explain and fix: it's a race condition between the
OS thread used to call getaddrinfo() and the main thread. The method
_write_to_self() in selector_events.py is hopelessly naive. It should probably
become something like this:
Josh Rosenberg added the comment:
Do you mean ProcessPoolExecutor? Thread based pools don't involve serialization.
It would be good for ThreadPoolExecutor to have it as well, to make it easier
to switch between executors, but only ProcessPoolExecutor is suffering from
serialization overhead.
Andreas van Cranenburgh added the comment:
Yes I did mean ProcessPoolExecutor, but indeed, it's good to have for threads
as well.
I could try to make a patch if it is likely that it would be accepted.
--
___
Python tracker rep...@bugs.python.org
Zachary Ware added the comment:
I'm good with just adding an example to the docs, along the lines of Paul's
del_rw. I think it would be better to use a more conservative example though,
something like:
def readonly_handler(rm_func, path, exc_info):
if issubclass(exc_info[0],
New submission from Josh Rosenberg:
_PyUnicode_CompareWithId is used exclusively for equality comparisons (after
all, identifiers aren't really sortable in a meaningful way; they're isolated
values, not a continuum). But because _PyUnicode_CompareWithId maintains the
general comparison
Josh Rosenberg added the comment:
I'm not a core developer, but writing the patch is usually considered helpful.
Two notes:
1. Make sure to write unit tests for any new behavior
2. I'd suggest making any such argument keyword-only; if we move closer to the
Java executor model, that means
Paul Moore added the comment:
Checking the exact error could be a bit fragile. I have a feeling I recently
saw an issue somewhere with code that stopped working on Python 3.4 because the
precise error raised for a read-only file changed. I don't recall where the
issue was, unfortunately.
Roundup Robot added the comment:
New changeset afe8c4bd3230 by Guido van Rossum in branch '3.4':
asyncio: Fix the second half of issue #21447: race in _write_to_self().
http://hg.python.org/cpython/rev/afe8c4bd3230
New changeset c0538334f4df by Guido van Rossum in branch 'default':
Merge
Matthias Klose added the comment:
so the issue here is that -L -o file is passed to the compiler, and -o is
interpreted as the library dir, and file as an input file.
To robustify, change distutils/tests/support.py to not include empty directory
names.
To fix, change configure.ac (RUNPATH)
Changes by Matthias Klose d...@debian.org:
--
stage: needs patch - patch review
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17752
___
___
Guido van Rossum added the comment:
I'm a little closer to understanding the first (more common) traceback. I can
repro it by running your demo program in a loop -- it may take a while but
occasionally I do get the same InvalidStateError.
This appears to be an example of the problem
Tim Peters added the comment:
A bit more info: recall that, when deleting a type object (for class B), the
previous (list) object's gc_next got overwritten with NULL. The new info: its
(the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to
GC_UNTRACKED, That the
eryksun added the comment:
This should be fixed in os.symlink. The Windows CreateSymbolicLink function
can't be relied on to translate slash to backslash. It only normalizes an
absolute link, or a path that's relative to the current working directory on a
drive (e.g. R:../crypto) since that's
eryksun added the comment:
For some read Sysinternals junction utility doesn't show the raw substitute
name. Microsoft's fsutil shows the actual reparse data:
C:\mklink /J Python34 C:\Program Files\Python34
Junction created for Python34 === C:\Program Files\Python34
C:\fsutil
Ned Deily added the comment:
The quotes that you removed around the DYLD_FRAMEWORK_PATH step are not needed,
at least until the rest of configure.ac and Makefile.pre.in support paths with
spaces et al. However, you missed removing the single quotes around the
DYLD_LIBRARY_PATH step here:
Changes by R. David Murray rdmur...@bitdance.com:
--
components: +email
nosy: +barry
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21300
___
___
Changes by Jesús Cea Avión j...@jcea.es:
--
nosy: +jcea
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21415
___
___
Python-bugs-list mailing list
Roundup Robot added the comment:
New changeset d994d75cce95 by R David Murray in branch '3.4':
#21300: Clean up the docs for the email policy arguments.
http://hg.python.org/cpython/rev/d994d75cce95
New changeset 63fa945119cb by R David Murray in branch 'default':
Merge: #21300: Clean up the
R. David Murray added the comment:
Thanks for the heads up.
policy.default will become the default policy eventually, but first the new
stuff has to get out of provisional status (which I expect will happen in 3.5).
I did a pass over the documentation of all of the policy arguments and
Roundup Robot added the comment:
New changeset faef1da30c6d by doko in branch '2.7':
- Issue #17752: Fix distutils tests when run from the installed location.
http://hg.python.org/cpython/rev/faef1da30c6d
--
nosy: +python-dev
___
Python tracker
Tim Peters added the comment:
Attaching a marginally cleaner version of the patch, with comments.
I think it's clear this addresses _some_ real fatal problems, but they're rare:
for a problem to show up, it has to be the case that finalize() reduces the
refcount of the current object to 0,
Tim Peters added the comment:
Oh, fudge. There are other failure modes in the test suite after I took out
the seemingly redundant incref/decref pair. Adding it back in finalize3.patch.
--
Added file: http://bugs.python.org/file35167/finalize3.patch
Guido van Rossum added the comment:
Thanks Tim! I'm not sure who should review the patch, but it's not me. :-) I've
verified that the patch stops the example program from segfaulting on OSX, and
I assume you've verified it on Windows -- that's good enough for me. We don't
see this happening
Tim Peters added the comment:
Guido, it's best if Antoine reviewed it - he wrote the relevant PEP, and the
code I'm changing. I'm sure he'll agree it's a necessary change.
About the rarity of the bug, not only do the refcounts and cyclic structure
have to be just right, we also need exactly
Palm Kevin added the comment:
Issue can be closed. I am not able to reproduce this any more...
--
resolution: - works for me
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18154
83 matches
Mail list logo
