[issue27504] Missing assertion methods in unittest documentation
Mitchell Model added the comment: My strong apology. I missed a section of the documentation. It didn't seem possible that they weren't there, but I made a mistake when I checked for them. Sorry. > On Jul 12, 2016, at 9:15 PM, R. David Murray <rep...@bugs.python.org> wrote: > > > R. David Murray added the comment: > > If you are looking at the source, you can look at the source. If you are > looking at the documentation, we believe they are all documented. If you use > pydoc/help, they are all documented. > > I can't find the phrase you cite, but 'assert methods' is correct: all of the > method names start with the word 'assert'. > > If there are specific methods you think are *not* in the library reference > that you think should be, please give examples. I suspect they will turn out > to be internal helper functions. > > -- > nosy: +r.david.murray > > ___ > Python tracker <rep...@bugs.python.org> > <http://bugs.python.org/issue27504> > ___ -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27504] Missing assertion methods in unittest documentation
New submission from Mitchell Model: In looking at the source for unittest.TestCase I was very surprised to see quite a few assertion methods that are not included in the module documentation. Every available assertion method should be included in the library documentation. Users should not have to look at the source to see what's available — in fact, why would it even occur to the typical user to do that? Also, I think the phrase "provides several assert methods to check for and report failures" is an understatement — it provides MANY assert methods. I think "assertion method" is a better term than "assert method". -- assignee: docs@python components: Documentation messages: 270278 nosy: MLModel, docs@python priority: normal severity: normal status: open title: Missing assertion methods in unittest documentation type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27504> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20077] Format of TypeError differs between comparison and arithmetic operators
Mitchell Model added the comment: Patch looks good to me. I like the choice to drop the parens. This is my first time reviewing a change; did I go through the right mechanics? I clicked Review on the issue's patch, looked at the diff, and a published a message similar to this one. Was I supposed to do something else? Is that message what Review is looking for? Was the Please review directed at me? Am I supposed to make a comment like looks good here? do something else? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20103] Documentation of itertools.accumulate is confused
New submission from Mitchell Model: The documentation of itertools.accumulate (10.1) starts out with 2 misleading sentences: Make an iterator that returns accumulated sums. Elements may be any addable type... It then goes on to show examples of using the func parameter added in 3.3 that are not additions. It should be changed to something like: Make an iterator that returns accumulated values. Elements may be any type that can be an argument to func. Func defaults to addition, so by default elements can be any addable types, ... My wording is awkward, but you get the idea. I think this is a significant documentation issue, not just a nit. -- assignee: docs@python components: Documentation messages: 207135 nosy: MLModel, docs@python priority: normal severity: normal status: open title: Documentation of itertools.accumulate is confused versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20103 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20090] slight ambiguity in README.txt instructions for building docs
New submission from Mitchell Model: I tried to build the docs for v3.4.0b1 following the instructions in the Doc/README.txt. My default python is v3.3. I got the following error message: Error: Sphinx needs to be executed with Python 2.4 or newer (not 3.0 though). I wondered what was weird about 3.0 as opposed to later versions that it wouldn't work. Fortunately I had run into other situations where tools expected Python 2 but wouldn't work with Python 3, so after a few minutes of head scratching I tried using Python 2, whi Sphinx needs to be executed with Python 2 (v. 2.4 or newer), not Python 3 so that it makes clear that it requires Python 2 not Python 3 and puts the grammatical emphasis where it belongs. More importantly, perhaps, the Doc README should be changed to state that make must use Python 2. -- assignee: docs@python components: Build, Documentation messages: 207029 nosy: MLModel, docs@python priority: normal severity: normal status: open title: slight ambiguity in README.txt instructions for building docs versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20090 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20091] An index entery for __main__ in 30.5 runpy is missing
New submission from Mitchell Model: An index entry should be added for __main__ as it appears in the documentation of runpy (30.5 in 3.3, 31.5 in 3.4). -- assignee: docs@python components: Documentation messages: 207030 nosy: MLModel, docs@python priority: normal severity: normal status: open title: An index entery for __main__ in 30.5 runpy is missing versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20091 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20077] Format of TypeError differs between comparison and arithmetic operators
New submission from Mitchell Model: [ctypes correct component for this?] The TypeError messages given for incompatible types in comparison operators differ from incompatible types in arithmetic operators. The arithmetic operator error messages show the names of the types in single quotes, while the comparison error messages do not use quotes but follow the name of the type with a pair of parens. Seems like these should be analogous. class foo(): pass ... foo() + 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: unsupported operand type(s) for +: 'foo' and 'int' foo() 1 Traceback (most recent call last): File stdin, line 1, in module TypeError: unorderable types: foo() int() -- components: ctypes messages: 206977 nosy: MLModel priority: normal severity: normal status: open title: Format of TypeError differs between comparison and arithmetic operators type: behavior versions: Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20077 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20060] float() and int() TypeError messages differ
New submission from Mitchell Model: [Sorry if ctypes is wrong component -- don't know which to use.] Given an invalid type, int()'s TypeError message includes the name of the invalid type, but float()'s doesn't. (Nor does complex()'s.) All three should give analogous error messages. int()'s version, with the name of the offending type, seems better. -- components: ctypes messages: 206892 nosy: MLModel priority: normal severity: normal status: open title: float() and int() TypeError messages differ versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20060 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8491] Need readline command and keybinding information
Mitchell Model added the comment: Ping. I just noticed that this is still unresolved in the Python 3.3 docs. This should be closed, with or without my suggested change. -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6057] sqlite3 error classes should be documented
Mitchell Model added the comment: I still think the Exception class hierarchy should be described in the sqlite3 module documentation. Someone should decide one way or another and close this issue. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11337] Nothing refers to footnote [1] on page 6. Simple Statements in Language Reference
New submission from Mitchell Model m...@acm.org: I can't find a reference to footnote [1] on page 6. Simple Statements in Language Reference. Either the footnote should be removed or a [1] link to it should appear on the page. -- assignee: docs@python components: Documentation messages: 129584 nosy: MLModel, docs@python priority: normal severity: normal status: open title: Nothing refers to footnote [1] on page 6. Simple Statements in Language Reference versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11337 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10733] plistlib rejects strings containing control characters
Mitchell Model m...@acm.org added the comment: Thanks for letting me know (and with a personalized message, yet!). I wasn't paying attention -- i verified that the problem exists in 2.7 and 3.1 and I just dragged 3.1 down to 2.6. Although I've been working furiously in Python for the past six months, I haven't been writing or teaching so I haven't been combing the documentation or testing examples or using obscure or forgotten features, which together are the source of nearly all my bug reports. So I just automatically did what I used to do. I understand the issue and difference; I just didn't realize 2.6 was closed -- I didn't really mean that this should be fixed in anything other than the current or even next release of anything. On Dec 24, 2010, at 3:36 PM, Terry J. Reedy wrote: Terry J. Reedy tjre...@udel.edu added the comment: Mitchell: 2.6 is closed to revision except for security issues -- nosy: +terry.reedy resolution: wont fix - versions: +Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10733 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10733] plistlib rejects strings containing control characters
New submission from Mitchell Model m...@acm.org: plistlib rejects control characters found in XML plists that Apple's 'plutil lint' accepts. I have attached my Terminal preferences as an example. (plistlib accepts the contents of the default Terminal preferences file) -- assignee: ronaldoussoren components: Library (Lib), Macintosh files: com.apple.Terminal.plist messages: 124311 nosy: MLModel, ronaldoussoren priority: normal severity: normal status: open title: plistlib rejects strings containing control characters type: behavior versions: Python 2.6, Python 2.7, Python 3.1 Added file: http://bugs.python.org/file20104/com.apple.Terminal.plist ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10733] plistlib rejects strings containing control characters
Mitchell Model m...@acm.org added the comment: I can see where that does make it tricky. (I also tried reading the plist after opening the file as binary, but no luck.) The problem here, of course, is that the only reason for the existence of this library is to read Apple's plist files, however XML-invalid some may be. (It is only a small number of my very many .plist files that have invalid characters -- I just happened to pick one of them to try to access in order to print a simple summary of its contents.) I guess since the plist is read using xml.parsers.expat, there's not much that can be done, and it wouldn't be worth anyone's time to hack around this for plistlib, especially since nearly all .plist files appear to be conforming. Thanks for the clarification. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10733 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8491] Need readline command and keybinding information
Mitchell Model m...@acm.org added the comment: On Aug 5, 2010, at 3:48 PM, Terry J. Reedy wrote: Terry J. Reedy tjre...@udel.edu added the comment: Can you suggest a specific link and a specific location where to add it? I would add a sentence to the first paragraph of the readline doc: Readline keybindings may be configured via an initialization file, typically .inputrc in your home directory; see http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC9 (or http://www.gnu.org/software/bash/manual/html_node/Readline-Init-File.html) for information about the format and allowable constructs of that file and the capabilities of the readline library in general. I did a few quick tests and convinced myself that the module's C code's call to rl_initialize actually reads .inputrc (or the value of the environment variable INPUTRC if that is set). -- assignee: georg.brandl - d...@python nosy: +d...@python, terry.reedy versions: -Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8491 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9562] Slightly misleading wording in documentation of dict.update
New submission from Mitchell Model m...@acm.org: The documentation of dict.update says that it accepts either another dictionary object or an iterable of key/value pairs (as a tuple or other iterable of length two) The parenthesized phrase is slightly misleading in that it could be interpreted as requiring the argument to be an iterable of length two, whereas the argument should be an iterable of iterables of length 2 (if not a dictionary). Suggest rewriting in the plural: (as tuples or other iterables of length two) -- assignee: d...@python components: Documentation messages: 113557 nosy: MLModel, d...@python priority: normal severity: normal status: open title: Slightly misleading wording in documentation of dict.update versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9562 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8491] Need readline command and keybinding information
New submission from Mitchell Model m...@acm.org: The documentation of the readline module refers to readline initialization files, but does not give any information about their format or the available commands. I realize that this is a standard part of environments that support readline, not anything specific to Python, but as long as the module documentations mentions the init file it should give a link to documentation about it. -- assignee: georg.brandl components: Documentation messages: 103902 nosy: MLModel, georg.brandl severity: normal status: open title: Need readline command and keybinding information versions: Python 2.6, Python 2.7, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8491 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8492] Addition to readline module to get dictionary of keystrokes and commands
New submission from Mitchell Model m...@acm.org: Requesting a function to be added to the readline module that produces a dictionary of the current keystroke bindings Also, one to write it to a file in readline init file format. This would be a big help for people interested in customizing the behavior of readline inside Python. -- components: Library (Lib) messages: 103905 nosy: MLModel severity: normal status: open title: Addition to readline module to get dictionary of keystrokes and commands type: feature request versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8492 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8172] Documentation of Property needs example
New submission from Mitchell Model m...@acm.org: Strangely, the extensive documentation of the property function in the Built-in Functions of the documentation has no example of the use of a property. Readers unfamiliar with properties should be told that obj.x invokes the getter, obj.x=value the setter, etc. The lack of parentheses is particularly significant. -- assignee: georg.brandl components: Documentation messages: 101262 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of Property needs example versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8172 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8077] cgi handling of POSTed files is broken
New submission from Mitchell Model m...@acm.org: I am reluctant to post this because (a) I might have made some dumb mistake in my code, simple as it is, and (b) the problem might be well-known or even hopeless because the cgi module may not be WSGI compliant, but if this isn't going to be fixed then at least the problem should be described in the cgi module documentation. I run an HTTPServer with a CGIHTTPRequestHandler. I open an HTML file with a trivial form that simply POSTs an upload of a single file. I browse, select a file, and click submit. The web request never completes -- the browser just waits for a response. Interrupting the server with ^C^C produces a backtrace that indicates it is stuck trying to decode the file contents. The attached zip file contains: cgi-server.py cgi-post.html cgi-bin/cgi-test.py exception.txt The latter is the backtrace output from when I interrupt the server. This is on OS X 10.5 with either Python3.1 or Python3.2 from the repository. -- assignee: georg.brandl components: Documentation, Library (Lib) files: cgi-post-broken.zip messages: 100509 nosy: MLModel, georg.brandl severity: normal status: open title: cgi handling of POSTed files is broken type: behavior versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file16465/cgi-post-broken.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8077 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4440] sort command doesn't work in pstats if run interactively
Mitchell Model m...@acm.org added the comment: Still true in 3.1 -- nosy: +MLModel versions: +Python 3.1 -Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4440 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7781] interactive pstats broken
New submission from Mitchell Model m...@acm.org:
I created a profile file, started up python3 -m pstats myfilename, did strip,
then stats 10 and got:
stats 10
Mon Jan 25 17:58:39 2010cd.profile
17529566 function calls (17528644 primitive calls) in 88.626 CPU
seconds
Traceback (most recent call last):
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/runpy.py,
line 128, in _run_module_as_main
__main__, fname, loader, pkg_name)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/runpy.py,
line 34, in _run_code
exec(code, run_globals)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 689, in module
browser.cmdloop()
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/cmd.py, line
139, in cmdloop
stop = self.onecmd(line)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/cmd.py, line
216, in onecmd
return func(arg)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 665, in do_stats
return self.generic('print_stats', line)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 586, in generic
getattr(self.stats, fn)(*processed)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 358, in print_stats
width, list = self.get_print_list(amount)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 331, in get_print_list
list, msg = self.eval_print_amount(selection, list, msg)
File
/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pstats.py,
line 314, in eval_print_amount
new_list = list[:count]
TypeError: 'dict_keys' object is not subscriptable
--
components: Library (Lib)
messages: 98304
nosy: MLModel
severity: normal
status: open
title: interactive pstats broken
versions: Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7781
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7488] Mac/README continues to refer to 2.6, not 3
New submission from Mitchell Model m...@acm.org: The file Mac/README in the Subversion source continues to refer to 2.6, not the appropriate version of 3. -- components: Build messages: 96316 nosy: MLModel severity: normal status: open title: Mac/README continues to refer to 2.6, not 3 versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7489] OS X binary installer for 3.1.1 missing from http://www.python.org/download/
New submission from Mitchell Model m...@acm.org: Is there some reason the OS X installer is missing from http://www.python.org/download/ but present on http://www.python.org/download/releases/3.1.1/? Seems it should be in both places. -- components: None messages: 96317 nosy: MLModel severity: normal status: open title: OS X binary installer for 3.1.1 missing from http://www.python.org/download/ versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7226] IDLE right-clicks don't work on Mac OS 10.5
New submission from Mitchell Model m...@acm.org: I'm sure this has been reported before, by I can't find it. Right button clicks do nothing on Mac OS X -- they don't go to the line of a traceback, and in debug mode they don't pop up the breakpoint menu. -- assignee: ronaldoussoren components: IDLE, Macintosh messages: 94598 nosy: MLModel, ronaldoussoren severity: normal status: open title: IDLE right-clicks don't work on Mac OS 10.5 versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7226 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6935] Version updates needed in tutorial
New submission from Mitchell Model m...@acm.org: Footnote 1 in section 2.1 of the Tutorial and the example of invoking Python in the middle of the page need their version number upped to 3.2 in both the invocation and the greeting. The same page in the 3.1 documentation should have the 'a' removed from the version number in the greeting. -- assignee: georg.brandl components: Documentation messages: 92798 nosy: MLModel, georg.brandl severity: normal status: open title: Version updates needed in tutorial versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6935 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6936] Import needed to quit Python?
New submission from Mitchell Model m...@acm.org: Section 2.1 of the tutorial describes using import sys; sys.exit() if ^D or ^Z doesn't work. However, both quit() and exit() work, as documented in the Built-in Constants section of the Library documentation. Is there something about them that should be hidden from the ordinary user that they aren't used in place of the import sys; sys.exit() combination? Seems easier to just say use quit() or exit(), especially for beginners following the tutorial who won't know what import or sys are, or even the dot notation. -- assignee: georg.brandl components: Documentation messages: 92799 nosy: MLModel, georg.brandl severity: normal status: open title: Import needed to quit Python? versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6903] pdb - print in for iteration prints None after printing
Mitchell Model m...@acm.org added the comment: No problem with the None's -- I see your point about that. Just that maybe the alias example should point out that the Nones will be printed so people won't be surprised and try to figure out what's wrong. --- Mitchell On Sep 16, 2009, at 5:56 AM, Georg Brandl wrote: Georg Brandl ge...@python.org added the comment: This is caused by the special displayhook that pdb uses. Normally, the displayhook suppresses output when it would print None; this is not done in pdb's displayhook. This was a conscious decision, because it can remove confusion when you try to get variable values like this: (Pdb) foo (Pdb) I'll ask python-dev for what is preferred. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6903 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6910] 1-char typo in language reference doc of import
New submission from Mitchell Model m...@acm.org: Just before 6.11.1 of the Language Reference: Attempting to use it in class for function definitions should be or not for -- assignee: georg.brandl components: Documentation messages: 92614 nosy: MLModel, georg.brandl severity: normal status: open title: 1-char typo in language reference doc of import versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6910 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6903] pdb - print in for iteration prints None after printing
New submission from Mitchell Model m...@acm.org: Near the bottom of the library documentation for pdb there is an example of a very useful alias: alias pi for k in %1.__dict__.keys(): print(%1.,k,=,%1.__dict__[k]) It turns out that doing print in a for loop in pdb results in None being printed on a line after each print. For example: (Pdb) for n in range(3): print(n) 0 None 1 None 2 None (Pdb) Seems like a (minor) bug, but if not, the example should be removed or replaced in the documentation. -- assignee: georg.brandl components: Documentation, Library (Lib) messages: 92588 nosy: MLModel, georg.brandl severity: normal status: open title: pdb - print in for iteration prints None after printing versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6885] pdb documentation shows running as script using python not python3
New submission from Mitchell Model m...@acm.org: The library documentation page for pdb shows running pdb as a script using the command python -m pdb Shouldn't that be python3 -m pdb ? -- assignee: georg.brandl components: Documentation messages: 92515 nosy: MLModel, georg.brandl severity: normal status: open title: pdb documentation shows running as script using python not python3 versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6885 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6886] cgi.py runs python, not python3
New submission from Mitchell Model m...@acm.org: The file cgi.py in the lib directory is an executable beginning with the line: #! /usr/local/bin/python Shouldn't that be python3? -- components: Library (Lib) messages: 92517 nosy: MLModel severity: normal status: open title: cgi.py runs python, not python3 versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6886 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6887] executables in lib use /usr/bin/env python, not python3
New submission from Mitchell Model m...@acm.org: Some of the executables in lib begin with the line: #! /usr/bin/env python Shouldn't that be python3? -- components: Library (Lib) messages: 92518 nosy: MLModel severity: normal status: open title: executables in lib use /usr/bin/env python, not python3 versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6887 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6888] pdb alias command with no arguments is broken
New submission from Mitchell Model m...@acm.org: Typing just alias in pdb doesn't work. Because dict.keys() now returns a dict_keys object instead of a list the line keys.sort() in Pdb.do_alias breaks because dict_keys doesn't have a sort method. -- components: Library (Lib) messages: 92522 nosy: MLModel severity: normal status: open title: pdb alias command with no arguments is broken versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6888 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6892] optparser example in optparse documentation is broken
New submission from Mitchell Model m...@acm.org: The help example in the middle of the optparse library documentation is broken. The code reads: parser = OptionParser() parser.add_option(-h, --help, action=help), parser.add_option(-v, action=store_true, dest=verbose, help=Be moderately verbose) parser.add_option(--file, dest=filename, help=Input file to read data from), The result of executing this code is: optparse.OptionConflictError: option -h/--help: conflicting option string(s): -h, --help I see that the documentation says that normally help is added automatically so you don't need to do it, but doing so shouldn't break especially since the example shows doing it. Also, the trailing commas on two of the lines are weird and should be removed. -- assignee: georg.brandl components: Documentation messages: 92530 nosy: MLModel, georg.brandl severity: normal status: open title: optparser example in optparse documentation is broken versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6892] optparser example in optparse documentation is broken
Mitchell Model m...@acm.org added the comment: There are other places on the same page with weird trailing commas that should be removed. I think they all follow right parentheses. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6892 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6805] Should be URL for documentation of current release of Python 3 (without version)
New submission from Mitchell Model m...@acm.org: There should be a standard URL on the web site to reach the documentation of the current stable release of Python 3. http://docs.python.org leads to the documentation for Python 2. I can get to Python 3.1 documentation, but I have to specify 3.1 in the URL: http://docs.python.org/3.1 That means that I cannot publish material on the web or in hardcopy that refers generically to the documentation of a particular module via URL without specifying a version, and that version will be obsolete before long. I don't know what the URL should be -- perhaps docs.python.org/3/ would be sufficient. This is one level up from the current arrangement in which specifying 3.1 actually currently gives me the 3.1.1 documentation. -- assignee: georg.brandl components: Documentation messages: 92078 nosy: MLModel, georg.brandl severity: normal status: open title: Should be URL for documentation of current release of Python 3 (without version) versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6805 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6679] obsolete paragraph in re doc for re.sub
New submission from Mitchell Model m...@acm.org: The documentation of re.sub states: The pattern may be a string or an RE object; if you need to specify regular expression flags, you must use a RE object, or use embedded modifiers in a pattern; for example, sub((?i)b+, x, ) returns 'x x'. but there is now a flags argument so that paragraph should be deleted. -- assignee: georg.brandl components: Documentation messages: 91461 nosy: MLModel, georg.brandl severity: normal status: open title: obsolete paragraph in re doc for re.sub versions: Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6679 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6487] Some index entries appear in black
Mitchell Model m...@acm.org added the comment: doh. sorry. I was in a reading mode, not a using mode, and wasn't thinking of the entries as links, though of course I use them that way all the time. The pages just seemed oddly sprinkled with black items. All I said is that I couldn't find any pattern -- doesn't mean there isn't an obvious one! Close it and forget I said anything about it -- status: pending - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6486] Library doc introduction strangely points to Built-in Objects as a starting point
New submission from Mitchell Model m...@acm.org: At the end of the introduction page of the library documentation there is a strange suggestion to begin with Built-in Objects as a starting point. The Built-in Objects page consists of two paragraphs that will surely mystify people new to Python. I'm not sure where it was supposed to point -- built-in functions? built-in types? But surely not Built-in Objects? Or another interpretation, which on deeper investigation, strikes me as the correct one: Built-in Objects, which references tables, operators, etc. that don't appear on that page, is simply an introduction to Built-in Types, or an introduction to all the subsequent chapters. In that case, I see the challenge for structuring the top-level chapters of the library documentation, but perhaps these two paragraphs could simply be moved to the introduction and the Built-in Objects eliminated. Besides, aren't built-in functions and constants, which come before this page, built-in objects too? -- assignee: georg.brandl components: Documentation messages: 90524 nosy: MLModel, georg.brandl severity: normal status: open title: Library doc introduction strangely points to Built-in Objects as a starting point versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6486 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6487] Some index entries appear in black
New submission from Mitchell Model m...@acm.org: Some index entries appear in black. I think this happens only with top-level entries. I can't find any pattern to which ones are in black, so it doesn't look like black has any actual significance. The C general index page is rich with examples. -- messages: 90525 nosy: MLModel severity: normal status: open title: Some index entries appear in black versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6487 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6488] ElementTree documentation refers to path with no explanation, and inconsistently
New submission from Mitchell Model m...@acm.org: The documentation of ElementTree mentions path in describing the arguments to certain methods. However, path is never defined. I realize that a path is (at least a partial implementation of) an XPath, but there's nothing in the documentation to suggest that to someone who is not aware of XPath. I also realize that there is a reference to the external ElementTree documentation, and that ElementTree support for XPath is documented there. I think path should at least be clarified with a reference that says something like As used here the term 'path' refers to ElementTree's support for the XML Path Language (XPath); see see http://effbot.org/zone/element-xpath.htm fordetails Next, a swarm of nits: The documentation of the Element methods find, findall, and findtext say that their arguments can be a tag name or path. (Using the same wording, which makes it strange that the argument to findtext is called condition while the argument to the other two methods are called match. I'm sure there's something important about this distinction, but I can't figure it out from the documentation. The documentation of the corresponding methods of ElementTree call the arguments path, rather than tag or condition. The real problem is that these methods are documented with respect to the element(s) with the given tag. [The the is missing from the documentation of ElementTree.find and findall.] The documentation says these methods are the same as calling the corresponding method on getroot(), but whereas the Element methods refer to tag name or path, the ElementTree methods, although they call their arguments path, only mention tag names. Finally, the ElementTree methods say path is the [top-level] element to look for, which, it seems to me, is redundant given the first sentence of each of each method's documentation. -- assignee: georg.brandl components: Documentation messages: 90528 nosy: MLModel, georg.brandl severity: normal status: open title: ElementTree documentation refers to path with no explanation, and inconsistently versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6488 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6489] Documentation of ElementTree.Element.getiterator implies element will always be included
New submission from Mitchell Model m...@acm.org: Documentation of ElementTree.Element.getiterator implies element will always be included, but it is only included if it matches. (It says creates a tree iterator with the current element as the root and also says, ambiguously, iterates over this element and all the elements below it that match the given tag.) I also feel that it is unclear to leave the term match undescribed. Especially with '*' explicitly mentioned as a possibility, it looks like one could specify, say, 'Thing*' and get all elements whose tag names begin with 'Thing', which does not appear to be the case. Also, using the term match is confusing if one understands the term to mean match an XPath, as (implicitly) used elsewhere in the document, unless match also means an XPath here too, which I don't think it does. I think match should be reserved for XPath matching in this documentation, and equals for when that is the actual test performed, such as, I think, in getiterator. -- assignee: georg.brandl components: Documentation messages: 90529 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of ElementTree.Element.getiterator implies element will always be included versions: Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6489 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6472] Inconsistent use of iterator in ElementTree doc diff between Py and C modules
New submission from Mitchell Model m...@acm.org: I can't quite sort this out, because it's difficult to see what is intended. The documentation of xml.etree.ElementTree (19.11 in the Library doc) uses terms like iterator, tree iterator, iterable, list in vague and perhaps not quite accurate ways. I can't tell from the documentation which functions/methods return lists, which return a generator, which return an unspecified kind of iterable, and so on. Moreover, the results are different using ElementTree than they are using cElementTree. In particular, getiterator() returns a list in ElementTree and a generator in cElementTree. This can make a substantial difference in performance when iterating over a large number of nodes (in addition to cElementTree's parsing being what appears to be about 10x faster). I think someone should go over the page and sort this out and make it clear what the user can expect. (I don't think it's fair to overgeneralize to things like iterables if the module is really meant to be making a commitment to a list or a generator.) I also think that the differences in the results of methods returned in the Python and C versions of the module should be highlighted. I stumbled on this trying to parses and extract individual bits of information out of large XML files. I full well realize there are better ways to do this (SAX, e.g.) and better ways to search than just iterate over all the tags of the type I'm interested in, but I should still know what to expect from ElementTree, especially because it is so wonderful! -- assignee: georg.brandl components: Documentation messages: 90465 nosy: MLModel, georg.brandl severity: normal status: open title: Inconsistent use of iterator in ElementTree doc diff between Py and C modules versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6472 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6384] Permalink to built-in exception class hierarchy documentation
New submission from Mitchell Model m...@acm.org: I think it would be useful to have a permalink to the built-in exception class hierarchy at the end of the library exceptions documentation. -- assignee: georg.brandl components: Documentation messages: 89904 nosy: MLModel, georg.brandl severity: normal status: open title: Permalink to built-in exception class hierarchy documentation versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6384 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6385] two lines of typographical inconsistency in doc of exception class hierarchy
New submission from Mitchell Model m...@acm.org: In the documentation of the built-in exception class hierarhcy in the library documentation WindowsError (Windows) and VMSError (VMS) are not in the same color as the rest of the exception names. -- messages: 89905 nosy: MLModel severity: normal status: open title: two lines of typographical inconsistency in doc of exception class hierarchy versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6385 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6350] Example at end of HTMLParser documentation uses old-style print syntax
New submission from Mitchell Model m...@acm.org: Change the print statements in the example at the bottom of the documentation for HTMLParser to function calls. -- assignee: georg.brandl components: Documentation messages: 89755 nosy: MLModel, georg.brandl severity: normal status: open title: Example at end of HTMLParser documentation uses old-style print syntax versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6350] Example at end of HTMLParser documentation uses old-style print syntax
Mitchell Model m...@acm.org added the comment: Also, while you're at it I think the example should show a call to feed since HTMLParser is unusual in not taking a contents argument when it is created. Nothing wrong with the design, and it is clearly stated at the beginning, but I like examples to be comprehensible at a glance and as self-sufficient as can be conveniently achieved. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6350 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6235] \d missing from effects of re.ASCII flag
New submission from Mitchell Model m...@acm.org: In the documentation of the re module the ASCII flag is described as Make \w, \W, \b, \B, \s and \S perform ASCII-only matching instead of full Unicode matching. This should also include \d and \D. -- assignee: georg.brandl components: Documentation messages: 89064 nosy: MLModel, georg.brandl severity: normal status: open title: \d missing from effects of re.ASCII flag versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6235 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6179] Documentation of for statement in Reference says that range() returns a list
New submission from Mitchell Model m...@acm.org: The documentation of the for statement in Section 7 of the Python 3 Reference states range(3) returns the list [0, 1, 2]. Since range() no longer returns a list, shouldn't this statement be made more precise? (since this is the reference it should be technically accurate) -- assignee: georg.brandl components: Documentation messages: 88764 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of for statement in Reference says that range() returns a list versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6179 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6125] 2to3 mishandles from module_name import when module_name includes an underscore
New submission from Mitchell Model m...@acm.org: 2to3 -f import l.py --- l.py (original) File p.py (the four modules exist in the same directory as p.py): from mod_a import a from modb import b from mod_c import * from modd import * % 2to3 -f import p.py +++ p.py (refactored) @@ -1,5 +1,5 @@ -from mod_a import a -from modb import b -from mod_c import * -from modd import * +from .mod_a import a +from .modb import b +from .mod_c import * +from .modd import * -- components: 2to3 (2.x to 3.0 conversion tool) messages: 88427 nosy: MLModel severity: normal status: open title: 2to3 mishandles from module_name import when module_name includes an underscore versions: Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6129] 2to3 does not convert imports of the form 'import sub.mod' to relative import
New submission from Mitchell Model m...@acm.org: 2to3 changes import m to from . import m but it doesn't change import sub.s. The directory q.py is in has a file m.py and a subdirectory sub. The subdirectory sub has a file s.py. File q.py contains two lines: import m import sub.s % 2to3 -f q.py --- q.py (original) +++ q.py (refactored) @@ -1,2 +1,2 @@ -import m +from . import m import sub.s RefactoringTool: Files that need to be modified: RefactoringTool: q.py -- messages: 88444 nosy: MLModel severity: normal status: open title: 2to3 does not convert imports of the form 'import sub.mod' to relative import ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6129] 2to3 does not convert imports of the form 'import sub.mod' to relative import
Mitchell Model m...@acm.org added the comment: Yes, I meant to mention that: the directory sub does contain an __init__.py with __all__ = ['s']. I'm attaching a zip of the test package pkg that contains the sub-package sub. It wasn't clear to me what import sub.s should be converted to. By analogy with the conversion of import m to from . import m, I had expected import sub.s to be converted from . import sub.s. However, that is a syntax error (which I don't understand, actually). What works is from sub import s but that could import from a sub module found anywhere; it isn't changed to a relative import. I don't see how to write a relative import of a subpackage's module. I don't doubt that I am confused about something here, but I've experimented with many variations and can't get it straightened out. -- Added file: http://bugs.python.org/file14095/pkg.zip ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6129] 2to3 does not convert imports of the form 'import sub.mod' to relative import
Mitchell Model m...@acm.org added the comment: Thanks. I sure couldn't find a way! I encountered this trying to convert someone else's code. There is a main directory and a subdirectory, both with __init__.py files. The files in the main directory import each other just by import othermodule. 2to3 changed those to from . import othermodule, which works. There is a module in the sub-package, say 'm', which files in the main package want to import, which they were doing by import subdirectory.m. I'm glad 2to3 can't figure out what to do and, as per your explanation, I guess there isn't anyway to make this work. So I have to ask, though perhaps this isn't the place, how would a module in a package import a module from a sub-package of that package (where the sub-package includes the module in its all list). I've tried a lot of variations and am not doing any better than 2to3 on this. Suggestions? -- status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6129 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6125] 2to3 mishandles from module_name import when module_name includes an underscore
Mitchell Model m...@acm.org added the comment: I apologize. This example evolved from my attempt to simplify things from the actual code, and I oversimplified to the point where I misread the 2to3 results. I thought there was a space after the period for the modules without the underscores in their name but obviously there wasn't. In the original results there were a lot of from . import modulename and while experimenting with my examples I carelessly confused the import of an entire module with the import of a name or * from a module. Sorry for the bother. (There really was a problem with the code that read from .modulename import *, but of course it wasn't that a space was missing after the period.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6125 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6057] sqlite3 error classes should be documented
Mitchell Model m...@acm.org added the comment: Thanks for the informatiion about the exception classes documented in the PEP. I didn't mean to suggest that the information wasn't available. (For that matter, I was able to extract it for my purposes by looking at the .c source.) I've been writing a book on Bioinformatics Programming Using Python for O'Reilly and working my way through the documentation for the many modules I describe in detail paying far more attention to accuracy, completeness, etc. than would normally concern me. In the process I have submitted many observations about inaccuracies, inconsistencies, gaps, etc. in the library documentation. In effect I am doing a review and picking up problems in a module documentation that could easily go unnoticed by anyone familiar with the modules. A small portion have involved incomplete transitions from Python 2 to Python 3. (My book uses 3; anyone involved in module documentation should take my comments as QA observations about Python 3 documentation and decid e what, if anything, to do about them.) My concern is for non-developer Python programmers who expect module documentation to be self-contained except, perhaps, where there are pointers to major outside resources (for instance, sqlite.org documentation). I don't think we can ask or expect normal Python programmers to know what a PEP is, how to access it, what relationship a PEP has to the module as implemented, etc. True, for the particular case of the DB API interface the PEP document is more important than most becuase it defines an interface that other modules implement. In this case, perhaps the best approach would be to document the DB-API as part of the ordinary Python library documentation, then have sqlite3 be a subtopic of that. However it's done I think user's should be able to read the standard documentation and find what they need. An incidental reason is that people sometimes work offline and don't have access to the PEPs though they do have access to the installed documentation. All those arguments aside, perhaps what makes the most sense is to simply add the error hierarchy following This is the exception inheritance layout: to the sqlite documentation, while still referring the reader to the PEP. I am just really wary of having PEPs serve as documentation for ordinary Python programmers. Even many PEPs that have been accepted and implemented have more interest as background and explanation than practical documentation, snce the documentation of their contribution to the language and the library has been integrated into the regular documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6055] References to pysqlite in documentation of sqlite3 should be changed.
New submission from Mitchell Model m...@acm.org: Why are there references to pysqlite in the documentation and examples for the sqlite3 module. Was sqlite3 derived from the earlier pysqlite module? Seems to me that all the references to pysqlite should read sqlite3, except maybe in a reworded attribution to the developer. -- assignee: georg.brandl components: Documentation messages: 88037 nosy: MLModel, georg.brandl severity: normal status: open title: References to pysqlite in documentation of sqlite3 should be changed. versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6055] References to pysqlite in documentation of sqlite3 should be changed.
Mitchell Model m...@acm.org added the comment: I see that the _sqlite .h and .c files, and the sqlite3/dbapi2.py file, all use pysqlite instead of sqlite3 internally. Should that be changed too, or is there just no point? My main concern is that people relatively new to Python who wouldn't be aware of the long history some modules have and their migration from external packages into the distribution (often with a name change) will be confused by mentions of pysqlite in the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6055 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6057] sqlite3 error classes should be documented
New submission from Mitchell Model m...@acm.org: I can't find any documentation of the exception classes defined in the sqlite3 module. There are quite a few, and some inheritance. The examples in the sqlite3 module documentation have a few exception clauses, but the errors they catch are not explained. I would expect every module that defines exception classes to document them, including inheritance. For a module like sqlite3 it is particularly important because it is just an interface to C code. Expecting someone to figure out exception classes from a module's Python code is one thing, but asking them to go into the C code, which they might not even have, is another. -- assignee: georg.brandl components: Documentation messages: 88044 nosy: MLModel, georg.brandl severity: normal status: open title: sqlite3 error classes should be documented versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6057 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5942] Ambiguity in dbm.open flag documentation
Mitchell Model m...@acm.org added the comment: No, I mean dbm.open. The third paragraph of its documentation says 'c' to create the database if it doesn’t exist, or 'n', which will always create a new empty database. This could easily be read as opening the database just for writing, although come to think of it a write-only database doesn't make any sense. I guess I was just being literal/mechanical in my reading of it, trying to make sure it erased all doubt. If the previous flags hadn't been explicitly documented as for reading only and for reading and writing it wouldn't have occurred to me that 'c' and 'n' should also be documented as reading and writing. No problem if you think this is too trivial and unlikely a problem to bother correcting. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5953] Add to whats new: range(n) != range(n)
Mitchell Model m...@acm.org added the comment: Sounds right. (1) I was raising the issue in case either the behavior was unintended or the documentation should mention it; (2) I realize that comparing ranges is strange; (3) I understand that range works in 3 the way xrange worked in 2, and that the what's new documentation says that range replaces xrange (4) you're point about ranges with steps clinches the issue, I think -- certainly equality of ranges should not have to compute the range -- they should be thought of as generators (and maybe documented as such -- for all I know, since I haven't looked, they are implemented that way); (5) I agree that range behaves like an iterator -- its documentation at the introduction to sequence tyhpes even points out that in, not in, max, and min are inefficient (6) the specific documentation for range explicitly states that they have very little behavior supporting only indexing, iteration, and len(). Your comments were very helpful in explicitly laying out the issues regarding implementing equality and the relative unimportance of the change in behavior, and I now have the explanation I wanted. The only thing that still makes me uncomfortable is that it wouldn't be such a big deal to point out in the 3.0 what's new document where the change to range is mentioned in a bullet that range supports only indexing, iteration, and len, and that operations such as in and not in and functions such as max and min are inefficient because, except in when true, they require iterating over the entire range. Since these are specified in the actual documentation of range I believe they should be added to the what's new, where the change to range is described. I agree that what things don't do should rarely be documented, but if they no longer do something that they used to do, that should go in the what's new document -- at least in the form of an explicit list of what they do do. The only argument I can see against doing that is that the document says that range() now behaves like xrange() used to behave, but I don't feel that is sufficiently explicit for people who have used range extensively but never or rarely xrange or who don't think about its implications. Maybe the what's new should just say that range() acts like an iterator. All in all I'm satisfied and appreciative, except that I'm still left with the feeling that something about range() should be added to the 3.0 what's new. -- -- --- Mitchell -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5953] Add to whats new: range(n) != range(n)
Mitchell Model m...@acm.org added the comment: Ah. I see. I hadn't realized that. OK, I see how all the pieces fit together now. Thanks for all the explanations. They'll help me understand better what kinds of comments to make on the documentation. -- -- --- Mitchell -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5953] Add to whats new: range(n) != range(n)
Mitchell Model m...@acm.org added the comment: Sorry -- I did notice in the copies sent to me of my replies to bugs.python.org that there was HTML, but I can't figure out why. I didn't use any style text in the message nor in my signature. I thought my email program only sent HTML when there was some styled text in the message. I just changed a setting that might fix this -- please tell me if you are seeing HTML in this. -- -- --- Mitchell -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5958] Typo in documentation of shelve.sync
Mitchell Model m...@acm.org added the comment:
Sorry. Careless again.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13924/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5958
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5958] Typo in documentation of
shelve.sync/title/headbody
divSorry. Careless again./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5957] Possible mistake regarding writeback in documentation of shelve.open()
Mitchell Model m...@acm.org added the comment:
http://bugs.python.org/file13925/issue5957.doc.patch
I just spent some time attempting a rewrite, and while I liked what I
ended up with it wasn't all that different from the patch. I'm happy
with the patch.
--
--
--- Mitchell
--
title: Possible mistake regarding writeback in documentation of shelve.open()
- Possible mistake regarding writeback in documentation of shelve.open()
Added file: http://bugs.python.org/file13929/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5957
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5957] Possible mistake regarding
writeback in do/title/headbody
blockquote type=cite
citehttp://bugs.python.org/file13925/issue5957.doc.patch/blockquote
divbr/div
divI just spent some time attempting a rewrite, and while I liked
what I ended up with it wasn't all that different from the patch. I'm
happy with the patch./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5953] Add to whats new: range(n) != range(n)
Mitchell Model m...@acm.org added the comment:
Yes, that's why I was surprised. It's rare (isn't it?) to have str(a)
== str(b) but a != b. a not is b, sure, but a != b? Note also that
list(range(n)) == list(range(n)). If the lists are equal and the
strings are equal it's hard to see why the objects wouldn't be equal.
There are other things like range that define equality; for instance
date.today() == datetime.date(2009, 5, 8)
Seems like ranges should define equals too.
However, I do understand the technical argument for saying not to use
ranges except in prescribed places, largely for iteration. Perhaps
analagously, I discovered that webbrowser.open would open file URLs
in their application on Macs (and perhaps Windows); when I suggested
that behavior be added to the documentation of webbrowser what got
added instead was a paragraph saying that although it might work it's
neither supported nor portable. It could be that the right thing to
do is instead of adding equality (though that would certainly be my
preference) emphasize the statement that ranges have very little
behavior, adding something like in fact, two ranges are never equal
or something like that.
Either the documentation or the implementation should be changed --
it's just too much of a surprised to find that ranges aren't ever
equal, especially when they were in Python 2. (I'm still not
claiming I can think of any logical reason for testing the equality
of ranges. I stumbled on this while writing up a list of examples
motivating pickling and trying to show for what kinds of values
eval(str(value)) == value. I expected range to be one of them.
Here's another wrench, though: while a file is treated as a sequence
of lines in for statements, I doubt anyone would want to ever compare
files for equality. Possibly identity, to see if two open files are
the same, but comparing the contents? That should be done under the
program's control.
Sorry for the long-winded response. It wouldn't be as important if
this were some corner of a little-used module, but range is really
fundamental and it's better to get this right ASAP before people
moving to Python 3 trip over it or rely on a behavior that might
change in the future.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13933/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5953
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5953] Add to quot;whats newquot;:
range(n) != range(n)/title/headbody
divYes, that's why I was surprised. It's rare (isn't it?) to have
str(a) == str(b) but a != b.nbsp; a not is b, sure, but a != b? Note
also that list(range(n)) == list(range(n)). If the lists are equal and
the strings are equal it's hard to see why the objects wouldn't be
equal./div
divbr/div
divThere are other things like range that define equality; for
instance/div
divx-tabnbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;
/x-tabdate.today() == datetime.date(2009, 5, 8)/div
divSeems like ranges should define equals too./div
divbr/div
divHowever, I do understand the technical argument for saying not to
use ranges except in prescribed places, largely for iteration.nbsp;
Perhaps analagously, I discovered that webbrowser.open would open file
URLs in their application on Macs (and perhaps Windows); when I
suggested that behavior be added to the documentation of webbrowser
what got added instead was a paragraph saying that although it might
work it's neither supported nor portable. It could be that the right
thing to do is instead of adding equality (though that would certainly
be my preference) emphasize the statement that ranges have very little
behavior, adding something like quot;in fact, two ranges are never
equalquot; or something like that./div
divbr/div
divEither the documentation or the implementation should be changed
-- it's just too much of a surprised to find that ranges aren't ever
equal, especially when they were in Python 2.nbsp; (I'm still not
claiming I can think of any logical reason for testing the equality of
ranges. I stumbled on this while writing up a list of examples
motivating pickling and trying to show for what kinds of values
eval(str(value)) == value. I expected range to be one of them./div
divbr/div
divHere's another wrench, though: while a file is treated as a
sequence of lines in for statements, I doubt anyone would want to ever
compare files for equality. Possibly identity, to see if two open
files are the same, but comparing the contents? That should be done
under the program's control./div
divbr/div
divSorry for the long-winded response. It wouldn't be as important
if this were some corner of a little-used module, but range is really
fundamental and it's better to get this right ASAP before people
[issue5957] Possible mistake regarding writeback in documentation of shelve.open()
New submission from Mitchell Model m...@acm.org: The documentation of shelve.open() states (paragraph 3) that By default, mutations to persistent-dictionary mutable entries are not automatically written back. It then goes on to describe what happens if the writeback parameter is True, which involves caching the entire dictionary of objects in memory and writing the whole thing back on close. But what happens if writeback is False, the default? The statement that the mutable entires are not automatically written back leaves open the question of how to write them back. shelf.sync() is documented as being used only when writeback is true. Also, for a user unfamiliar with the nuances of persistence the sentence quoted above is somewhat mysterious -- persistent-dictionary mutable entries? written back? -- assignee: georg.brandl components: Documentation messages: 87381 nosy: MLModel, georg.brandl severity: normal status: open title: Possible mistake regarding writeback in documentation of shelve.open() versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5958] Typo in documentation of shelve.sync
New submission from Mitchell Model m...@acm.org: In the documentation of shelve.sync, 'shelf' is mispelled 'Shelf' -- both the word and case are wrong. -- assignee: georg.brandl components: Documentation messages: 87382 nosy: MLModel, georg.brandl severity: normal status: open title: Typo in documentation of shelve.sync versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5958 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5957] Possible mistake regarding writeback in documentation of shelve.open()
Mitchell Model m...@acm.org added the comment: OK, I've figured out from the comments in the example later on in the shelf documentation what the paragraph is supposed to mean. I still think it should be stated clearly. The distinction to be made is that modifications to the dictionary immediately change the file contents -- d[key] = data and del d[key] are, I think, the only actions that fall under this category -- but getting a value from the shelf then modifying that value does NOT affect the underlying dictionary. Ever. It's not a matter of WHEN, but WHETHER. (when writeback is False) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5957 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5953] Add to whats new: range(n) != range(n)
New submission from Mitchell Model m...@acm.org: I just discovered to my (deep) surprise that range(n) != range(n) I think that's worth including in the what's new document. I realize that the document essentially says that in python 3 range behaves the way xrange did in python 2 and that ranges have very little behavior, but surely the lack of equality of two ranges whose string representations are equal is enough of a surprise and difference from python 2 to be worth an explicit comment. (Or maybe no-one ever compares ranges? They are just for iteration? Even that should be said explicitly. This is one of those things that I'm sure expert developers look at and think is obvious but might trip up ordinary users.) -- assignee: georg.brandl components: Documentation messages: 87357 nosy: MLModel, georg.brandl severity: normal status: open title: Add to whats new: range(n) != range(n) versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5953 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5942] Ambiguity in dbm.open flag documentation
New submission from Mitchell Model m...@acm.org: It isn't clear from the explanation of dbm.open's flag values at the beginning of the dbm documentation page whether 'c' and 'n' open the database just for writing or for reading and writing. I'm sure it's obvious to anyone familiar with dbm, and the example demonstrates that 'c' opens the database for reading and writing, but I think it's worth making it explicit by adding a few words to the paragraph describing the flags. -- assignee: georg.brandl components: Documentation messages: 87243 nosy: MLModel, georg.brandl severity: normal status: open title: Ambiguity in dbm.open flag documentation versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5942 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5937] Problems with dbm documentation
Mitchell Model m...@acm.org added the comment: Further confusion: dbm.dumb._Database objects DO support items(), DO NOT support iteritems(), and DO support iterkeys() My previous comments referred to the general dbm documentation and the specifics of dbm.gnu. I haven't checked any of this against the Unix ndbm implementation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5937] Problems with dbm documentation
Mitchell Model m...@acm.org added the comment: And, checking the methods of dbm.ndbm, I find get() and setdefault() but nothing like iterkeys() or iteritems(), just keys(). I think it might also be worth pointing out that a particular variation of dbm may be chosen to create a database file by calling the submodule's open function -- dbm.gdbm.open(), dbm.ndbm.open(), or dbm.dumb.open(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5925] Odd formatting differences of keywords in reference
New submission from Mitchell Model m...@acm.org: In the section at reference/lexical_analysis.html#keywords of the HTML documentation some of the keywords are formatted differently from the majority. In the HTML markup most of the keywords have CSS class 'k', but others have 'n', 'nc', 'kn', 'nn', or 'ow'. I don't see any pattern to which keywords are formatted which way, so I believe this should be corrected. Or, if the differences are intentional they should be documented. [Just trying to help clean up the doc -- I realize how trivial this is.] -- assignee: georg.brandl components: Documentation messages: 87153 nosy: MLModel, georg.brandl severity: normal status: open title: Odd formatting differences of keywords in reference versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5925 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5937] Problems with dbm documentation
New submission from Mitchell Model m...@acm.org: There are some problems with the dbm documentation. In the opening section: 1. The comment before the iteration example says that .values() works, but the method is not defined. 2. The statement in the paragraph after the documentation of dbm.open() says that the opened dbm object supports most of the same functionality as dictionaries. It specifically mentions keys(), but should state that values() is not supported. 3. I disagree with the use of the word most there. It does support a minimal dictionary-like interface, but it provides only about 1/3 of the method that dict does. 4. The documentation should point out that keys() returns a list not a dict_keys object. 5. The example code shows the use of iteritems() but the documentation doesn't mention it. In any case, there is no such method. 6. In fact, the comment at the beginning of dbm/__init__.py states that the interface is limited to set, get, and del using [] notation, the in operator (and though not stated, the not in operator), and k.keys(). The Unix dbm section does state that values() and items() are not supported, but the gdbm section does not (and should). I hope this is all accurate. In general, the whole page should be edited to be consistent with the actual implementation. -- assignee: georg.brandl components: Documentation messages: 87208 nosy: MLModel, georg.brandl severity: normal status: open title: Problems with dbm documentation versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5937 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5658] make html in doc fails because Makefile assigns python to PYTHON
Mitchell Model m...@acm.org added the comment:
It strikes me as an inconsistency because I wouldn't expect the build
process to differ from Python 3.0 to 3.1 except for fixing bugs. A
developer, or someone trying to keep up with the most recent
versions, who had been successfiully making the html doc in a
subversion copy of Python 3.0 and wanted to move over to Python 3.1
finds this surprise if the command python is bound to Python 3. I
grant you that this is a lot of ifs, and a transitional issue if
we're all going to call Python 3 python3.
It might even be worth mentioning in the build instructions that
python should be bound to a Python 2 executable, not Python 3,
because a few things, such as make html in doc, use tools that
haven't been updated.
Not a big deal. Just fighting for the Principle of Least Surprise,
as in many of the documentation issues I've submitted. My GUI
background showing.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13581/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5658
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5658] make html in doc fails because
Makefile as/title/headbody
divIt strikes me as an inconsistency because I wouldn't expect the
build process to differ from Python 3.0 to 3.1 except for fixing
bugs.nbsp; A developer, or someone trying to keep up with the most
recent versions, who had been successfiully making the html doc in a
subversion copy of Python 3.0 and wanted to move over to Python 3.1
finds this surprise if the command python is bound to Python 3. I
grant you that this is a lot of ifs, and a transitional issue if we're
all going to call Python 3 python3./div
divbr/div
divIt might even be worth mentioning in the build instructions that
quot;pythonquot; should be bound to a Python 2 executable, not
Python 3, because a few things, such as make html in doc, use tools
that haven't been updated./div
divbr/div
divNot a big deal. Just fighting for the quot;Principle of Least
Surprisequot;, as in many ofnbsp; the documentation issues I've
submitted. My GUI background showing./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5658] make html in doc fails because Makefile assigns python to PYTHON
Mitchell Model m...@acm.org added the comment:
OK
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13583/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5658
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5658] make html in doc fails because
Makefile as/title/headbody
divOK/div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5601] webbrowser doesn't just open browsers
Mitchell Model m...@acm.org added the comment:
Never mind about the garbage -- I was looking at weird HTML in the
copy of the message I received but it didn't make it into the entry
on this page. I should have looked first.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13539/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5601
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5601] webbrowser doesn't just open
browsers/title/headbody
divNever mind about the garbage -- I was looking at weird HTML in
the copy of the message I received but it didn't make it into the
entry on this page. I should have looked first./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5650] Obsolete RFC's should be removed from doc of urllib.urlparse
New submission from Mitchell Model m...@acm.org: The documentation of urlparse in Python2 and urllib.urlparse in Python3 refers to three RFC's, the last of which (RFC 2396) says that it supersedes the other two and, in fact, clicking on the links to the other two doesn't work; the link and description for the two obsolete RFCs should be removed. -- assignee: georg.brandl components: Documentation messages: 85032 nosy: MLModel, georg.brandl severity: normal status: open title: Obsolete RFC's should be removed from doc of urllib.urlparse versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5658] make html in doc fails because Makefile assigns python to PYTHON
New submission from Mitchell Model m...@acm.org: Mac OSX, py3k 70991 cd doc; make html fails due to an old style except clause in Doc/tools/sphinx/__init__.py The make works in release30-maint. The difference is that the generated doc/Makefile in release30-maint assigns python2.5 to PYTHON, but the py3k doc/Makefile assigns python. I have things set up so that 'python' is Python 3. I understand how to set the variable from the command line, and I can build the html doc, but this should be fixed, either by continuing to specify python2.5 in the sphinx Makefile or by changing __init__.py and whatever other code uses exception binding to the new syntax. -- components: Build messages: 85094 nosy: MLModel severity: normal status: open title: make html in doc fails because Makefile assigns python to PYTHON versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5658 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5658] make html in doc fails because Makefile assigns python to PYTHON
Mitchell Model m...@acm.org added the comment:
OK, makes sense. Just out of curiosity where does a user find that
information? a developer?
There is still an inconsistency between the Makefiles in the two
versions. That seems dangerous.
--
--
--- Mitchell
--
title: make html in doc fails because Makefile assigns python to PYTHON - make
html in doc fails because Makefile assigns python toPYTHON
Added file: http://bugs.python.org/file13565/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5658
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5658] make html in doc fails because
Makefile as/title/headbody
divOK, makes sense. Just out of curiosity where does a user find
that information? a developer?/div
divbr/div
divThere is still an inconsistency between the Makefiles in the two
versions. That seems dangerous./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5601] webbrowser doesn't just open browsers
Mitchell Model m...@acm.org added the comment:
The problem is not so much that I think people should use it for file
URLs, it's that the behavior when they do can be quite confusing.
Perhaps a note that webbrowser is not meant for file URLs and that
it's behavior is undefined if it is?
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13532/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5601
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5601] webbrowser doesn't just open
browsers/title/headbody
divThe problem is not so much that I think people should use it for
file URLs, it's that the behavior when they do can be quite confusing.
Perhaps a note that webbrowser is not meant for file URLs and that
it's behavior is undefined if it is?/div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5601] webbrowser doesn't just open browsers
Mitchell Model m...@acm.org added the comment:
whoops
Sorry for the garbage in the previous message.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13533/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5601
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5601] webbrowser doesn't just open
browsers/title/headbody
divwhoops/div
divbr/div
divSorry for the garbage in the previous message./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5600] Slight inaccuracy in webbrowser documentation
New submission from Mitchell Model m...@acm.org: The sentence introducing Browser Controller Objects in the documentation of the webbrowser module says that the methods parallel two of the module's convenience functions; it's really three. -- assignee: georg.brandl components: Documentation messages: 84460 nosy: MLModel, georg.brandl severity: normal status: open title: Slight inaccuracy in webbrowser documentation versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5600 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5601] webbrowser doesn't just open browsers
New submission from Mitchell Model m...@acm.org:
There is a problem with the documentation of the webbrowser module:
opening a URL doesn't necessarily open it in a browser. The
documentation of the open function and method should say that the URL is
opened in whatever application the system chooses based on
considerations such as the type of URL, an application assigned to the
file, and the application assigned to the file's type (extension).
Here's why:
The documentation of module webbrowser, as well as the name of the
module itself, only mentions browsers as what opens the given URL.
However, on some platforms (Mac OS X, e.g.) if things are configured so
there is a default application associated with a particular file
extension, the webbrowser functions will open a path to a file in the
application associated with it's file type rather than a browser. This
is true whether or not file:// precedes the file path in the URL.
For example, if .py files are set to open in IDLE,
webbrowser.open('/fullpath/to/file.py') will open /fullpath/to/file.py
in IDLE. It's even possible to assign one browser to open .htm files and
another to open .html files.
It is also possible on some platforms (Mac, again) to assign a default
application to files of a particular extension but assign a different
application to specific files with that extension.
Applications can also be assigned to URL types. For instance, you could
have an application that isn't really a browser open ftp:// URLs. (This
also can happen when you download a file from a browser and the task is
turned over to a download application such as Speed Download or
Interarchy on a Mac.)
The real problem here is that some platforms have extended the idea of
opening a URL (including a bare file path interpreted as a file:// URL)
beyond browsers per se. In a sense the entire terminology of this module
is suspect, despite its obvious intent. Although not a serious
suggestion, it would more accurately be termed the urlopen module.
--
assignee: georg.brandl
components: Documentation
messages: 84485
nosy: MLModel, georg.brandl
severity: normal
status: open
title: webbrowser doesn't just open browsers
versions: Python 3.0, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5601
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5602] Slight punctuation problem in documentation of urllib.request.urlopen
New submission from Mitchell Model m...@acm.org: In the documentation of the urllib.request module, the function urllib.request.urlretrieve is shown with parameters: (url[, data][, timeout]) Shouldn't the right bracket after 'data' be after 'timeout'? -- assignee: georg.brandl components: Documentation messages: 84489 nosy: MLModel, georg.brandl severity: normal status: open title: Slight punctuation problem in documentation of urllib.request.urlopen versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5513] What's New should say VERY CLEARLY that the type file is gone
Mitchell Model m...@acm.org added the comment: At 11:03 AM -0400 3/19/09, Mitchell L Model wrote: Martin v. Löwis mar...@v.loewis.de added the comment: The Python 3 What's New should SCREAM that the type file is gone I don't think the documentation should ever SCREAM. No, of course not. I was being extreme. The problem with the laconic alternative is that it sets traps for people. It reminds me of wrestling Stroustrop's first book on C++ where all this weird behavior happened and when you went back to the book you could find one sentence whose third-level implication was consistent with the explanation. What I'm saying is that it's not enough to say to use open(). Don't you think people ever referred to the type file directly? As in help(file) or dir(file) or file.somemethod(receiver, arg)? Or even storing a file method in a dictionary for dispatch? It doesn't matter whether any of these were a good idea, I claim they were quite ingrained in Python 2 user's minds. The changes in the sequence types are quite substantial, but they are explained in detail. This isn't. In reviewing the What's New for the purpose of this reponse I noticed an earlier mention of sys.stdin, sys.stdout, and sys.stderr, where it says they are now instances of TextIOBase. (They are actually instances of TextIOWrapper, just like the result of open().) So why can't the documentation of open() say that it returns an instance of TextIOBase too? At least add to the paragraph of PEP 3116 that the old file type is gone. Maybe that's better than discussing it in conjunction with open(), in which case the statement using open() instead of file should read that open replaces file(), not file. It just seems like a very wide trap to never mention that the whole file type is gone. It does not follow from the two facts that one should use open() instead of file() and that the IO system has been rewritten, that there is no file type. Even if whatever open returns has the same interface as the old file type. The type file has been replaced by _ioTextIOWrapper; use open() to open a file; open returns an instance of _ioTextIOWrapper. That would be an incorrect statement: there are multiple types that replace the 2.x file type. See the documentation of the io module for details. OK, I didn't follow the technical details through and, as I said above, I hadn't noticed the earlier mention of TextIOBase for sys.stdout, etc. So just say something like The type file is gone, replaced by classes in the IO module. Use open() to open a file. And maybe add that it returns an instance of TextIOBase or TextIOWrapper, whichever is deemed more appropriate. Whatever else it says with regard to the above comments the What's New really needs to explicitly say that the file type is gone. And I apologize for screaming in my entry. I was just so incredibly shocked when I figured out what was going on. -- --- Mitchell -- title: What's New should say VERY CLEARLY that the type file is gone - What's New should say VERY CLEARLY that the type fileis gone ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5519] Deletion of some statements in re documentation
New submission from Mitchell Model m...@acm.org: The second sentence of the re module documentation -- The re module is always available. seems extraneous at best. What is it saying? What modules are not always available? Do other always available modules say that they are always available? Also, the reference to kodos should probably be removed. It hasn't been updated since 2006, and it doesn't work with PyQT4. -- assignee: georg.brandl components: Documentation messages: 83821 nosy: MLModel, georg.brandl severity: normal status: open title: Deletion of some statements in re documentation versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5519 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5513] What's New should say VERY CLEARLY that the type file is gone
New submission from Mitchell Model m...@acm.org: MAIN POINT The Python 3 What's New should SCREAM that the type file is gone, not just that people should use the function open() to open files, since that has been a recommendation for quite a while. EXPLANATION In multiple readings of the Python 3 What's New I blew right past the Removed file. Use open()., since I've been using open() instead of file() for a long time. I didn't notice that unlike the preceding several lines, there were no parentheses after file and that this line was literally saying there was no longer a type called file. OBSERVATIONS (1) If the line is meant to say that you can no longer call file() as a function -- which would be strange if it were still a type -- then it is missing its parentheses. (2) If the line is meant to say that there is no longer a file type, as it apparently means to say since in fact -- and to my great surprise -- there really IS no type called file in Python 3 (I discovered that doing a dir(file) to check whether file provided method function I thought it did instead of taking the time to look it up.) then there is a grammatical problem with the line since a (n old) type shouldn't be equated to a function call. (3) I predict that anyone who has more than a passing acquaintance with Python 2 will be similarly shocked when they find out that what they get back from open() is a _io.TextIOWrapper (and, by the way, that they have to import _io or at least _io.TextIOWrapper to be able to do a dir on it). Likewise for help(file) and help(_io.TextIOWrapper). There should be a very prominent statement that as part of the reimplementation of the io system, the type file has been replaced by _io.TextIOWrapper. RECOMMENDATION The line Removed file. Use open(). should be replaced with: The type file has been removed; use open() to open a file. or possibly: The type file has been replaced by _ioTextIOWrapper; use open() to open a file; open returns an instance of _ioTextIOWrapper. -- assignee: georg.brandl components: Documentation messages: 83783 nosy: MLModel, georg.brandl severity: normal status: open title: What's New should say VERY CLEARLY that the type file is gone versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5513 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5469] Reference paragraph about the constructs that bind names needs updating for Python 3
New submission from Mitchell Model m...@acm.org: In the Python Language Reference, in the Naming and binding section of Execution Model, there is a paragraph that states: The following constructs bind names: formal parameters to functions, import statements, class and function definitions (these bind the class or function name in the defining block), and targets that are identifiers if occurring in an assignment, for loop header, or in the second position of an except clause header. The import statement of the form “from ...import *” binds all names defined in the imported module, except those beginning with an underscore. This form may only be used at the module level. This misdescribes the except clause, which now uses as, and omits the with ... as construct which also binds names. -- assignee: georg.brandl components: Documentation message_count: 1.0 messages: 83439 nosy: MLModel, georg.brandl nosy_count: 2.0 severity: normal status: open title: Reference paragraph about the constructs that bind names needs updating for Python 3 versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5469 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5426] README slight error re OSX
New submission from Mitchell Model m...@acm.org: Line 136 of the 3.0 README and line 179 of the 3.1 README state that the executable on OSX is called python.exe. It's not. -- assignee: georg.brandl components: Documentation messages: 83203 nosy: MLModel, georg.brandl severity: normal status: open title: README slight error re OSX versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5426 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5426] README slight error re OSX
Mitchell Model m...@acm.org added the comment:
Nothing on OSX is ever named .exe.
On OSX building and installing Python with configure
--enable-framework installs an executable just called 'python' in
/Library/Frameworks/Python.framework/Versions/3.1/bin (using 3.1 as
an example). It also creates double-clickable applications whose real
name is Python.app and IDLE.app. Whether to see the .app extensions
on packages that are applications is a Finder preference, so most
users won't see the .app.
If the build was configured without frameworks, then an executable
named in the Unix style -- just python -- is installed in
/usr/local/bin (by default) or wherever else was specified with the
configure --prefix option.
--
--
--- Mitchell
Added file: http://bugs.python.org/file13249/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5426
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5426] README slight error re
OSX/title/headbody
divNothing on OSX is ever named .exe./div
divbr/div
divOn OSX building and installing Python with quot;configure
--enable-frameworkquot; installs an executable just called 'python'
in /Library/Frameworks/Python.framework/Versions/3.1/bin (using 3.1 as
an example). It also creates double-clickable applications whose real
name is Python.app and IDLE.app.nbsp; Whether to see the .app
extensions on quot;packagesquot; that are applications is a Finder
preference, so most users won't see the .app./div
divbr/div
divIf the build was configured without frameworks, then an
executable named in the Unix style -- just python -- is installed in
/usr/local/bin (by default) or wherever else was specified with the
configure --prefix option./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5427] OSX framework make error: ld: duplicate symbol _PyExc_BlockingIOError in libpython3.1.a(_iobase.o) and libpython3.1.a(io.o)
New submission from Mitchell Model m...@acm.org: Trying to build 3.1 in recent 'svn update's on OSX 10.5 after make clean configure --enable-framework I get the following error near the end of the build: ld: duplicate symbol _PyExc_BlockingIOError in libpython3.1.a(_iobase.o) and libpython3.1.a(io.o) I even tried deleting all the files and checking them out again, but I got the same error. -- components: Build messages: 83211 nosy: MLModel severity: normal status: open title: OSX framework make error: ld: duplicate symbol _PyExc_BlockingIOError in libpython3.1.a(_iobase.o) and libpython3.1.a(io.o) versions: Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5427 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5426] README slight error re OSX
Mitchell Model m...@acm.org added the comment:
Whoops! It didn't say the executable that gets built is called
python.exe, but it is in the build section, so taking things
literally, yes, the executable is called python.exe and I maybe
should have taken it at its word.
There's a subtle problem in the wording since the executable almost
always suggests the program you run. It's a little weird -- though
I see your point about why it's done that way -- to build an
executable that gets installed as a different name. (Well, maybe
installed with version number as part of the name.) So even if the
README is literally correct I do think it lays a subtle trap for the
reader that could be avoided with a slight rewording. Not important
-- I'm just trying to help by pointing out documentation problems as
I come across them. Most of them have been real.
--
--
--- Mitchell
Added file: http://bugs.python.org/file13250/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5426
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5426] README slight error re
OSX/title/headbody
divWhoops! It didn't say quot;the executable that gets built is
called python.exequot;, but it is in the build section, so taking
things literally, yes, the executable is called python.exe and I maybe
should have taken it at its word./div
divbr/div
divThere's a subtle problem in the wording since quot;the
executablequot; almost always suggests quot;the program you
runquot;. It's a little weird -- though I see your point about why
it's done that way -- to build an executable that gets installed as a
different name. (Well, maybe installed withnbsp; version number as
part of the name.) So even if the README is literally correct I do
think it lays a subtle trap for the reader that could be avoided with
a slight rewording.nbsp; Not important -- I'm just trying to help by
pointing out documentation problems as I come across them. Most of
them have been real./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5418] urllib.response.addinfourl does not support __exit__
New submission from Mitchell Model m...@acm.org: response = urllib.request.open(someURL) page = response.read() close() be called on response after the read(), right? Experimentation shows that I can repeatedly read from response until I close it, getting back empty bytes objects. Thinking that anything with a close() should support the with statement, I tried putting the code inside one but got AttributeError: 'addinfourl' object has no attribute '__exit__' so I can see that it doesn't support with. It seems like it should. -- components: Library (Lib) messages: 83174 nosy: MLModel severity: normal status: open title: urllib.response.addinfourl does not support __exit__ type: behavior versions: Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5418 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5419] urllib.request.open(someURL).read() returns a bytes object so writing it requires binary mode
New submission from Mitchell Model m...@acm.org:
There needs to be something somewhere in the documentation that makes
the simple point that data coming in from the web is bytes not strings,
which is a big change from Python 2, and that it needs to be manipulated
as such, including writing in binary mode.
I am not sure what documentation should be changed, but I do think
something is missing, because I just ran around in circles on this one
for quite some time. Perhaps the Unicode HOWTO needs more information;
possibly urllib.request does; maybe a combination of things have to be
added to several documentation files. Here's what happened:
I wanted to read from a web page, make some string replacements, and
save to a file, so I wrote code that boils down to something like:
with open('url.html', 'w') as fil:
fil.write(urllib.request.open(aURL).read()).replace(str1, str2)
The first thing that happened was an error telling me that I can't write
bytes to a text stream, so I realized that read() was returning a bytes
object, which makes sense.
So I converted it to a string, but that put a b' at the beginning of the
file and a ' at the end! Bad.
Instead of str(thebytes) I did the proper thing: thebytes.decode(), and
wrote that to the file.
But then I found that Non-ASCII characters created problems -- they were
saved in the file as \xNN\xNN or even three \x's, then displayed as
garbage when the page was opened in a browser.
So I tried decoding using different codecs but couldn't find one that
worked for the é and the emdash that were in the response.
Finally I realized that the whole thing was a delusion: obviously
urlopen responses have to return bytes objects, and adding 'b' to the
'w' when opening the output file fixed everything. (I also had to change
my replacement strings to bytes.)
I went back to the relevant documentation multiple times, including
after I figured everything out, and I can't convince myself that it
makes the connection anywhere between bytes coming in, manipulating the
bytes as bytes, and writing out in binary. Yes, in retrospect this all
makes sense and perhaps even should have been obvious, but I am quite
sure I won't be the only experienced Python 2 programmer to trip over
this when making the transition to Python 3.
I apologize in advance if the requested documentation exists and I
didn't find it, in which case I would appreciate a pointer to where it
is lies.
--
assignee: georg.brandl
components: Documentation
messages: 83179
nosy: MLModel, georg.brandl
severity: normal
status: open
title: urllib.request.open(someURL).read() returns a bytes object so writing
it requires binary mode
versions: Python 3.0, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5419
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5371] Documentation of str.format in library/stdtypes shows incorrect first parameter
New submission from Mitchell Model m...@acm.org: In the library documentation of standard types, the instance method str.format is shown as taking a format-specification as its first argument. I'm pretty sure that this is incorrect. When format is called through a string, it is that string that is the format specification. That is, shouldn't format(format-specification-string, arg) be equivalent to format-specification-string.format(arg) ? -- assignee: georg.brandl components: Documentation messages: 82722 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of str.format in library/stdtypes shows incorrect first parameter versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5371 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5363] Documentation of filecmp.compfiles missing word possible explanation
New submission from Mitchell Model m...@acm.org: contains the list of files match in both directories, should have that before match In addition I couldn't figure out from the documentation what common was supposed to be doing -- it sounded more like something that should be part of the result not a parameter. I had to look at the code to realize that this function ONLY compares the files listed in common -- that it doesn't compare two directories completely, but rather dir1 and dir2 are merely prefixes for the files listed in common that are to be compared. One thing that would help would be to move the paragraph about common first. Another would be to a list of file names found in both directories to a list of the names of files to be compared, which must be in both directories or something like that. -- assignee: tarek components: Distutils messages: 82696 nosy: MLModel, tarek severity: normal status: open title: Documentation of filecmp.compfiles missing word possible explanation versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5363 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5363] Documentation of filecmp.compfiles missing word possible explanation
Changes by Mitchell Model m...@acm.org: -- components: +Documentation -Distutils ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5363 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5348] Documentation of format implies only strings and numbers are acceptable arguments
Mitchell Model m...@acm.org added the comment:
Sorry -- I was too quick to include 2.6 and 2.7 in the bug tracker
entry. I usually check 3 vs 2.6 but since format is in 2.6 I didn't
check the 2.6 doc page to discover, as you did, that it wasn't
documented.
--
--
--- Mitchell
Added file: http://bugs.python.org/file13157/unnamed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5348
___!doctype html public -//W3C//DTD W3 HTML//EN
htmlheadstyle type=text/css!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
--/styletitleRe: [issue5348] Documentation of format implies
only strin/title/headbody
divSorry -- I was too quick to include 2.6 and 2.7 in the bug
tracker entry.nbsp; I usually check 3 vs 2.6 but since format is in
2.6 I didn't check the 2.6 doc page to discover, as you did, that it
wasn't documented./div
divtt-- /tt/div
div-- br
br
nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp; --- Mitchell/div
/body
/html___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
