[issue21948] Documentation Typo
New submission from Roy: In the documentation in 15.2 (https://docs.python.org/3/library/hmac.html), under hmac.new(key, msg=None, digestmod=None), it says "Paramter digestmod", which should be "Parameter digestmod" -- messages: 222623 nosy: thosehippos priority: normal severity: normal status: open title: Documentation Typo type: enhancement versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue21948> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17113] argparse.RawDescriptionHelpFormatter should not delete blank lines
Roy Smith added the comment: It's nice to see this is still being worked on after all these years :-) I'm not actually convinced the proposed fix makes sense. It swaps out one incorrect behavior for a different incorrect behavior. If it really is more effort than it's worth to fix this (and given msg223371, I agree it probably is), then at least the original behavior makes more sense, as it's got years of history behind it and dropping an extra blank line is less arbitrary than adding an extra space. I've long since forgotten what real-world issue led me to open this, but it seems like it be easier to just document that extra trailing whitespace may not be honored. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue17113> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43371] Mock.assert_has_calls works strange
Roy Smith added the comment: I agree that this is confusing and that what we need is an assertion for the top-level mock having specific calls in a specific order, and ignores any intervening extra calls to mocked functions. In other words, a version of assert_has_calls() which looks at call_args_list instead of mock_calls. I just finished up a session of head-banging with some tests that were failing (Python 3.7), and eventually ended up with the self.assertEqual(my_mock.call_args_list, [call(...), call(...)]) idiom as noted in msg397172 (but without first banging a few new dents into the top of my desk). This exact same experience is related in a recent stackoverflow thread (https://stackoverflow.com/questions/69360318/python-unittest-mock-assert-has-calls-returning-calls-to-other-mocks) so this seems to be a common source of confusion. I am neutral on whether this is implemented as a new flag to assert_has_calls() or as a new assertion method. As an aside, what I was trying to do was test if my code constructed its several instances of a class in the correct way. At one point I hit upon the idea of: MyMockedClass().__init__.assert_has_calls() which expressed my desired logic exactly and simply, but couldn't get that to work. It's unclear if I just never found the proper incantation, or if that's fundamentally unworkable. -- nosy: +roysmith ___ Python tracker <https://bugs.python.org/issue43371> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46492] BrokenPipeError when piping to head (linux)
New submission from Roy Assis :
problem:
---
Python raises exception when piping to head. Exception is not caught by try
except.
code:
#sample.py
import sys
from time import sleep
try:
for line in sys.stdin:
print(line, flush=True)
sleep(2)
except:
print("a")
Environment:
--
# Python 3.8.12 (default, Oct 12 2021, 13:49:34)
# [GCC 7.5.0] :: Anaconda, Inc. on linux
# (scanpyEnv3.8) aaa@IP111-11-1-111:~/scripts/short-python-scripts$ uname -srm
# Linux 5.4.0-1063-aws x86_64
code execution
--
# (scanpyEnv3.8) aaa@IP111-11-1-111:~/scripts/short-python-scripts$ echo "a a a
a" | sed s'/ /\n/g' | python ./sample.py | head -3
# a
#
# a
# Exception ignored in: <_io.TextIOWrapper name='' mode='w'
encoding='utf-8'>
# BrokenPipeError: [Errno 32] Broken pipe
--
components: IO
messages: 411413
nosy: royroy
priority: normal
severity: normal
status: open
title: BrokenPipeError when piping to head (linux)
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue46492>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46492] BrokenPipeError when piping to head (linux)
Roy Assis added the comment: Resolution in this post: https://stackoverflow.com/questions/26692284/how-to-prevent-brokenpipeerror-when-doing-a-flush-in-python/26738736 code was changed to: #sample.py import sys from time import sleep try: for line in sys.stdin: print(line, flush=True) sleep(2) except: sys.stderr.close() pass -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46492> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
New submission from Roy Smith :
The docs list the arguments in the order:
class argparse.ArgumentParser([description][, epilog][, prog]...
but the code (I'm looking at the 2.7.2 source) lists them as:
class ArgumentParser(_AttributeHolder, _ActionsContainer):
[...]
def __init__(self,
prog=None,
usage=None,
description=None,
[...]
If you create a parser with just:
parser = argparse.ArgumentParser("foo")
you end up setting the 'prog' argument instead of the expected 'description'.
It's unclear if the order in the code should be fixed to match the docs, or the
order in the docs fixed to match the code, or just a note added to the docs
saying you should not rely on positional argument ordering and always create a
parser with named arguments.
--
components: Library (Lib)
messages: 146238
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse.ArgumentParser() lists arguments in the wrong order
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue13249>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: An Nth place is in the docstring: Keyword Arguments: - prog -- The name of the program (default: sys.argv[0]) - usage -- A usage message (default: auto-generated from arguments) - description -- A description of what the program does - epilog -- Text following the argument descriptions - parents -- Parsers whose arguments should be copied into this one - formatter_class -- HelpFormatter class for printing help messages - prefix_chars -- Characters that prefix optional arguments - fromfile_prefix_chars -- Characters that prefix files containing additional arguments - argument_default -- The default value for all arguments - conflict_handler -- String indicating how to handle conflicts - add_help -- Add a -h/-help option which omits 'version'. -- ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: I'm working on a doc patch now... -- ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: Patch attached. I just deal with putting all the items into the same order, not terry.reedy's idea for separating them into two groups. Added a recommendation to only use keywords, which seems sane given the number of arguments. -- keywords: +patch Added file: http://bugs.python.org/file23505/Issue13249.patch ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: PS -- this is against the 2.7 branch. -- ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: New patch uploaded. The added recommendation is around line 161 (look for 'Recommended usage is to only use keyword arguments') -- Added file: http://bugs.python.org/file23667/Issue13249-2.patch ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: Before I build another patch, would you be OK with leaving it as a note, but adding the "due to the number of arguments" language? There's a lot of text here, and people tend to just zoom in on the bits and pieces they need right now. I think there is value in making this stand out as a note. If you feel strongly this should not be a note, let me know and I'll change it. -- ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13249] argparse.ArgumentParser() lists arguments in the wrong order
Roy Smith added the comment: Another patch, with the most recent review suggestions incorporated. -- Added file: http://bugs.python.org/file23703/Issue13249-3.patch ___ Python tracker <http://bugs.python.org/issue13249> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12510] IDLE get_the_calltip mishandles raw strings
New submission from Roy Fox :
Hi,
When you type (not copy-paste!) into an IDLE shell a string literal followed by
(
you get a calltip.
When the string contains a bad unicode escaping you get an error (see example
below), which makes some sense.
But when the string is raw, it isn't treated as such, and you may get the same
error, though now it doesn't make any sense.
Non-raw example:
>>> '\xyz'(
>>> *** Internal Error: rpc.py:SocketIO.localcall()
Object: exec
Method: >
Args: ("'\\xyz'",)
Traceback (most recent call last):
File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
ret = method(*args, **kwargs)
File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
return self.calltip.fetch_tip(name)
File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
entity = self.get_entity(name)
File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
return eval(name, namespace)
File "", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 0-2: truncated \xXX escape
Raw example:
>>> r'\xyz'(
>>> *** Internal Error: rpc.py:SocketIO.localcall()
Object: exec
Method: >
Args: ("'\\xyz'",)
Traceback (most recent call last):
File "C:\Python32\lib\idlelib\rpc.py", line 188, in localcall
ret = method(*args, **kwargs)
File "C:\Python32\lib\idlelib\run.py", line 324, in get_the_calltip
return self.calltip.fetch_tip(name)
File "C:\Python32\lib\idlelib\CallTips.py", line 103, in fetch_tip
entity = self.get_entity(name)
File "C:\Python32\lib\idlelib\CallTips.py", line 112, in get_entity
return eval(name, namespace)
File "", line 1
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 0-2: truncated \xXX escape
--
components: IDLE
messages: 139961
nosy: Roy.Fox
priority: normal
severity: normal
status: open
title: IDLE get_the_calltip mishandles raw strings
type: behavior
versions: Python 3.2
___
Python tracker
<http://bugs.python.org/issue12510>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12628] urllib.request.urlopen gives empty response bodies for some sites
New submission from Roy Liu : When testing urllib.request.urlopen in Python 3, I found that it gave empty responses for some sites. In other words, reading from the file-like object gives zero bytes. Python 2.x's urllib2.urlopen did not give this behavior. I isolated the problem down to the following difference: @@ -1137,8 +1137,6 @@ r = h.getresponse() # an HTTPResponse instance except socket.error as err: raise URLError(err) -finally: -h.close() r.url = req.get_full_url() # This line replaces the .msg attribute of the HTTPResponse The "finally" clause is absent in urllib2.py but present in Python 3.2's request.py. I think it has something to do with the HTTPConnection being closed before data could be read. Still, it's puzzling because some sites still give expected answers. Please find attached a small test script for "www.wsj.com" for which the response body should be empty without applying the above patch. -- components: Extension Modules files: test.py messages: 141039 nosy: royliu priority: normal severity: normal status: open title: urllib.request.urlopen gives empty response bodies for some sites type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file22739/test.py ___ Python tracker <http://bugs.python.org/issue12628> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10473] Strange behavior for socket.timeout
New submission from Roy Smith :
While investigating issue7322, I wrote a test case to demonstrate the issue. I
made a mistake and called settimeout() on the wrong socket, but the result
appears to demonstrate a different bug. When I run the attached
test-issue7322.py on my OSX-10.6.5 machine, using...
Python 3.2a4+ (py3k:86538, Nov 19 2010, 20:52:31)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
I get the output below. The bug is that readline() is returning, even though I
never wrote a newline on the other side of the connection. If I comment out
the settimeout() call, it hangs in the readline() call, as expected.
While I admit it makes no sense to call settimeout() on the listening socket,
doing so certainly should not cause this behavior.
Note: I also tried this on Ubuntu linux (with python built from the same 3.2a4+
sources). I cannot reproduce the problem there.
issue7322$ ./test-issue7322.py
F/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed
result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed
result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/socket.py:324: ResourceWarning: unclosed
self._sock = None
==
FAIL: test_foo (__main__.Test_Issue7322)
--
Traceback (most recent call last):
File "./test-issue7322.py", line 22, in test_foo
self.fail("readline() returned '%s'" % line)
AssertionError: readline() returned 'hello'
--
Ran 1 test in 0.026s
FAILED (failures=1)
[49547 refs]
--
components: Library (Lib)
files: test-issue7322.py
messages: 121769
nosy: roysmith
priority: normal
severity: normal
status: open
title: Strange behavior for socket.timeout
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19710/test-issue7322.py
___
Python tracker
<http://bugs.python.org/issue10473>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
Roy Smith added the comment: I'm looking into this now. In the meantime, I've opened a marginally-related bug, issue10473 -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
Roy Smith added the comment: Ataching a test case which demonstrates the bug. -- Added file: http://bugs.python.org/file19711/test-issue7322.py ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10473] Strange behavior for socket.timeout
Roy Smith added the comment: Thank you for the detailed analysis. That certainly explains what I observed. Would it make sense for socket.makefile() to check to see if the socket is in blocking mode (assuming there is some reliable/portable way to perform this check), and raise some exception if it is not? -- ___ Python tracker <http://bugs.python.org/issue10473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7322] Socket timeout can cause file-like readline() method to lose data
Roy Smith added the comment: This is kind of ugly. On the one hand, I'm all for adding a check in makefile() to catch it being called on a non-blocking socket. On the other hand, you are correct that a user could change the mode leter. Even if we added checks for this in socket.setblocking(), there's plenty of ways to get around that; it's easy to grab a raw file descriptor and do whatever you want with it behind the library's back. On the third hand, maybe a check could be added to SocketIO.readinto() to verify that the socket was in blocking mode each time it was called? -- ___ Python tracker <http://bugs.python.org/issue7322> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Roy Smith added the comment: The answer depends on what the socket module is trying to do. Is the goal simply to provide a pythonic thin wrapper over the underlying OS interfaces without altering their semantics, or to provide a completely homogeneous abstraction? Having attempted the latter before, I'm aware of just how difficult a job it can be. The docs have a big bold note right up top, "Note Some behavior may be platform dependent, since calls are made to the operating system socket APIs". This is followed up by, "The platform-specific reference material for the various socket-related system calls are also a valuable source of information on the details of socket semantics." What's not clear, however, is the intent. If the intent is to hide the platform differences, then the notes in the docs are simply warnings that we're not always successful at doing that. If so, then exposing the different behaviors of listen/accept is a bug which should be fixed. Anyway, my personal opinion is that we should consider the current behavior a bug and fix it. I like the idea of setting all accepted sockets to blocking mode (and documenting it clearly). I think it is what most people would expect. I understand that this would break code of people who were relying on the "accept inherits non-blocking mode" behavior on some OS's, but I suspect the number of people who are relying on that behavior is extremely close to zero, and they are relying on a non-portable feature of a specific OS. I leave it to others to figure out which versions it is reasonable to apply this to. -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue7995> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Roy Smith added the comment: I got into this by starting with Issue7322, which reports a scenario where data is lost using makefile(). The docs for makefile() say, "The socket must be in blocking mode (it can not have a timeout)". So, we've got published documentation which equates non-blocking mode with a timeout set. -- ___ Python tracker <http://bugs.python.org/issue7995> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7995] On Mac / BSD sockets returned by accept inherit the parent's FD flags
Roy Smith added the comment: Responding to msg122013: I think he exactly meant to equate the two. The original problem described in issue882297 is that the makefile() documentation only stated that the socket could not be in non-blocking mode. The test case presented didn't appear to set non-blocking mode, it only set a timeout. The explanation by facundobatista was that setting a timeout inplies putting the socket into non-blocking mode, and the docs were updated to make this "non-blocking <==> timeout" relationship clear. -- ___ Python tracker <http://bugs.python.org/issue7995> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11073] threading.Thread documentation can be improved
New submission from Roy Smith : The documentation for the threading.Thread constructor says: "target is the callable object to be invoked by the run() method. Defaults to None, meaning nothing is called." This could be improved by explicitly stating that target is called in a static context. As written, it takes a bit of thought (and experimentation) to be sure of that. -- assignee: docs@python components: Documentation messages: 127566 nosy: docs@python, roysmith priority: normal severity: normal status: open title: threading.Thread documentation can be improved versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue11073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11073] threading.Thread documentation can be improved
Roy Smith added the comment: What I meant was whether target should be declared as @staticmethod or not. -- ___ Python tracker <http://bugs.python.org/issue11073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11073] threading.Thread documentation can be improved
Roy Smith added the comment: Here's the code I ended up writing: class Foo(): def __init__(self): self.thread = Thread(target=Foo.runner, args=[self]) self.thread.start() @staticmethod def runner(self): # blah, blah, blah It was not immediately clear from the documentation if my runner() method should be declared static or not. In retrospect, it must be (since this can be used with target functions which are not class methods at all), but it took a bit of thought to get from what the documentation said (i.e. 'callable object to be invoked by the run() method') to that conclusion. It seems to me the documentation could be a bit more explicit that your target does not get called as a method of some object. Changing the text to read, "static function or other callable object" would remove any such confusion. It could be that some of my confusion is due to my previously working with a C++ threading package where the thread runner functions *were* class methods. Still, it seems like the potential for other people to be similarly confused exists and a little tweaking of the documentation text would help. -- ___ Python tracker <http://bugs.python.org/issue11073> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3585] pkg-config support
New submission from Clinton Roy <[EMAIL PROTECTED]>: This patch adds pkg-config support to the python build, a python.pc file is installed in the pkgconfig directory such that autoconf buildsystems can trivially link against the python library. Diff made against revision 65796 -- components: Build files: pkgconfig.diff keywords: patch messages: 71305 nosy: ClintonRoy severity: normal status: open title: pkg-config support type: feature request versions: Python 2.6 Added file: http://bugs.python.org/file11142/pkgconfig.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3585] pkg-config support
Clinton Roy <[EMAIL PROTECTED]> added the comment:
Thanks for the comments Amaury, this patch uses ${VERSION} throughout so
that it can be applied across branches.
cheers,
Added file: http://bugs.python.org/file11152/pkgconfig.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3585>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3585] pkg-config support
Clinton Roy <[EMAIL PROTECTED]> added the comment: This version sets Libs.private for static compiles. Any chance this will make it into the 2.6/3.0 release candidates ? cheers, Added file: http://bugs.python.org/file11368/pkgconfig.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3891] collections.deque should have empty() method
New submission from Roy Smith <[EMAIL PROTECTED]>: Unless I'm missing something, the only way to tell if a deque is empty is to try and pop() something and catch the resulting IndexError. This is not only awkward, but mutates the data structure when you may not want to. It should be trivial to implement, and run in O(1) time. -- components: Library (Lib) messages: 73344 nosy: roysmith severity: normal status: open title: collections.deque should have empty() method type: feature request versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3891] collections.deque should have empty() method
Roy Smith <[EMAIL PROTECTED]> added the comment: I just realized my request may have been ambiguous; empty() is a predicate, not a verb. Doc should be something like: """Return true if the deque is empty. Return false otherwise.""" ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3891] collections.deque should have empty() method
Roy Smith <[EMAIL PROTECTED]> added the comment: Sigh. It looks like you can do what I want after all, by just using the deque object itself, i.e.: q = deque() while (q): ... This should be changed to a docs bug -- the doc page for deque should mention this, or include an example of this usage. It's logical that it works this way, but not entirely obvious. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3891] collections.deque should have empty() method
Roy Smith <[EMAIL PROTECTED]> added the comment: In retrospect, it's obvious that "while mydeque" is indeed the way to process the queue, yet, when I was reading the docs, I didn't come away with that. The statement, "list objects support similar operations", is wishy-washy. It is not the same as saying "deque is a subclass of list" (which isn't true), nor "the set of operations supported by deque is a superset of those supported by list" (which also isn't true). Thus, you're left having to interpret the statement as a handwave that deques are sort-of list-like things, with some (indeterminate) set of operations in common. It's not at all obvious (or at least it wasn't to me) that one of those operations is evaluating the container in a boolean context to test for emptiness. Anyway, to more concretely answer your question, I'd just make the plain statement, "An empty deque evaluates as false", somewhere right on the page where the methods are listed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3912] unittest. assertAlmostEqual() documentation incomplete
New submission from Roy Smith <[EMAIL PROTECTED]>: The third argument, places, is optional, but no indication is given what value is used if it is omitted. -- assignee: georg.brandl components: Documentation messages: 73447 nosy: georg.brandl, roysmith severity: normal status: open title: unittest. assertAlmostEqual() documentation incomplete versions: Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3912> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3891] collections.deque should have empty() method
Roy Smith <[EMAIL PROTECTED]> added the comment: I think you're missing the point. Imagine you are somebody who doesn't know Python internals. You're looking at the doc page for deque and ask yourself the question, "How do I tell if one of these is empty?". There's no information ON THAT PAGE that answers that question. Your explanation is all about "How do I compute the boolean value of a container?" The logical gap is that you need to understand that to tell if it's empty, you should compute the boolean value. You give the page on boolean operations as part of the answer, but you need to know to go look at that page in the first place. I should be able to look at the page that describes a deque and find out everything I need to know about that class on that page. Essentially, what you're saying is that deque inherits some behaviors from container, one of which being that if you convert a container to a bool, it is True iff the container is not empty. So, there should be something on the deque page which points to that information. Explicit is better than implicit :-) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3891> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1873] threading.Thread.join() description could be more explicit
New submission from Roy Smith: At http://docs.python.org/lib/thread-objects.html, under join(), it says: "As join() always returns None, you must call isAlive() to decide whether a timeout happened." This would be better if it were more explicit, i.e. "As join() always returns None, you must call isAlive() after calling join() to decide whether a timeout happened; a return value of True indicates the join() call timed out." -- components: Documentation messages: 60190 nosy: roysmith severity: minor status: open title: threading.Thread.join() description could be more explicit type: rfe versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1873> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2633] Improve subprocess.Popen() documentation ("env" parameter)
New submission from Roy Smith <[EMAIL PROTECTED]>:
http://docs.python.org/lib/node528.html (17.1.1 Using the subprocess
Module) describes the "env" parameter thusly:
If env is not None, it defines the environment variables for the new
process.
This is too vague to be useful. If it's not None, what should it be? A
dictionary in the style of os.environ? A sequence of name/value pairs? A
string with some sort of delimiter between each entry?
--
assignee: georg.brandl
components: Documentation
messages: 65480
nosy: georg.brandl, roysmith
severity: normal
status: open
title: Improve subprocess.Popen() documentation ("env" parameter)
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2633>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2634] os.execvpe() docs need to be more specific
New submission from Roy Smith <[EMAIL PROTECTED]>: Note: this is (sort of) related to Issue2633. http://docs.python.org/lib/os-process.html (14.1.5 Process Management). The docs for os.execvpe() say, "the env parameter must be a mapping which is used to define the environment variables for the new process". It's not clear if this mapping replaces the existing environment, or defines additional entries which are added to the existing environment. This should be clarified. This applies to the spawn*() methods too. -- assignee: georg.brandl components: Documentation messages: 65496 nosy: georg.brandl, roysmith severity: normal status: open title: os.execvpe() docs need to be more specific versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2634> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2639] shutil.copyfile() documentation is vague
New submission from Roy Smith <[EMAIL PROTECTED]>: The current doc says, "Copy the contents of the file named src to a file named dst". Anybody used to the unix shell "cp" command would assume that dst could be a directory, in which case the true destination is a file in that directory with the same basename as src. Experimentation shows that this is not true. A note something like the following would help: Note: unlike the "cp" shell command, dst may not be a directory; it must be a path to a file in that directory. True, there's no place in the docs which actually says a directory is valid for dst, but the name of the module is shutil, so it's reasonable for people to assume that these act the same way as the corresponding unix shell commands. It should be stated up front that this is not true, to avoid confusion. -- assignee: georg.brandl components: Documentation messages: 65521 nosy: georg.brandl, roysmith severity: normal status: open title: shutil.copyfile() documentation is vague versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2639> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2639] shutil.copyfile() documentation is vague
Roy Smith <[EMAIL PROTECTED]> added the comment: Reading closer, I see that copy() has the shell-like semantics I was expecting copyfile() to have. Perhaps the right fix is to include a note in the copyfile() docs saying, "dst must be a file path; see also copy() for a version which allows dst to be a directory". It might also make sense to move copy() to the top of the list, because it is the one which has the most shell-like semantics. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2639> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2701] csv.reader accepts string instead of file object (duck typing gone bad)
New submission from Roy Smith <[EMAIL PROTECTED]>:
If you pass csv.reader() a filename as its first argument:
csv.reader('filename')
instead of a file object like you're supposed to, you don't get an error.
You instead get a reader object which returns the characters which make up
the filename.
Technically, this is not a bug, since the documentation says, "csvfile can
be any object which supports the iterator protocol and returns a string
each time its next method is called", and a string meets that definition.
Still, this is unexpected behavior, and is almost certainly not what the
user intended. It would be useful if a way could be devised to catch this
kind of mistake.
--
components: Library (Lib)
messages: 65871
nosy: roysmith
severity: normal
status: open
title: csv.reader accepts string instead of file object (duck typing gone bad)
type: behavior
versions: Python 2.5
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2701>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4257] Documentation for socket.gethostname() needs tweaking
New submission from Roy Smith <[EMAIL PROTECTED]>: The docs say: Return a string containing the hostname of the machine where the Python interpreter is currently executing. If you want to know the current machine's IP address, you may want to use gethostbyname(gethostname()). This operation assumes... It is not clear what the referent of "This" is. Are you saying that gethostname() itself makes that assumption, or the use of gethostbyname() to turn what gethostname() returns into an address makes that assumption? I think it's the latter, but the sentence should be reworded to make it clear. -- assignee: georg.brandl components: Documentation messages: 75476 nosy: georg.brandl, roysmith severity: normal status: open title: Documentation for socket.gethostname() needs tweaking versions: Python 2.5.3 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4257> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4538] ctypes could include data type limits
New submission from Roy Smith <[EMAIL PROTECTED]>: It would be useful if ctypes included limiting constants for the various fixed-size integers, i.e. MAX_INT_32, MIN_INT_32, etc. Maybe it does and I just missed just didn't see it in the docs? -- assignee: theller components: ctypes messages: 76932 nosy: roysmith, theller severity: normal status: open title: ctypes could include data type limits type: feature request ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4538> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] Queue class should include high-water mark
New submission from Roy Smith : It would be nice if Queue.Queue included a way to access the high-water mark, i.e. the largest value which qsize() has ever reached. This is often useful when assessing application performance. I am assuming this is cheap, i.e. O(1), to provide. -- components: Library (Lib) messages: 77955 nosy: roysmith severity: normal status: open title: Queue class should include high-water mark type: feature request versions: Python 2.5.3 ___ Python tracker <http://bugs.python.org/issue4680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] Queue class should include high-water mark
Roy Smith added the comment:
I'm suppose you could implement this in a subclass, but it would be
inefficient. You'd have to over-ride put() and get(), call qsize(),
then delegate to Base.put() and Base.get().
A cleaner solution would be in the C implementation of deque, in
Modules/collectionsmodule.c. There's just a couple of places where
queue->len gets incremented. All that needs to happen is add:
if (queue->len > queue->high_water_mark) {
queue->high_water_mark = queue->len;
}
after each one and then add the appropriate accessor functions in deque
and Queue to expose it to users. The run-time cost is a couple of
machine instructions for each item added to the deque.
If I were to write the code and submit it, would you be willing to
accept it?
___
Python tracker
<http://bugs.python.org/issue4680>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Roy Smith added the comment: I'm not actually sure what the use case is for clear(). It's easy enough to just create a new deque. If you can do that, why do you need clear()? Since I don't ever see a reason anybody would want to call clear(), I'm not 100% if it should reset the high-water mark or not. I don't *think* it should, but I'm willing to believe that a use case could exist which would make me change my mind about that. Popping all the elements off the deque certainly should *not* reset the high water mark. The whole point of tracking the high water mark is to know if the consumer thread ever fell behind the producer thread (yes, I realize queues could be used for non-threading purposes). It's perfectly normal for the queue to drain completely at times, and there's absolutely no reason this should affect the high-water mark. You do raise a good question about whether all of the standard containers should be instrumented. I don't know the answer to that. Queues and, say, dicts are different beasts. It's common to use queues where the putting-in and taking-out are asynchronous, and thus the high-water mark is an indicator of overall application health. I don't see that for dicts, or lists (well, maybe if used as a stack) or most other kinds of containers. ___ Python tracker <http://bugs.python.org/issue4680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4680] deque class should include high-water mark
Roy Smith added the comment: And, FWIW, I did figure out a use case for clear(). I create a queue and pass it to two threads. One side or the other decides to abandon processing of the events currently in the queue. I can't just create a new queue, because you have no way to tell the other thread about it. You need to have clear() to do this. And, no, it should not clear the high water mark. As I see it, it comes down to this: If you bury this in the C code inside deque(), it's very efficient compared to the Python wrapper class. The downside is it makes the API larger than it would otherwise be, to satisfy a use case with limited demand. If you feel the efficiency gain doesn't justify the added complexity in the API, I'm OK with that. I just didn't want this shot down on the basis of, "He's asking us to invest the effort to write the code for something we don't see a need for", hence the offer to write it myself. But, it's your call if you want it or not. ___ Python tracker <http://bugs.python.org/issue4680> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3585] pkg-config support
Clinton Roy added the comment: Is there anything I can do to move this forward at all? cheers, ___ Python tracker <http://bugs.python.org/issue3585> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777134] minidom pretty xml output improvement
Roy Wood added the comment: This patch would be very useful to me, so I'm sad to see it's been languishing for so long. :-( Is there any way to encourage the maintainer to merge this into the current branch? -- nosy: +rrwood ___ Python tracker <http://bugs.python.org/issue1777134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1777134] minidom pretty xml output improvement
Roy Wood added the comment: Thanks! :-) On Wed, Feb 11, 2009 at 9:28 PM, Daniel Diniz wrote: > > Daniel Diniz added the comment: > > @Roy: we can try :) > > Patch updated, tests pass. However, keeping the default output and > adding an option to prettyprint should keep lots of current users sane, > while those wanting prettier output could have it. > > -- > keywords: +easy > nosy: +ajaksu2 > stage: -> patch review > type: -> feature request > versions: +Python 2.6, Python 2.7 > Added file: > http://bugs.python.org/file13042/minidom_output_improvement_v3.patch > > ___ > Python tracker > <http://bugs.python.org/issue1777134> > ___ > Added file: http://bugs.python.org/file13043/unnamed ___ Python tracker <http://bugs.python.org/issue1777134> ___Thanks! :-)On Wed, Feb 11, 2009 at 9:28 PM, Daniel Diniz <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Daniel Diniz <mailto:aja...@gmail.com";>aja...@gmail.com> added the comment: @Roy: we can try :) Patch updated, tests pass. However, keeping the default output and adding an option to prettyprint should keep lots of current users sane, while those wanting prettier output could have it. -- keywords: +easy nosy: +ajaksu2 stage: -> patch review type: -> feature request versions: +Python 2.6, Python 2.7 Added file: http://bugs.python.org/file13042/minidom_output_improvement_v3.patch"; target="_blank">http://bugs.python.org/file13042/minidom_output_improvement_v3.patch ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue1777134"; target="_blank">http://bugs.python.org/issue1777134> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38462] Typo (nam ing) in import system docs
New submission from Roy Smith : In https://docs.python.org/3.5/reference/import.html#importsystem, section "5.2 Packages", second sentence, the word "naming" is broken across two lines. In 3.7.5rc1 as well. Didn't check any others. -- assignee: docs@python components: Documentation messages: 354581 nosy: docs@python, roysmith priority: normal severity: normal status: open title: Typo (nam ing) in import system docs versions: Python 3.5 ___ Python tracker <https://bugs.python.org/issue38462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38462] Typo (nam ing) in import system docs
Roy Smith added the comment: Yeah, that's weird. Looks like this may be a Chrome bug. I'm seeing it in Chrome (Version 77.0.3865.90 (Official Build) (64-bit)), but not Safari. This is on MacOS (High Sierra). In the attached screenshot, I narrowed the window a bit. In the second paragraph, it's mis-broken "modules" and "contain", but hyphenated some other line breaks. If I diddle with the CSS and disable "hyphens: auto", it stops breaking words completely (which is probably better than breaking them wrong). I guess close this and I'll open a bug against Chrome. -- Added file: https://bugs.python.org/file48658/Screen Shot 2019-10-13 at 10.12.15 AM.jpg ___ Python tracker <https://bugs.python.org/issue38462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43873] bz2.open() docs give conflicting defaults for mode
New submission from Roy Smith : See https://docs.python.org/3.7/library/bz2.html For bz2.open(), the section header says: bz2.open(filename, mode='r' ...) but the text says: The mode argument ... The default is 'rb'. As I understand it, 'r' and 'rb' actually do the same thing, but the docs should at least be consistent. -- components: Library (Lib) messages: 391245 nosy: roysmith priority: normal severity: normal status: open title: bz2.open() docs give conflicting defaults for mode versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue43873> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24258] BZ2File objects do not have name attribute
Change by Roy Smith : -- nosy: +roysmith ___ Python tracker <https://bugs.python.org/issue24258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24258] BZ2File objects do not have name attribute
Roy Smith added the comment: The https://bitbucket.org/cliff/cpython#python24258 URL 404's Looking at the attached bz2.py diff, I would change: if isinstance(filename, (str, bytes, os.PathLike)): self._fp = _builtin_open(filename, mode) +self.filename = filename self._closefp = True self._mode = mode_code to special-case os.PathLike and do: self.filename = str(filename) I would expect BZ2File.name to be a string. Returning a PathLike means lots of legitimate string methods will not work on it. Also, it should be "name" as an attribute, not "name()" as a method, to match other existing interfaces. -- ___ Python tracker <https://bugs.python.org/issue24258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44534] unittest.mock.Mock.unsafe doc is garbled
New submission from Roy Smith : At https://docs.python.org/3.9/library/unittest.mock.html#unittest.mock.Mock, it says: unsafe: By default if any attribute starts with assert or assret will raise an AttributeError. That's not an English sentence. I think what was intended was, "By default accessing an attribute which starts with assert or assret will raise an AttributeError." -- assignee: docs@python components: Documentation messages: 396719 nosy: docs@python, roysmith priority: normal severity: normal status: open title: unittest.mock.Mock.unsafe doc is garbled versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue44534> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38462] Typo (nam ing) in import system docs
Roy Smith added the comment: Just for the archives: https://bugs.chromium.org/p/chromium/issues/detail?id=1022011 -- ___ Python tracker <https://bugs.python.org/issue38462> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16399] argparse: append action with default list adds to list instead of overriding
Roy Smith added the comment: I just got bit by this in Python 3.5.3. I get why it does this. I also get why it's impractical to change the behavior now. But, it really isn't the obvious behavior, so it should be documented at https://docs.python.org/3.5/library/argparse.html?highlight=argparse#default. -- nosy: +roysmith ___ Python tracker <https://bugs.python.org/issue16399> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35105] Document that CPython accepts "invalid" identifiers
Roy Smith added the comment:
Just as another edge case, type() can do the same thing:
Foo = type("Foo", (object,), {"a b": 1})
f = Foo()
for example, will create a class attribute named "a b". Maybe this actually
calls setattr() under the covers, but if it's going to be documented, it should
be noted in both places.
--
nosy: +roysmith
___
Python tracker
<https://bugs.python.org/issue35105>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37554] Typo in os.rename docs
New submission from Roy Wellington : The documentation for os.rename (e.g., here, https://docs.python.org/3/library/os.html#os.rename but also for 3.8 and 3.9) currently reads, > On Unix, if src is a file and dst is a directory or vice-versa, anq:q > IsADirectoryError or a NotADirectoryError will be raised respectively. That "anq:q" should probably be just "an"; it appears someone tried to quit vim ;-) -- assignee: docs@python components: Documentation messages: 347647 nosy: docs@python, roy.wellington priority: normal severity: normal status: open title: Typo in os.rename docs versions: Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue37554> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30432] FileInput doesn't accept PathLike objects for file names
New submission from Roy Williams:
```
from fileinput import FileInput
from pathlib import Path
p = Path('.')
FileInput(p)
```
Results in:
Traceback (most recent call last):
File "", line 1, in
File
"/usr/local/Cellar/python3/3.6.0/Frameworks/Python.framework/Versions/3.6/lib/python3.6/fileinput.py",
line 198, in __init__
files = tuple(files)
TypeError: 'PosixPath' object is not iterable
--
components: IO
messages: 294169
nosy: Roy Williams
priority: normal
severity: normal
status: open
title: FileInput doesn't accept PathLike objects for file names
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<http://bugs.python.org/issue30432>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30432] FileInput doesn't accept PathLike objects for file names
Changes by Roy Williams : -- pull_requests: +1822 ___ Python tracker <http://bugs.python.org/issue30432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30432] FileInput doesn't accept PathLike objects for file names
Roy Williams added the comment: @arp11 sorry for the too-minimal repro :D - the issue is with FileInput attempting to cast `files` to a tuple. Instead, if passed a PathLike object FileInput should set `files` to a tuple just as it does with a str. -- ___ Python tracker <http://bugs.python.org/issue30432> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30605] re.compile fails when compiling bytes under `-bb` mode
New submission from Roy Williams: import re re.compile(br'^(.*?)$(?m)') -- components: Regular Expressions messages: 295473 nosy: Roy Williams, ezio.melotti, mrabarnett priority: normal severity: normal status: open title: re.compile fails when compiling bytes under `-bb` mode versions: Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue30605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30605] re.compile fails when compiling bytes under `-bb` mode
Roy Williams added the comment: Repro: ``` import re re.compile(br'^(.*?)$(?m)') ``` Results in ``` Traceback (most recent call last): File "test_compile.py", line 2, in re.compile(br'^(.*?)$(?m)') File "/usr/lib/python3.6/re.py", line 233, in compile return _compile(pattern, flags) File "/usr/lib/python3.6/re.py", line 301, in _compile p = sre_compile.compile(pattern, flags) File "/usr/lib/python3.6/sre_compile.py", line 562, in compile p = sre_parse.parse(p, flags) File "/usr/lib/python3.6/sre_parse.py", line 856, in parse p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, False) File "/usr/lib/python3.6/sre_parse.py", line 415, in _parse_sub itemsappend(_parse(source, state, verbose)) File "/usr/lib/python3.6/sre_parse.py", line 741, in _parse ' (truncated)' if len(source.string) > 20 else '', BytesWarning: str() on a bytes instance ``` -- ___ Python tracker <http://bugs.python.org/issue30605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30605] re.compile fails when compiling bytes under `-bb` mode
Changes by Roy Williams : -- pull_requests: +2081 ___ Python tracker <http://bugs.python.org/issue30605> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
New submission from Roy Williams :
Repro:
```python
from pathlib import Path
import subprocess
subprocess.run([Path('/bin/ls')]) # Works Fine
subprocess.run(Path('/bin/ls')) # Fails
```
The problem seems to originate from here:
https://github.com/python/cpython/blob/master/Lib/subprocess.py#L1237-L1240
This file auspiciously avoids importing pathlib, which I'm guessing is somewhat
intentional? Would the correct fix be to check for the existence of a
`__fspath__` attribute as per https://www.python.org/dev/peps/pep-0519/ ?
--
components: Library (Lib)
messages: 305663
nosy: Roy Williams
priority: normal
severity: normal
status: open
title: subprocess._execute_child doesn't accept a single PathLike argument for
args
versions: Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue31961>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31961] subprocess._execute_child doesn't accept a single PathLike argument for args
Roy Williams added the comment: Ignore my comment re: pathlib, it looks like PathLike is defined in `os` and not `pathlib`. -- ___ Python tracker <https://bugs.python.org/issue31961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34288] Declare sethostname in socketmodule.c for SOLARIS
New submission from Roy Belio : Following issue 18259 which was solved by extern sethostname I managed to build python 3.7 on solaris only after patching away the ifdef for _AIX. We need to add SOLARIS flag and check for that also in the same line of #ifdef _AIX. This error only appears in 3.7 since a new CFLAG was turned on -Werror=no-implicit-declaration. and during build time it fails on sethostname function, not build _socket. -- components: Build messages: 322742 nosy: rbelio priority: normal severity: normal status: open title: Declare sethostname in socketmodule.c for SOLARIS type: compile error versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34288> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31710] setup.py: _ctypes won't getbuilt when system ffi is only in $PREFIX
Roy Belio added the comment: Also happens on suse 11 x86_64 with python 3.7 Same issue exactly building locally (but with cross compiling flag for system independency) Building our own libffi 3.2.1 and adding it in the CPPFLAGS includes. -- nosy: +rbelio ___ Python tracker <https://bugs.python.org/issue31710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31710] setup.py: _ctypes won't get built when system ffi is only in $PREFIX
Roy Belio added the comment: Sure, I'll attach it. one more thing to mention is that during configure it printed: configure: WARNING: --with(out)-system-ffi is ignored on this platform We are also providing all the dependency libraries ourselves (building, linking, h files and what not) so that should tkae into consideration. on Suse 11 x86 build is working fine. and we are using gcc 4.3.4 configure arguments passed: --prefix=/root/rc3/dist --enable-shared --enable-ipv6 --with-dbmliborder=gdbm --with-gcc --with-system-ffi --with-openssl=/root/rc3/dist -- Added file: https://bugs.python.org/file47728/build.log ___ Python tracker <https://bugs.python.org/issue31710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31710] setup.py: _ctypes won't get built when system ffi is only in $PREFIX
Roy Belio added the comment: as seen in the config.log: LIBFFI_INCLUDEDIR='/root/rc3/dist/lib/libffi-3.2.1/include' I'm attaching the config.log just in case -- Added file: https://bugs.python.org/file47729/config.log ___ Python tracker <https://bugs.python.org/issue31710> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34461] Availability of parsers in etree initializer
New submission from nilanjan roy : As xml package make the availability of separate global name-space by *__all__* so considerably *etree* should have included of all the parser files in its initialize(i.e. in *__init__.py*). So if any script consider as "from xml import *" then *etree* should have accessibility on all of it's parser files i.e. etree should access like *etree.ElementTree* which is not working as expected currently. Currently it's enforced to use as normal behavior as "import xml.etree.ElementTree" -- components: XML messages: 323872 nosy: nilanjan roy priority: normal severity: normal status: open title: Availability of parsers in etree initializer type: behavior versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34461] Availability of parsers in etree initializer
nilanjan roy added the comment: @scoder: *xml* package organization have little confusion 1. Current xml have exposed all the sub-packages from *__all__* scope from the initializer - so there are possibilities to write code from script a. *import xml as x* or *import xml.somepackage as x* => which is also possible even if I do not declare the sub-packages from *__all__* scope of an initializer b. as all the subpackages are available in xml initialzer scope- so this is allowed to developer to write *from xml import ** - but this flexibility will not work(which is contradictory) as each of sub-package initializer doesn't have any inclusion(which i have included in PR) Regards, -- ___ Python tracker <https://bugs.python.org/issue34461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34461] Availability of parsers in etree initializer
nilanjan roy added the comment: @serhiy.storchaka: If I concur with your comment then probably declaration of *__all__** over xml initializer(__init__) is little contradictory - because whenever we declare __all__ to enable global-scope means API provides the flexibility to use * during package import. Now this is totally depends on developer how the script need to optimize/simulate during development. Yes agree * should not be used due to high reference of memory usage. But as far __init__.py of xml and python convention this should not be explicitly restricted -- ___ Python tracker <https://bugs.python.org/issue34461> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19006] UnitTest docs should have a single list of assertions
New submission from Roy Smith: http://docs.python.org/2/library/unittest.html#assert-methods The docs say, "The TestCase class provides a number of methods to check for and report failures, such as", and then when you scroll a couple of screens down, there's another list, "There are also other methods used to perform more specific checks, such as". These should be merged into a single list. There's nothing fundamentally different about the two lists and breaking them into two parts just makes it harder to find what you want. -- assignee: docs@python components: Documentation messages: 197492 nosy: docs@python, roysmith priority: normal severity: normal status: open title: UnitTest docs should have a single list of assertions versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue19006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19006] UnitTest docs should have a single list of assertions
Roy Smith added the comment: Adding a note that there are more methods in the tables below would be useful. Otherwise, you assume you've seen them all when you've read the first table. I agree that the assertions about exceptions and warnings belong in a different group, but I don't see any fundamental reason to put assertGreater in a different table from assertEqual. -- ___ Python tracker <http://bugs.python.org/issue19006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15265] random.sample() docs unclear on k < len(population)
New submission from Roy Smith : The docs don't say what happens if you call random.sample() with a population smaller than k. Experimentally, it raises ValueError, but this should be documented. I would have guessed it would return IndexError, by analogy to random.choice(). -- assignee: docs@python components: Documentation messages: 164742 nosy: docs@python, roysmith priority: normal severity: normal status: open title: random.sample() docs unclear on k < len(population) type: enhancement ___ Python tracker <http://bugs.python.org/issue15265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15265] random.sample() docs unclear on k < len(population)
Roy Smith added the comment: The docs describe population as a "sequence". Your patch describes it as a "list". I would go with: If *len(population)* is less than *k*, raises :exc:`ValueError`. -- ___ Python tracker <http://bugs.python.org/issue15265> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15575] Tutorial is unclear on multiple imports of a module.
New submission from Roy Smith: Opening this bug at Ben Finney's request. See https://groups.google.com/forum/?fromgroups#!topic/comp.lang.python/wmDUrpW2ZCU for the full thread discussing the problem. Here's a significant excerpt: - The tutorial is misleading on this. It it says plainly: A module can contain executable statements as well as function definitions. […] They are executed only the *first* time the module is imported somewhere. http://docs.python.org/tutorial/modules.html> but it doesn't make clear that a module can exist in the ‘sys.modules’ list multiple times under different names. - Also note: -- The footnote to that is wrong too: > [1]In fact function definitions are also ‘statements’ that are > ‘executed’; the execution of a module-level function enters the function name > in the module’s global symbol table. I think what it's supposed to say is "... the execution of a module-level def statement ..." --- -- assignee: docs@python components: Documentation messages: 167628 nosy: docs@python, roysmith priority: normal severity: normal status: open title: Tutorial is unclear on multiple imports of a module. type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue15575> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Roy Smith added the comment: We need to define the scope of what input strings will be accepted. ISO-8601 defines a lot of stuff which we may not wish to accept. Do we want to accept both basic format (MMDD) and extended format (-MM-DD)? Do we want to accept things like "1985-W15-5", which is (if I understand this correctly(), the 5th day of the 15th week of 1985 [section 4.1.4.2]. Do we want to accept [section 4.2.2.4], "23:20,8", which is 23 hours, 20 minutes, 8 tenths of a minute. I suspect most people who have been following the recent thread (https://groups.google.com/d/topic/comp.lang.python/Q2w4R89Nq1w/discussion) would say none of the above are needed. All that's needed is if you have an existing datetime object, d1, you can do: s = str(d1) d2 = datetime.datetime(s) assert d1 == d2 for all values of d1. But, let's at least agree on that. Or, in the alternative, agree on something else. Then we know what we're shooting for. -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Roy Smith added the comment: I see I mis-stated my example. When I wrote: s = str(d1) d2 = datetime.datetime(s) assert d1 == d2 what I really meant was: s = d1.isoformat() d2 = datetime.datetime(s) assert d1 == d2 But, now I realize that while that is certainly an absolute lower bound, it's almost certainly not sufficient. The most common use case I see on a daily basis is parsing strings that look like "2012-09-07T23:59:59+00:00". This is also John Nagle's original use case from the cited mailing list thread: > I want to parse standard ISO date/time strings such as > 2012-09-09T18:00:00-07:00 Datetime.isoformat() returns something that matches the beginning of that, but doesn't have the time zone offset. And it's the offset that makes strptime() not usable as a soluation, because "%z" isn't portable. If we don't satisfy the "2012-09-07T23:59:59+00:00" case, then we won't have really done anything useful. -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Roy Smith added the comment: I've started collecting some test cases. I'll keep adding to the collection. I'm going to start trolling ISO 8601:2004(E) for more. Let me know if there are other sources I should be considering. -- ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15873] "datetime" cannot parse ISO 8601 dates and times
Roy Smith added the comment: Ooops, clicked the wrong button. -- Added file: http://bugs.python.org/file27165/test-cases.py ___ Python tracker <http://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16623] argparse help formatter does not honor non-breaking space
New submission from Roy Smith:
Running this code:
---
import argparse
p = argparse.ArgumentParser()
p.add_argument('--foo',
help=u'This is a very long help string. ex:
"--s3\u00A0s3://my.bucket/dir1/dir2"')
p.parse_args()
---
produces:
---
$ ./arg.py --help
usage: arg.py [-h] [--foo FOO]
optional arguments:
-h, --help show this help message and exit
--foo FOO This is a very long help string. ex: "--s3
s3://my.bucket/dir1/dir2"
---
It should not be breaking the line at a non-breaking space. I'm running:
Python 2.7.3 (default, Aug 1 2012, 05:14:39)
[GCC 4.6.3] on linux2
--
components: Library (Lib)
messages: 177012
nosy: roysmith
priority: normal
severity: normal
status: open
title: argparse help formatter does not honor non-breaking space
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue16623>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6792] Distutils-based installer does not detect 64bit versions of Python
Roy Jacobson added the comment: This bug is a really annoying one, any chance it will be fixed in 2.7? It's really a matter when you want to deploy a program using distutils (my case), because you cannot really require your clients to edit the registry themselves :/ Is there any problem with just adding the x32 compatibility path entry to the python x64 .msi? It's a very easy fix that shouldn't cause any harm. -- nosy: +Roy.Jacobson ___ Python tracker <http://bugs.python.org/issue6792> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14452] SysLogHandler sends invalid messages when using unicode
Changes by Roy Smith : -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue14452> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17113] argparse.RawDescriptionHelpFormatter should not delete blank lines
New submission from Roy Smith: The following code, when run with "--help", omits the trailing newlines from the epilog. It should just emit the string verbatim. If the developer didn't want the extra newlines, he/she wouldn't have put them there. import argparse parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter, epilog="foo\n\n") parser.parse_args() -- components: Library (Lib) messages: 181267 nosy: roysmith priority: normal severity: normal status: open title: argparse.RawDescriptionHelpFormatter should not delete blank lines type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue17113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17184] re.VERBOSE doesn't respect whitespace in '( ?P...)'
New submission from Roy Smith:
# Python 2.7.3
# Ubuntu 12.04
import re
pattern = r"( ?P.*)"
regex = re.compile(pattern, re.VERBOSE)
The above raises an exception in re.compile():
Traceback (most recent call last):
File "./try.py", line 6, in
regex = re.compile(pattern, re.VERBOSE)
File "/home/roy/env/python/lib/python2.7/re.py", line 190, in compile
return _compile(pattern, flags)
File "/home/roy/env/python/lib/python2.7/re.py", line 242, in _compile
raise error, v # invalid expression
sre_constants.error: nothing to repeat
The problem appears to be that re.VERBOSE isn't ignoring the space after the
"(".
Maybe this is a duplicate of issue15606 ?
--
components: Library (Lib)
messages: 181927
nosy: roysmith
priority: normal
severity: normal
status: open
title: re.VERBOSE doesn't respect whitespace in '( ?P...)'
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue17184>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15606] re.VERBOSE whitespace behavior not completely documented
Changes by Roy Smith : -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue15606> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11204] re module: strange behaviour of space inside {m, n}
Changes by Roy Smith : -- nosy: +roysmith ___ Python tracker <http://bugs.python.org/issue11204> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19006] UnitTest docs should have a single list of assertions
Roy Smith added the comment: The new text suggested by terry.reedy works for me. -- ___ Python tracker <http://bugs.python.org/issue19006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19416] NNTP page has incorrect links
New submission from Roy Smith: http://docs.python.org/2/library/nntplib.html contains intra-page references such as: NNTP.next() Send a NEXT command. Return as for stat(). The problem is that the link for "stat" points to the stat module (i.e. http://docs.python.org/2/library/stat.html#module-stat). It should be pointing to the NNTP.stat() entry on this page. The problem exists for : NNTP.next() NNTP.last() NNTP.head(id) NNTP.body(id[, file]) NNTP.article(id) and maybe some others I missed. -- assignee: docs@python components: Documentation messages: 201456 nosy: docs@python, roysmith priority: normal severity: normal status: open title: NNTP page has incorrect links versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue19416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
New submission from Roy Smith: https://mail.python.org/pipermail/python-list/2014-June/674188.html -- messages: 221846 nosy: roysmith priority: normal severity: normal status: open title: str.format() gives poor diagnostic on placeholder mismatch ___ Python tracker <http://bugs.python.org/issue21879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21879] str.format() gives poor diagnostic on placeholder mismatch
Roy Smith added the comment:
(ugh, hit return too soon)
>>> '{1}'.format()
Traceback (most recent call last):
File "", line 1, in
IndexError: tuple index out of range
This is a confusing error message. The user hasn't written any tuples, so a
message about a tuple index out of range will just leave them scratching their
head. We should either return a more specific subclass of IndexError, or at
least a more descriptive text describing what went wrong.
See https://mail.python.org/pipermail/python-list/2014-June/674188.html for
background.
--
type: -> behavior
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue21879>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21956] Doc files deleted from repo are not deleted from docs.python.org.
Audrey Roy added the comment: > Since it isn't linked from the 3.4 index, it may be more effort than > it is worth to get someone to delete the file from the 3.4 tree on the > server. It would be worthwhile to delete or fix it in the 2.7 and 3.4 tree. It accidentally gets linked, still causing confusion to 2.7 and 3.4 users: https://twitter.com/audreyr/status/487446878837944320 -- nosy: +audreyr ___ Python tracker <http://bugs.python.org/issue21956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21956] Doc files deleted from repo are not deleted from docs.python.org.
Audrey Roy added the comment: Mark, I and a number of others simply misinterpreted the text in that section. -- ___ Python tracker <http://bugs.python.org/issue21956> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22089] collections.MutableSet does not provide update method
New submission from Roy Wellington: Inheriting from collections.MutableSet mixes in several methods, however, it does not mix in a .update method. This can cause a variety of confusion if you expect a MutableSet to act like a set. Moreover, MutableMapping does provide a .update method, which makes me think this is a bug. I've attached a file that creates a bare-bones MutableSet, and shows the difference. Is this a bug, or is there some reason that MutableSet doesn't provide an update method? -- components: Library (Lib) files: ms.py messages: 224105 nosy: roy.wellington priority: normal severity: normal status: open title: collections.MutableSet does not provide update method versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file36125/ms.py ___ Python tracker <http://bugs.python.org/issue22089> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22167] iglob() has misleading documentation (does indeed store names internally)
New submission from Roy Smith: For background, see: https://mail.python.org/pipermail/python-list/2014-August/676291.html In a nutshell, the iglob() docs say, "Return an iterator which yields the same values as glob() without actually storing them all simultaneously." The problem is, internally, it calls os.listdir(), which apparently *does* store the entire list internally, defeating the whole purpose of iglob() I recognize that iglob() is not going to get fixed in 2.7, but at least the documentation should be updated to point out that it doesn't really do what it says it does. Or rather, it doesn't really not do what it says it doesn't :-) -- assignee: docs@python components: Documentation messages: 225048 nosy: docs@python, roysmith priority: normal severity: normal status: open title: iglob() has misleading documentation (does indeed store names internally) type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue22167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22167] iglob() has misleading documentation (does indeed store names internally)
Roy Smith added the comment: The thread that led to this started out with the use case of a directory that had 200k files in it. If I ran iglob() on that and discovered that it had internally generated a list of all 200k names in memory at the same time, I would be pretty darn surprised, based on what the docs say now. We're shooting for principle of least astonishment here. -- ___ Python tracker <http://bugs.python.org/issue22167> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
