New submission from Steven Barker <blckkn...@gmail.com>:
While investigating a Stack Overflow question (here:
https://stackoverflow.com/q/46529767/1405065), I found that there may be a race
condition in the cleanup code for concurrent.futures.ThreadPoolIterator. The
behavior in
Steven Barker added the comment:
A few weeks ago I reported issue 27389 which looks to be a duplicate of this
issue. Has any progress been made on this issue?
--
nosy: +Steven.Barker
___
Python tracker <rep...@bugs.python.org>
Steven Barker added the comment:
Yes, this looks to be a duplicate of that issue. I'm closing this issue as a
duplicate, but I don't seem to be able to set the Superseder field. If you can,
please set that to Issue 2786.
--
resolution: -> duplicate
status: open ->
New submission from Steven Barker:
When a method is called with incorrect arguments (too many or too few, for
instance), a TypeError is raised. The message in the TypeError generally of the
form:
foo() takes 2 positional arguments but 3 were given
I think the message should include
Changes by Steven Barker <blckkn...@gmail.com>:
Added file: http://bugs.python.org/file43372/Python 3.5.2rc1
(64-bit)_20160613002148_008_launcher_AllUsers.log
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven Barker <blckkn...@gmail.com>:
Added file: http://bugs.python.org/file43371/Python 3.5.2rc1
(64-bit)_20160613002950.log
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Steven Barker added the comment:
I've just encountered this error when trying to update to the 3.5.2rc1 release
(64-bit Python, Windows 10). I'd already had the 3.5.1 release installed, so I
suppose it could have been an issue with the older installer trying to
uninstall the old version.
I
New submission from Steven Barker:
The C implementation of `_random.Random.getrandbits` is unnecessarily limited
in the number of bits it can produce on 64-bit Windows systems. I learned about
this issue in discussion of my answer to this stack overflow question:
http://stackoverflow.com
Steven Barker added the comment:
The problem being discussed here just came up on Stack Overflow today:
http://stackoverflow.com/questions/37288135/inspect-module-for-python/
The cause of the incorrect error message is pretty clear. The relevant code
from `inspect.getfile` should do something
Steven Barker added the comment:
Thanks for looking at the issue Brett.
I think you're right that your patch has incorrect semantics, since it doesn't
save the value to the provided namespace if it had to go through the special
path to find the name. I think my patch got that part right
Steven Barker added the comment:
I've managed to partially fix my build environment, so I can verify that my
patch (attached previously) works as intended. I'm not completely sure that it
doesn't break unrelated things as my build still has lots of failing tests
(which all appear
Steven Barker added the comment:
I was looking over some of the bugs I've contributed to, and it looks like this
one has been fixed. It should be marked as a dupe of issue 22161 and closed (I
can close, but not set a superseder, it seems).
--
resolution: - duplicate
status: open
Steven Barker added the comment:
I've finally gotten around to looking into this issue and it turns out that
fixing from package import * to work with circular imports is pretty easy, as
all that needs to be done is apply the same logic from the patch for issue
17636 to the loop in the next
New submission from Steven Barker:
The documentation for the csv.writer.writerows method says that it expects a
list of row objects, when it really will accept any iterable that yields rows
(such as a generator). While it's often nice for code to be more accepting than
the documented
Steven Barker added the comment:
Another Stack Overflow user pointed out that the DictWriter's writerows
implementation (in pure Python) unnecessarily converts whatever its argument is
into a list in memory before passing it on to the builtin writer.writerows
method which would accept any
Steven Barker added the comment:
This issue is a special case of the problem discussed in issue 992389, that
modules within packages are not added to the package dictionary until they are
fully loaded, which breaks circular imports in the form from package import
module.
The consensus
Steven Barker added the comment:
OK, I've written some tests of the new bound method repr functionality, which
I'm attaching as a patch against the current tip.
I test the basic repr output, all the cases the old code got wrong (inherited
methods, overridden methods, methods called via super
Steven Barker added the comment:
I've worked on this filecmp issue some more, and I have some new patches.
First up is a patch that only modifies the tests. It has one test that fails
without the behavior patch. The test patch also modifies some other tests so
that they will work after
Changes by Steven Barker blckkn...@gmail.com:
Added file: http://bugs.python.org/file36239/filecmp_behavior_and_doc_fix.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue1234674
Steven Barker added the comment:
I think that your test patch misses the confusing/possibly wrong case. That
case is when two files have the same contents, but different mtimes. If you
attempt a shallow comparison, you'll actually get a deep comparison (reading
the whole files) and a result
Steven Barker added the comment:
The behavior of !s with the format() methods isn't exactly the same as %s with
% formatting. With the latter, the conversion depends on the type of the result
string, which in turn depends on whether the format string *or any of the
values values* is unicode
Steven Barker added the comment:
Here's a patch that changes the behavior of method_repr in
Objects/classobject.c . It first tries to use __func__.__qualname__, then tries
__func__.__name__ as a fallback and finally uses ? if neither of those
attributes are available.
I'm not sure
Steven Barker added the comment:
Ah, I figured out why using %R may be bad. It breaks for the following silly
class:
class C():
def __repr__(self):
return repr(self.__repr__) # or use any other bound method
repr(C()) will recurse until the recursion limit is hit, both
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
Steven Barker added the comment:
Here's a patch against the default branch that fixes filecmp.cmp's behavior
when shallow is True, including an update to the module's docs (correcting
the previous ambiguity discussed in the 2011 python-dev thread mentioned by
Sandro Tosi) and a couple of new
New submission from Steven Barker:
The repr of bound method objects can be misleading in certain situations. The
repr is always is of the format:
bound method x.y of object
But x is often incorrect.
Here are some examples where the current code gets it wrong:
# inherited method
Steven Barker added the comment:
A recent Stack Overflow question (http://stackoverflow.com/q/23192359/1405065)
relates to this bug. The questioner was surprised that filecmp.cmp is much
slower than usual for certain large files, despite the shallow parameter
being True.
It is pretty clear
New submission from Steven Barker:
Pasting multiple lines of input and then pressing Enter when IDLE is waiting to
read a single line (such as when input() or sys.stdin.readline() have been
called) will result is a multi-line string being given as the input, rather
than a single line
New submission from Steven Barker:
While investigating a Stack Overflow question
(http://stackoverflow.com/questions/16484764/multiprocessing-value-clear-syntax)
I came across a misleading error message from the multiprocessing.Value
constructor:
import multiprocessing
my_char = x
v
Changes by Steven Barker blckkn...@gmail.com:
--
components: +ctypes -Library (Lib)
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17991
30 matches
Mail list logo
