[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[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
[issue22880] hmac.new docs show optional args incorrectly
New submission from Roy Smith: At https://docs.python.org/2/library/hmac.html, hmac.new() is shown as hmac.new(key[, msg[, digestmod]]) This implies that digestmod can only be given if msg is given. This is incorrect. Either can be given without the other. -- assignee: docs@python components: Documentation messages: 231231 nosy: docs@python, roysmith priority: normal severity: normal status: open title: hmac.new docs show optional args incorrectly versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22880 ___ ___ 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: How about something like this: Note: The current iglob() implementation is optimized for the case of many files distributed in a large directory tree. Internally, it iterates over the directory tree, and stores all the names from each directory at once. This will lead to pathologically inefficient behavior when any individual directory has a large number of files in it. -- ___ Python tracker rep...@bugs.python.org 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)
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 rep...@bugs.python.org 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 rep...@bugs.python.org http://bugs.python.org/issue22167 ___ ___ 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 rep...@bugs.python.org 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 stdin, line 1, in module
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 rep...@bugs.python.org
http://bugs.python.org/issue21879
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20769] Reload() description is unclear
New submission from Roy Smith: http://docs.python.org/2/library/functions.html#reload says: It is legal though generally not very useful to reload built-in or dynamically loaded modules, except for sys, __main__ and __builtin__. It is unclear what the except for ... part is referring to. Is it not legal to reload those modules? Or is it not very useful to reload them? -- assignee: docs@python components: Documentation messages: 212187 nosy: docs@python, roysmith priority: normal severity: normal status: open title: Reload() description is unclear versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20769 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20582] socket.getnameinfo() does not document flags
New submission from Roy Smith: http://docs.python.org/2/library/socket.html The description for getnameinfo() says, ... Depending on the settings of flags, the result can contain a fully-qualified domain name or numeric address representation in host., but does not say what to pass for flags to get those behaviors. -- assignee: docs@python components: Documentation messages: 210838 nosy: docs@python, roysmith priority: normal severity: normal status: open title: socket.getnameinfo() does not document flags versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20582] socket.getnameinfo() does not document flags
Roy Smith added the comment: What might make sense is for all of those, document the function call as taking native_flags (or something like that), with a single note at the top of the page saying, native_flags means look up the specific values in the man page and link to that note each time it's used. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20582 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20169] random module doc page has broken links
New submission from Roy Smith: On http://docs.python.org/2/library/random.html, the links to random() go to the module, not the function. Thus: Almost all module functions depend on the basic function random(), If you lick on random(), you get to http://docs.python.org/2/library/random.html#module-random This looks like the same problem as issue19416. -- assignee: docs@python components: Documentation messages: 207612 nosy: docs@python, roysmith priority: normal severity: normal status: open title: random module doc page has broken links versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20169 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20169] random module doc page has broken links
Roy Smith added the comment: Ugh, that should say, if you CLICK on random(). Really wish I was filing this from my phone so I could blame it on autocorrect. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20169 ___ ___ 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 rep...@bugs.python.org http://bugs.python.org/issue19416 ___ ___ 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: The new text suggested by terry.reedy works for me. -- ___ Python tracker rep...@bugs.python.org 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
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 rep...@bugs.python.org 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 rep...@bugs.python.org http://bugs.python.org/issue19006 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17629] Expose string width to Python
Roy Smith added the comment: I'm the guy who was searching for astral characters in msg18597. I should mention that while what I did was certainly inefficient, the database was so much slower that it didn't have any observable impact on the overall process time (a bit over 2 days to insert approximately 200 million rows) I see this has already been closed, but figured I should record my observation for the historical record. -- nosy: +roysmith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17629] Expose string width to Python
Roy Smith added the comment: Um, make that msg185972. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17629 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17341] Poor error message when compiling invalid regex
New submission from Roy Smith:
re.compile('(?P=foo)')
Traceback (most recent call last):
File stdin, line 1, in module
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: bad character in group name
The error here is that I put a = where it shouldn't be. The error message is
misleading. The group name is the stuff between the 's. That part's fine.
What's broken is the stuff outside of the 's.
Unclear if it's reasonable to expect such precise error reporting here, but
this one seems particularly misleading, so opening a ticket to record the
observation.
--
components: Regular Expressions
messages: 183375
nosy: ezio.melotti, mrabarnett, roysmith
priority: normal
severity: normal
status: open
title: Poor error message when compiling invalid regex
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17341
___
___
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 '( ?Pfoo...)'
New submission from Roy Smith: # Python 2.7.3 # Ubuntu 12.04 import re pattern = r( ?Pphrase.*) 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 module 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 '( ?Pfoo...)' type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org 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 r...@panix.com: -- nosy: +roysmith ___ Python tracker rep...@bugs.python.org 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 r...@panix.com: -- nosy: +roysmith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11204 ___ ___ 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 rep...@bugs.python.org http://bugs.python.org/issue17113 ___ ___ 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 r...@panix.com: -- nosy: +roysmith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14452 ___ ___ 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 rep...@bugs.python.org
http://bugs.python.org/issue16623
___
___
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 rep...@bugs.python.org 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 rep...@bugs.python.org 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: 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 rep...@bugs.python.org 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 rep...@bugs.python.org http://bugs.python.org/issue15873 ___ ___ 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. URL: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 rep...@bugs.python.org http://bugs.python.org/issue15575 ___ ___ 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 r...@panix.com 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 rep...@bugs.python.org 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)
New submission from Roy Smith r...@panix.com: 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 rep...@bugs.python.org http://bugs.python.org/issue15265 ___ ___ 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 r...@panix.com added the comment: Another patch, with the most recent review suggestions incorporated. -- Added file: http://bugs.python.org/file23703/Issue13249-3.patch ___ Python tracker rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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
New submission from Roy Smith r...@panix.com: 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com added the comment: I'm working on a doc patch now... -- ___ Python tracker rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com added the comment: PS -- this is against the 2.7 branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13249 ___ ___ 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 r...@panix.com 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 rep...@bugs.python.org 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
New submission from Roy Smith r...@panix.com: 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 rep...@bugs.python.org 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 r...@panix.com added the comment: What I meant was whether target should be declared as @staticmethod or not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11073 ___ ___ 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org http://bugs.python.org/issue7995 ___ ___ 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 r...@panix.com: 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 socket.socket object, fd=3, family=2, type=1, proto=0 result.addFailure(self, sys.exc_info()) /Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed socket.socket object, fd=4, family=2, type=1, proto=0 result.addFailure(self, sys.exc_info()) /Users/roy/python/py3k/Lib/socket.py:324: ResourceWarning: unclosed socket.socket object, fd=5, family=2, type=1, proto=0 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 rep...@bugs.python.org 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 r...@panix.com added the comment: I'm looking into this now. In the meantime, I've opened a marginally-related bug, issue10473 -- nosy: +roysmith ___ Python tracker rep...@bugs.python.org 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 r...@panix.com added the comment: Ataching a test case which demonstrates the bug. -- Added file: http://bugs.python.org/file19711/test-issue7322.py ___ Python tracker rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org http://bugs.python.org/issue7322 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7325] tempfile.mkdtemp() does not return absolute pathname when dir is specified
New submission from Roy Smith r...@panix.com: The docs (http://www.python.org/doc/2.5.1/lib/module-tempfile.html) specify that mkdtemp(), returns the absolute pathname of the new directory. It does that in the default case, but if you specify a relative path for 'dir', you get back a relative path. $ python Python 2.5.1 (r251:54863, Oct 17 2008, 14:39:09) [GCC 3.4.6 20060404 (Red Hat 3.4.6-10)] on linux2 Type help, copyright, credits or license for more information. import tempfile tempfile.mkdtemp(dir='.') './tmpHk1pBD' similar results were obtained on: Python 2.5.1 (r251:54863, Feb 6 2009, 19:02:12) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Note that mkstemp() gets it right: tempfile.mkdtemp(dir='.') './tmpoPXdL7' tempfile.mkstemp(dir='.') (3, '/Users/roy2/tmpwTGZ2y') -- components: Library (Lib) messages: 95256 nosy: roysmith severity: normal status: open title: tempfile.mkdtemp() does not return absolute pathname when dir is specified type: behavior versions: Python 2.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7325 ___ ___ 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 r...@panix.com 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 rep...@bugs.python.org
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 r...@panix.com 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 rep...@bugs.python.org 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 r...@panix.com 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 rep...@bugs.python.org 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
New submission from Roy Smith r...@panix.com: 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 rep...@bugs.python.org http://bugs.python.org/issue4680 ___ ___ 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
[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
[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
[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
[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
[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
[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
[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
