[issue8491] Need readline command and keybinding information
Mitchell Model added the comment: On Aug 5, 2010, at 3:48 PM, Terry J. Reedy wrote: > > Terry J. Reedy 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 > <http://bugs.python.org/issue8491> > ___ -- ___ Python tracker <http://bugs.python.org/issue8491> ___ ___ 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 : 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 <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
New submission from Mitchell Model : 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 <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 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 <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 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 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 > <http://bugs.python.org/issue10733> > ___ -- ___ Python tracker <http://bugs.python.org/issue10733> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3855] Windows installation did not work; tried on two machines
New submission from Mitchell Model <[EMAIL PROTECTED]>: I installed 3.0b3 using the Windows MSI installer on two machines, one running 32-bit Windows XP Professional on a 64-bit AMD processor with Python 2.5 already installed, and another a Parallels Desktop on an Intel MacBook running Windows XP Professional with no previous Python installation. Both failed to run either python or pythonw, saying "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem." Building 3.0b3 on my MacBook from source and doing an altinstall runs fine. I'm sorry if this is a ridiculous submission, but I have done plenty of this sort of thing on both platforms before and am just stumped, and I have a fairly urgent need to try something on Windows. -- components: Installation messages: 73164 nosy: MLModel severity: normal status: open title: Windows installation did not work; tried on two machines type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3855> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
New submission from Mitchell Model <[EMAIL PROTECTED]>: IDLE fails to start on my MacBook [OS 10.5, v2.6b3 and v3.0b3, built from source]. At the call to delete in the backtrace below index1 is 1 and index2 is 'end'. python2.6 lib/python2.6/idlelib/idle.py Traceback (most recent call last): File "lib/python2.6/idlelib/idle.py", line 21, in idlelib.PyShell.main() File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 1396, in main shell = flist.open_shell() File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 275, in open_shell self.pyshell = PyShell(self) File "/usrlocal/lib/python2.6/idlelib/PyShell.py", line 816, in __init__ OutputWindow.__init__(self, flist, None, None) File "/usrlocal/lib/python2.6/idlelib/OutputWindow.py", line 16, in __init__ EditorWindow.__init__(self, *args) File "/usrlocal/lib/python2.6/idlelib/EditorWindow.py", line 234, in __init__ self.update_recent_files_list() File "/usrlocal/lib/python2.6/idlelib/EditorWindow.py", line 763, in update_recent_files_list menu.delete(1, END) # clear, and rebuild: File "/usrlocal/lib/python2.6/lib-tk/Tkinter.py", line 2665, in delete for i in range(self.index(index1), self.index(index2)+1): TypeError: unsupported operand type(s) for +: 'NoneType' and 'int' -- components: IDLE messages: 73166 nosy: MLModel severity: normal status: open title: IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3 type: crash versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3856> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3856] IDLE fails on startup on Mac 10.5 for 2.6b3 and 3.0b3
Mitchell Model <[EMAIL PROTECTED]> added the comment:
Theis the first time I've submitted bug reports to Python.org's
development efforts, though I've been using Python for many years. I
don't know what the procedures are for followup to emails like you
sent me, and given that the address is [EMAIL PROTECTED], I'm
not even sure who -- if anyone -- reads a response like this. Please
tell me how to follow up and anything else you'd like to suggest
about how I could help more effectively.
I retried IDLE it with Python 2.6rc1 and got a very helpful and
elaborate error message about not being able to start the subprocess,
what port it was trying to connect to, and a pointer to information
about running it without a subprocess. I had my Mac's Security
Firewall set to allow all incoming connections, so I don't know why
it was refusing this one, but I changed the settings to "Set access
for specific services and applications" and added idle26 and idle30.
IDLE 2.6rc1 now works.
However, I checked out 3.0 sources from the Subversion repository
yesterday, but am still getting a problem, though a different one,
with IDLE30:
Traceback (most recent call last):
File "", line 1, in
File "/usrlocal/lib/python3.0/idlelib/run.py", line 76, in main
sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute 'set_daemon'
Should I just assume that the development problem will be taking care
of things like this, or is it helpful for me to report them when I
encounter them?
Thanks for your response.
--- Mitchell
>Guilherme Polo <[EMAIL PROTECTED]> added the comment:
>
>This bug was fixed after b3 was released (r65971). You should retry it
>using python 2.6rc1 or update your sources for py3k.
>
>--
>nosy: +gpolo
>resolution: -> out of date
>status: open -> closed
>
>___
>Python tracker <[EMAIL PROTECTED]>
><http://bugs.python.org/issue3856>
>___
Added file: http://bugs.python.org/file11496/unnamed
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3856>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue3856] IDLE fails on startup on Mac 10.5
for 2.6b
Theis the first time I've submitted bug reports to Python.org's
development efforts, though I've been using Python for many years.
I don't know what the procedures are for followup to emails like you
sent me, and given that the address is [EMAIL PROTECTED], I'm
not even sure who -- if anyone -- reads a response like this.
Please tell me how to follow up and anything else you'd like to
suggest about how I could help more effectively.
I retried IDLE it with Python 2.6rc1 and got a very helpful
and elaborate error message about not being able to start the
subprocess, what port it was trying to connect to, and a pointer to
information about running it without a subprocess. I had my
Mac's Security Firewall set to allow all incoming connections, so I
don't know why it was refusing this one, but I changed the settings to
"Set access for specific services and applications" and
added idle26 and idle30. IDLE 2.6rc1 now works.
However, I checked out 3.0 sources from the Subversion repository
yesterday, but am still getting a problem, though a different one,
with IDLE30:
Traceback (most recent call last):
File "<string>", line 1, in
<module>
File
"/usrlocal/lib/python3.0/idlelib/run.py", line 76, in
main
sockthread.set_daemon(True)
AttributeError: 'Thread' object has no attribute
'set_daemon'
Should I just assume that the development problem will be taking
care of things like this, or is it helpful for me to report them when
I encounter them?
Thanks for your response.
---
Mitchell
Guilherme Polo <[EMAIL PROTECTED]>
added the comment:
This bug was fixed after b3 was released (r65971). You should retry
it
using python 2.6rc1 or update your sources for py3k.
--
nosy: +gpolo
resolution: -> out of date
status: open -> closed
___
Python tracker
<[EMAIL PROTECTED]>
<http://bugs.python.org/issue3856>;
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3549] Missing IDLE Preferences on Mac
Mitchell Model <[EMAIL PROTECTED]> added the comment: Compiling with configure --enable-framework, from updated SVN sources today plus the change suggested in issue 3628, IDLE works with both 2.6rc1 and 3.0b3. There is still no options menu, but there is now a Preferences item on the IDLE menu, where this more appropriately belongs on the Mac. However, IDLE Help still refers to the Options menu; on the Mac, the Help information should refer to the Preferences item on the IDLE menu instead of Options item, or at least add a comment that that's where the functionality of Options appears on the Mac. -- nosy: +MLModel ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3549> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3882] Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text.
New submission from Mitchell Model <[EMAIL PROTECTED]>: The text of the buttons on the bottom of the Mac IDLE Preferences pane is cut off in 2.6rc1 and 3.0b3 (framework builds). This was not true in 2.5.1. -- messages: 73309 nosy: MLModel severity: normal status: open title: Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text. versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3883] Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text.
New submission from Mitchell Model <[EMAIL PROTECTED]>: The text of the buttons on the bottom of the Mac IDLE Preferences pane is cut off in 2.6rc1 and 3.0b3 (framework builds). This was not true in 2.5.1. -- components: IDLE messages: 73310 nosy: MLModel severity: normal status: open title: Bottom buttons of IDLE Preferences Pane on Mac not wide enough for their text. versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3883> ___ ___ 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 added the comment: Still true in 3.1 -- nosy: +MLModel versions: +Python 3.1 -Python 3.0 ___ Python tracker <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 :
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
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
<http://bugs.python.org/issue7781>
___
___
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 : 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 <http://bugs.python.org/issue8077> ___ ___ 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 : 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 <http://bugs.python.org/issue8172> ___ ___ 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 : 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 <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 : 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 <http://bugs.python.org/issue8492> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3433] libtk
Changes by Mitchell Model : -- title: Mac, 3.0 framework install error with fink cp -> libtk ___ Python tracker <http://bugs.python.org/issue3433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4813] On OS-X the directories searched by setup.py for Tk are in the wrong order.
New submission from Mitchell Model : In function detect_tkinter_darwin of setup.py framework_dirs should be the reverse of what it is: first the user's library should be searched, then /Library, and finally /System/Library. If Tk 8.5 is installed in /Library or ~/Library make will otherwise find the headers from 8.4 but the libraries from 8.5. Issue 4017 discusses this problem, among others, and is marked fixed, but it is still incorrect in the 2.6 and 3.0 downloads as well as in the trunk, 3.0, and 3.1 subversion repositories. It may have been "fixed" in so far as someone was able to make a .dmg by manually altering setup.py, and that's great, but it isn't fixed in the source and the problem will reappear with each new version. -- components: Build messages: 78904 nosy: MLModel severity: normal status: open title: On OS-X the directories searched by setup.py for Tk are in the wrong order. type: compile error versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4813> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4914] trunc(x) erroneously documented as built-in
New submission from Mitchell Model : In the Numeric Types documentation for 2.6, 3.0, and 3.1 trunc is documented as a built-in, like round, but while there is a trunc in math there is no built-in trunc. Read some of the debate on trunc from a year ago convinced me that this discrepancy is a documentation problem not a problem with the built-in functions. Sorry if I'm completely off target here, but since I noticed I figured it was worth an issue. -- assignee: georg.brandl components: Documentation, Library (Lib) messages: 79590 nosy: MLModel, georg.brandl severity: normal status: open title: trunc(x) erroneously documented as built-in versions: Python 2.6, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4914> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4974] Redundant mention of lists and tuples at start of Sequence Types documentation
New submission from Mitchell Model : Under Built-in Types in the Library documentation the section on "Sequence Types" begins with the paragraph: There are five sequence types: strings, byte sequences, byte arrays, lists, tuples, and range objects. (For other containers see the built-in dict, list, set, and tuple classes, and the collections module.) list and tuple "classes" shouldn't be in that second sentence, should they? They are already in the first. -- assignee: georg.brandl components: Documentation messages: 80046 nosy: MLModel, georg.brandl severity: normal status: open title: Redundant mention of lists and tuples at start of Sequence Types documentation versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4976] Documentation of the set intersection and difference operators is inaccurate
New submission from Mitchell Model : A quibble about the documentation of sets in the library documentation: the union and intersection operators are shown with ellipsis, as is the difference operator. However, they inaccurately refer to "both sets" in their documentation. They should refer to "all sets" or "the others" the way the set difference operator documentation does. -- assignee: georg.brandl components: Documentation messages: 80051 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of the set intersection and difference operators is inaccurate versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4976> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4981] Incorrect statement regarding mutable sequences in datamodel Reference
New submission from Mitchell Model : Early in the datamodel document in the Reference documentation is the statement: There is currently a single intrinsic mutable sequence type: This statement is followed by the documentation of Lists and Byte Arrays. The statement should read "There are currently two intrinsic mutable sequence types". -- assignee: georg.brandl components: Documentation messages: 80067 nosy: MLModel, georg.brandl severity: normal status: open title: Incorrect statement regarding mutable sequences in datamodel Reference versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4981> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4983] Spurious reference to "byte sequences" in Library stdtypes sequence documentation
New submission from Mitchell Model : The first sentence under "Sequence Types" in the Library stdtypes document is: There are five sequence types: strings, byte sequences, byte arrays, lists, tuples, and range objects However, subsequent discussion, as well as reality, use the term "bytes" not "byte sequences". -- assignee: georg.brandl components: Documentation messages: 80074 nosy: MLModel, georg.brandl severity: normal status: open title: Spurious reference to "byte sequences" in Library stdtypes sequence documentation versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4983> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4984] Inconsistent count of sequence types in Library stdtypes document
New submission from Mitchell Model : Sorry I didn't notice all the problems I've reported today about this paragraph at one time so I could have submitted only one report. Anyway, here's another problem with the first sentence of the Sequence Types section of the library stdtypes document. The sentence: There are five sequence types: strings, byte sequences, byte arrays, lists, tuples, and range objects lists six types but says their are five. -- assignee: georg.brandl components: Documentation messages: 80076 nosy: MLModel, georg.brandl severity: normal status: open title: Inconsistent count of sequence types in Library stdtypes document versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4984> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4981] Incorrect statement regarding mutable sequences in datamodel Reference
Mitchell Model added the comment: >Benjamin Peterson added the comment: > >Fixed in r68707. Sorry if I missed that. I checked some of the documentation problems I reported today against an updated subversion copy of 3.0 and 3.1, but I didn't check all. Got impatient. I'll be more careful. >-- >nosy: +benjamin.peterson >resolution: -> fixed >status: open -> closed > >___ >Python tracker ><http://bugs.python.org/issue4981> >___ -- --- Mitchell ___ Python tracker <http://bugs.python.org/issue4981> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5018] Overly general claim about sequence unpacking in tutorial
New submission from Mitchell Model : The datastructures section of the tutorial states with respect to "sequence unpacking" that "there is a small bit of asymmetry here: packing multiple values always creates a tuple, and unpacking works for any sequence". This is too general, as shown by the definition of assignment statement target in the simple_stmts section of the reference shows: tuples and lists are the only kinds of sequences that can appear on the left-hand side of an assignment statement. -- assignee: georg.brandl components: Documentation messages: 80307 nosy: MLModel, georg.brandl severity: normal status: open title: Overly general claim about sequence unpacking in tutorial versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5018] Overly general claim about sequence unpacking in tutorial
Mitchell Model added the comment: I've read those paragraphs many times. Oddly enough when you asked me for a rewording and I went back and read them again I found a very different interpretation than all the other times. I've always thought of unpacking as being about the variables on the left rather than the values on the right. Now that I am rethinking this I realize (a) that unpacking is always about both sides of the assignment and (b) the wording I criticized is actually precise and accurate, if a bit subtle. What I noticed this time is that "the sequence" in the sentence beginning "Sequence unpacking" refers to the sequence on the right, not the variables on the left, especially since "the variables on the left" are mentioned earlier in the sentence. Part of how I backed into the wrong corner with this is that the left- hand side of an unpacking can be a list as well as a tuple. I was checking to see if any other kinds of sequences could go on the left, which of course they can't. That's why I thought "works for any sequence" was wrong. If only a tuple could be on the left I think I would have realized what this was saying sooner. It was the fact that more than one kind of sequence could go on the left that got be sidetracked. Moreover, the example shows a target list and doesn't even show an explicit tuple or a list. So, it's being fairly informal, as is appropriate for a tutorial. However, with all that sorted out I now see a different problem: "multiple assignment is really just a combination of tuple packing and sequence unpacking". If there is an explicit tuple, or a list, on the left-hand side then there's no packing involved. In fact it's rather strange that one could put something like [x,y,z] on the left-hand side of the assignment. I suppose it must get converted during compilation to a tuple for multiple assignment -- it's not as if a list-valued variable could go there. Sorry about the long-winded meditation. Hope the exploration proves interesting and or valuable to someone! ___ Python tracker <http://bugs.python.org/issue5018> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5061] Inadequate documentation of the built-in function open
New submission from Mitchell Model : Documentation of the mode parameter of the built-in function open is insufficient with respect to what values are acceptable. (1) Right after the mode table, it states "For binary random access, the mode 'w+b' opens and truncates the file to 0 bytes, while 'r+b' opens the file without truncation." This is true of text random access too -- w+ or r+. Furthermore, the possibility of a+, while meaningful, is not mentioned. (2) The documentation does not, but should, say that while w/r/a with or without the plus can appear without a 'b' or 't', a plain 'b' as the mode valuable raises an error that r/w/a wasn't specified. (3) The documentation does not, but should, say that + cannot stand on its own -- the mode must also include an r, w, or a. The table listing the meanings of each value just says + means "open a disk file for updating (reading and writing)". Suggested rewording is to put the phrase "in conjunction with 'r', 'w', or 'a', open a disk file...". Alternatively, add a note to that table entry and explain below that the plus must accompany a r/w/a. -- assignee: georg.brandl components: Documentation messages: 80549 nosy: MLModel, georg.brandl severity: normal status: open title: Inadequate documentation of the built-in function open versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5061] Inadequate documentation of the built-in function open
Mitchell Model added the comment: In point (2) I should have written "a plain 'b' or 't'" and "value" not "valuable". Neither 't' nor 'b' can appear without a r/w/a. ___ Python tracker <http://bugs.python.org/issue5061> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5061] Inadequate documentation of the built-in function open
Mitchell Model added the comment:
>David W. Lambert added the comment:
>
>I disagree. You propose to examine the trees but ignore the forest.
>The perspective programmer needs to understand what is a file.
>
Could you be more specific about what parts of my comments you
disagree with? The current documentation leaves open the possibility
of someone thinking that random access doesn't apply to text files,
getting errors when entering the apparently legal, but in reality
not, 'b', and that '+', 't+', and 'b+' are legal whereas they require
a r, w, or a.
I know this bit of documentation has been stable for years, but in
doing some writing I got tripped up by trying to write an example
using just '+', despite being very knowledgeable about Python. At
that pointI experimented with the various combinations and compared
the reality against the documentation. What I ended up doing is
splitting the table in two and listing the + combinations explicitly:
Text or Binary:
t text
b binary
Read, Write, or Append:
r beginning, read
w beginning, write
a end, write
r+ beginning, read/write
w+ beginning, read/write
a+ end, read/write
--
--- Mitchell
Added file: http://bugs.python.org/file12864/unnamed
___
Python tracker
<http://bugs.python.org/issue5061>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5061] Inadequate documentation of the
built-in f
David W. Lambert
<lamber...@corning.com> added the comment:
I disagree. You propose to examine the trees but ignore the
forest.
The perspective programmer needs to
understand what is a file.
Could you be more specific about what parts of my comments you
disagree with? The current documentation leaves open the possibility
of someone thinking that random access doesn't apply to text files,
getting errors when entering the apparently legal, but in reality not,
'b', and that '+', 't+', and 'b+' are legal whereas they require a r,
w, or a.
I know this bit of documentation has been stable for years, but
in doing some writing I got tripped up by trying to write an example
using just '+', despite being very knowledgeable about Python. At that
pointI experimented with the various combinations and compared the
reality against the documentation. What I ended up doing is splitting
the table in two and listing the + combinations explicitly:
Text or Binary:
t
text
b
binary
Read, Write, or Append:
r
beginning, read
w
beginning, write
a end,
write
r+ beginning,
read/write
w+ beginning,
read/write
a+ end,
read/write
--
--- Mitchell
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5130] Obsolete reference to "unicode" in glossary
New submission from Mitchell Model : The glossary entry for "sequence" mentions the type "unicode", but that's gone. -- assignee: georg.brandl components: Documentation messages: 80943 nosy: MLModel, georg.brandl severity: normal status: open title: Obsolete reference to "unicode" in glossary versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5130> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5232] Setting font from preference dialog in IDLE on OS X broken
New submission from Mitchell Model : When setting the font in IDLE's Preferences dialog on OSX, having started IDLE from the command line, the font is changed and the following is printed: Exception in Tkinter callback Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/tkinter /__init__.py", line 1399, in __call__ return self.func(*args) File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib /configDialog.py", line 1125, in Ok self.Apply() File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib /configDialog.py", line 1129, in Apply self.DeactivateCurrentConfig() File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/idlelib /configDialog.py", line 1107, in DeactivateCurrentConfig winInstances = self.parent.instance_dict.keys() File "/Library/Frameworks/Python.framework/Versions/3.0/lib/python3.0/tkinter /__init__.py", line 1708, in __getattr__ return getattr(self.tk, attr) AttributeError: 'tkapp' object has no attribute 'instance_dict' -- components: IDLE messages: 81827 nosy: MLModel severity: normal status: open title: Setting font from preference dialog in IDLE on OS X broken versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5233] Enhance 2.7 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart
New submission from Mitchell Model : The main thing the patch does is: modify the subprocess restart procedure so that it reloads whatever file, if any, was loaded when IDLE first started and looked for IDLESTARTUP then PYTHONSTARTUP environment variables. In addition: a -q option is added for starting IDLE on the command line to mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or PYTHONSTARTUP The former effect of -s would now be the default, which is desirable so double-clicking an IDLE icon to start it will cause the startup file to run. -s is changed to take an argument that is an alternate startup file to use I am a bit concerned about changing -s to have a different meaning. Perhaps it's better to leave -s as an option that is simplhy superfluous and use a different letter for the alternate startup. -- components: IDLE files: PyShell-2.7.diff keywords: patch messages: 81831 nosy: MLModel severity: normal status: open title: Enhance 2.7 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file13058/PyShell-2.7.diff ___ Python tracker <http://bugs.python.org/issue5233> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5234] Enhance 3.1 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart
New submission from Mitchell Model : The main thing the patch does is: modify the subprocess restart procedure so that it reloads whatever file, if any, was loaded when IDLE first started and looked for IDLESTARTUP then PYTHONSTARTUP environment variables. In addition: a -q option is added for starting IDLE on the command line to mean "quiet", as with Emacs, e.g., to suppress loading of IDLESTARTUP or PYTHONSTARTUP The former effect of -s would now be the default, which is desirable so double-clicking an IDLE icon to start it will cause the startup file to run. -s is changed to take an argument that is an alternate startup file to use I am a bit concerned about changing -s to have a different meaning. Perhaps it's better to leave -s as an option that is simplhy superfluous and use a different letter for the alternate startup. -- components: IDLE files: PyShell-3.1.diff keywords: patch messages: 81832 nosy: MLModel severity: normal status: open title: Enhance 3.1 IDLE to exec IDLESTARTUP/PYTHONSTARTUP on restart type: behavior versions: Python 3.1 Added file: http://bugs.python.org/file13059/PyShell-3.1.diff ___ Python tracker <http://bugs.python.org/issue5234> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5232] Setting font from preference dialog in IDLE on OS X broken
Mitchell Model added the comment: At 10:56 PM + 02/12/09, Ned Deily wrote: >Ned Deily added the comment: > >FWIW, I am not able to reproduce this using a release3.0 IDLE (so with >today's patches) built with the default Apple-supplied Tcl/Tk in 10.5. >Are you using a newer Tcl/Tk? Does it happen if you move your current >preferences out of ~/.idlerc? > It does still happen if I move my preferences. And move my .Idle.py. I did build it with a newer Tk -- 8.5 installed as a Framework. (And I switched the order of /System/Library/Frameworks and /Library/Frameworks, which makes more sense. I thought I had seen that as an Issue, but it must have been just a web page where I saw it. Similarly, I added /opt/local/lib and /opt/local/include in detect_modules before the directories that are added, so that it finds the readline I installed with "port".) So, I started again with a fresh checkout. I didn't switch the order of the Frameworks directories, and I tried it with and without the directories for readline. I started Python manually, imported Tk, checked it's version, etc. to confirm I was getting the Apple installation. If I try to run bin/idle from the 3.1 Frameworks version directory I get a segmentation fault. I've seen a lot of weird behavior over the years in my many configuration and installation escapades across a wide variety of software, but I've never seen a seg fault with anything to do with Python. I have the "do you want to report this" backtrace if you're interested. A little later I'll try this from scratch on a clean, though PowerPC (G4), machine and see what happens. ___ Python tracker <http://bugs.python.org/issue5232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5232] Setting font from preference dialog in IDLE on OS X broken
Mitchell Model added the comment: OK, so I built 3.1 on a clean (G4) system instead of my highly tangled Intel and didn't get the seg fault. I guess the issue isn't real. ___ Python tracker <http://bugs.python.org/issue5232> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5267] Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
New submission from Mitchell Model : After checking out 3.0 and 3.1 and building them on a Mac (Leopard, Intel) when I subsequently try to do "svn update" I get the error: svn: Directory 'Mac/PythonLauncher/Python Launcher.app/.svn' containing working copy admin area is missing As a result, "svn update" fails. Removing PythonLauncher.app fixes. This problem does NOT happen in Python2.6 even though there's no PythonLauncher.app/.svn there either. I don't know enough about subversion to disentangle this. And in fact there is a .svn directory in Mac/IDLE/Idle.app but none in PythonLauncher.app. "make clean" doesn't remove the .app's; perhaps it should. [Am I mistaken in building my subversion directories?] -- components: Build messages: 82135 nosy: MLModel severity: normal status: open title: Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5268] VMSError not documented in Doc/library/exceptions.rst
New submission from Mitchell Model : Lib/test/exception_hierarchy.txt shows VMSError but it is not mentioned in Doc/library/exceptions.rst -- assignee: georg.brandl components: Documentation messages: 82137 nosy: MLModel, georg.brandl severity: normal status: open title: VMSError not documented in Doc/library/exceptions.rst versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5268> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5267] Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
Mitchell Model added the comment: >Ned Deily added the comment: > >There are various steps in the Mac build process where the files are >copied from the build source to the build destination and then .svn >directories (among other things) are removed. Perhaps you tried building >using the source directory as the destination directory? > See my previous message. The question is whether I should be doing the build from the src directory. It works fine in all respects -- it creates a build subdirectory and does everything in there. For IDLE.app it does create a .svn but for PythonLauncher.app it doesn't. Either "make clean" or something else I'm not doing should remove all of the .app packages entirely or the build process should leave behind a .svn in each of the .app packages. Are there build instructions somewhere that say I should be doing something other than what I'm doing? I really want to know. I've been hanging out in the background studying, using, and teaching Python for years, building it on Mac G4's and an Intel MacBook Pro, and even on Window machines, but am only now starting to contribute to the community, so I appreciate any guidance or clarification anyone wants to offer. ___ Python tracker <http://bugs.python.org/issue5267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5276] IDLE startup file .Idle.py not documented
New submission from Mitchell Model : The following behavior should be documented but it is not: If the user has a .Idle.py file IDLE will run it when it starts up. This is independent of running IDLESTARTUP or PYTHONSTARTUP when the -s switch is given. It is run by Tk.readprofile as called from Tk.__init__. The "Idle" comes from the name passed to TK() when PyShell.py creates its Tk root. In fact, not only is it independent, but it works differently: any imports done in .Idle.py go into Tk's name space, whereas IDLESTARTUP/PYTHONSTARTUP is exec'd and imports go into the interpreter's namespace. Note that the 'I' in '.Idle.py' is really uppercase, which will matter on case-sensitive platforms. -- assignee: georg.brandl components: Documentation, IDLE messages: 82186 nosy: MLModel, georg.brandl severity: normal status: open title: IDLE startup file .Idle.py not documented versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5276> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5267] Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
Mitchell Model added the comment: >Martin v. Löwis added the comment: > >How precisely did you build? Can you check whether any build step >removed PythonLauncher, then recreated it? in the svn directory for, say, py3k % svn update % make clean % ./configure --enable-frameworks % make % sudo make install > >If you remove Python Launcher.app, you should be able to svn update. Yes, that's what I've been doing. ___ Python tracker <http://bugs.python.org/issue5267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5267] Subversion problem with PythonLauncher after building 3.0 or 3.1 on Mac
Mitchell Model added the comment: Sorry -- msg 82178 refers to "my previous message" but I sent them out of order. The "previous message" was 82190, just below 82178. ___ Python tracker <http://bugs.python.org/issue5267> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5281] Slight inconsistency in documentation appearances of RuntimeError
New submission from Mitchell Model :
The Library Exceptions documentation describes RuntimeException as "mostly
a relic from a previous version of the interpreter; it is not used very
much any more." Yet, the Reference in describing the raise statement uses
RuntimeException as an example:
raise RuntimeError("foo occurred").with_traceback(tracebackobj)
This seems slightly misleading. It might be better to just use Exception
as the example there.
--
assignee: georg.brandl
components: Documentation
messages: 82241
nosy: MLModel, georg.brandl
severity: normal
status: open
title: Slight inconsistency in documentation appearances of RuntimeError
versions: Python 3.0, Python 3.1
___
Python tracker
<http://bugs.python.org/issue5281>
___
___
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 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 <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 <http://bugs.python.org/issue6057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://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 <http://bugs.python.org/issue20060> ___ ___ 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 "", line 1, in TypeError: unsupported operand type(s) for +: 'foo' and 'int' >>> foo() < 1 Traceback (most recent call last): File "", line 1, in 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 <http://bugs.python.org/issue20077> ___ ___ 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 <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 <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
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 <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 <http://bugs.python.org/issue20103> ___ ___ Python-bugs-list mailing list Unsubscribe: https://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 : 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 <http://bugs.python.org/issue6472> ___ ___ 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 : 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 <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 : 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 <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 : 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 <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 : 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 <http://bugs.python.org/issue6489> ___ ___ 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 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 <http://bugs.python.org/issue6487> ___ ___ 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 :
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
<http://bugs.python.org/issue6679>
___
___
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 : 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 <http://bugs.python.org/issue6805> ___ ___ 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 : 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 <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 : 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 <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 : 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 <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 : 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 <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 :
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
<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 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 <http://bugs.python.org/issue6892> ___ ___ 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 :
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
<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 : 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 <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
Mitchell Model 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 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 > <http://bugs.python.org/issue6903> > ___ -- ___ Python tracker <http://bugs.python.org/issue6903> ___ ___ 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 : 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 <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 : 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 <http://bugs.python.org/issue6936> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7000] optional second argument of string.keywords not documented
New submission from Mitchell Model : string.capwords has an optional second argument, sep, which is not documented -- assignee: georg.brandl components: Documentation messages: 93139 nosy: MLModel, georg.brandl severity: normal status: open title: optional second argument of string.keywords not documented versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7000> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7007] Tiny inconsistency in the orthography of "url encoded" in the doc of urllib.parse
New submission from Mitchell Model : The documentation of urllib.parse contains: URL encoded a “url-encoded” string I am not sure what the official usage is, either in Python or more generally. Actually, in formal W3C documents the term used is percent- encoding (with the hyphen, even when used as a noun). I don't expect anyone to use "percent-encoding" but maybe, especially as an adjective, the phrase in Python documentation should consistently be "url-encoded"? -- messages: 93179 nosy: MLModel severity: normal status: open title: Tiny inconsistency in the orthography of "url encoded" in the doc of urllib.parse versions: Python 3.0, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue7007> ___ ___ 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 : 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 <http://bugs.python.org/issue7226> ___ ___ 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 : 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 <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 : 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 <http://bugs.python.org/issue7489> ___ ___ 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
New submission from Mitchell Model : The documentation of format on the builtin functions page should be changed from "Convert a string or a number" to "Convert a value". The documentation begins "Convert a string or a number". This is misleading in that format can be called on any value, since there is an Object.__format__ and classes can define their own __format__ method. PEP 3101 is explicit about all of this and the documentation of __format__ ends by noting that "format(value, format_spec) merely calls value.__format__(format_spec)". typeobject.c implements Object.__format__ with a note about PEP 3101. Given all of that I don't see why format should be explained as taking a string or a number as its first argument. -- assignee: georg.brandl components: Documentation messages: 82616 nosy: MLModel, georg.brandl severity: normal status: open title: Documentation of format implies only strings and numbers are acceptable arguments versions: Python 2.6, Python 2.7, Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5348> ___ ___ 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 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
<http://bugs.python.org/issue5348>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5348] Documentation of format implies
only strin
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
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5357] Last paragraph of urllib.request.urlopen documentation is garbled
New submission from Mitchell Model : The last two sentences of the last paragraph of the documentation of urllib.request.urlopen are shown below. I have broken up the text to comment on places where it appears to be garbled. It might be easier to just rewrite the two sentences rather than trying to make the corrections I'm suggesting. The urlopen function from the previous version, "the previous version" --> "previous versions" Python 2.6 and earlier, of the module urllib has been discontinued as urlopen can return the file-object as the previous. either one or more words are missing from the end of the sentence or the last part of the sentence starting with "as" needs repair The proxy handling, "handling" --> "handler"? which in earlier "earlier" --> "earlier versions"? was passed as a dict parameter to urlopen can be availed need comma after "urlopen" "availed" --> "obtained" or better, perhaps: "can be obtained by using ProxyHandler objects" instead of "by the use of" by the use of ProxyHandler objects. -- assignee: georg.brandl components: Documentation messages: 82652 nosy: MLModel, georg.brandl severity: normal status: open title: Last paragraph of urllib.request.urlopen documentation is garbled versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5357> ___ ___ 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 : "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 <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 : -- components: +Documentation -Distutils ___ Python tracker <http://bugs.python.org/issue5363> ___ ___ 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 : 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 <http://bugs.python.org/issue5371> ___ ___ 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 : 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 <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 :
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
<http://bugs.python.org/issue5419>
___
___
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 : 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 <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 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
<http://bugs.python.org/issue5426>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5426] README slight error re
OSX
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
___
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 : 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 <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 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
<http://bugs.python.org/issue5426>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5426] README slight error re
OSX
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
___
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 : 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 <http://bugs.python.org/issue5469> ___ ___ 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 : 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 <http://bugs.python.org/issue5513> ___ ___ 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 added the comment: At 11:03 AM -0400 3/19/09, Mitchell L Model wrote: >>Martin v. Löwis 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 <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 : 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 <http://bugs.python.org/issue5519> ___ ___ 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 : 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 <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 :
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
<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 : 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 <http://bugs.python.org/issue5602> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5603] Garbled sentence in documentation of urllib.request.urlopen
New submission from Mitchell Model : The middle sentence of the last paragraph of the documentation of urllib.request.urlopen is garbled, reading: "The urlopen function from the previous version, Python 2.6 and earlier, of the module urllib has been discontinued as urlopen can return the file-object as the previous." Perhaps the easiest way to say what is intended is "urllib.request.urlopen replaces the function urllib.urlopen from versions of Python before 3.0". -- assignee: georg.brandl components: Documentation messages: 84490 nosy: MLModel, georg.brandl severity: normal status: open title: Garbled sentence in documentation of urllib.request.urlopen versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue5603> ___ ___ 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 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
<http://bugs.python.org/issue5601>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5601] webbrowser doesn't just open
browsers
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
___
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 added the comment:
whoops
Sorry for the garbage in the previous message.
--
--
--- Mitchell
--
Added file: http://bugs.python.org/file13533/unnamed
___
Python tracker
<http://bugs.python.org/issue5601>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5601] webbrowser doesn't just open
browsers
whoops
Sorry for the garbage in the previous message.
--
--
--- Mitchell
___
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 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
<http://bugs.python.org/issue5601>
___
<!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
-->Re: [issue5601] webbrowser doesn't just open
browsers
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
___
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 : 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 <http://bugs.python.org/issue5650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
