[issue12960] threading.Condition is not a class
Eli Bendersky added the comment: > What do you suggest? Replace it by class threading._Condition? -1 on this IMHO just documenting the situation as it is would make more sense -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12960> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13003] Bug in equivalent code for itertools.izip_longest
New submission from Eli Bendersky : Regarding the sample code in: http://docs.python.org/library/itertools#itertools.izip_longest If an IndexError is raised inside an iterator in the "equivalent" code from the docs, the generator stops and the error is swallowed. If an IndexError is raised inside an iterator in the "izip_longest_next" code in CPython's "Modules/itertoolsmodule.c", the generator stops and the error propagates. --- Reported by Adam Forsyth on the docs mailing list. More details in this SO discussion: http://stackoverflow.com/questions/7392902/izip-longest-in-itertools-how-does-rasing-indexerror-inside-the-iterator-work -- assignee: docs@python components: Documentation messages: 144228 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Bug in equivalent code for itertools.izip_longest versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13003] Bug in equivalent code for itertools.izip_longest
Eli Bendersky added the comment: What about at least documenting it? Since a real user ran into this and reported it as a problem, I think it would make sense to make the discrepancy explicit. Alternatively a generalized note can be added to the documentation of itertools stating that the "equivalent" code samples are only approximate and differ in small details from the real implementations. -- ___ Python tracker <http://bugs.python.org/issue13003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13161] problems with help() documentation of __i*__ operators
New submission from Eli Bendersky : Report from Joao Carneiro in the docs@ maillist: I would like to report that I found a mistake in the document of "help(set)". In the document all the __i*__ methods are described exactly like the same methods without i before the name. Copied from the document: __ixor__(...) x.__ixor__(y) <==> x^y __xor__(...) x.__xor__(y) <==> x^y I suppose that the __ixor__ would mean x^=y and not x^y like the __xor__ method right? This problem also occurs for: __iand__ __ior__ __isub__ The report is on Python 3.2, but the problem also exists in 2.7 It appears that the problem's source is in Objects/typeobject.c, where the __i*__ operators are defined with the IBSLOT macro. The documentation string is the operator, passed to IBSLOT - for __ixor__ it's "^", while it should probably be "^=" -- assignee: docs@python components: Documentation messages: 145411 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: problems with help() documentation of __i*__ operators versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13161> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13191] Typo in argparse documentation
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
New submission from Eli Bendersky : Operator <> was removed in Python 3, but still appears in Grammar/Grammar (and hence in Doc/reference/grammar.rst) Reported by Alexander Ivanyuta on the docs mailing list -- assignee: docs@python components: Documentation, Interpreter Core messages: 146070 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Remove <> operator from Grammar/Grammar versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Eli Bendersky added the comment:
The relevant code in Parser/parsetok.c is:
#ifdef PY_PARSER_REQUIRES_FUTURE_KEYWORD
if (type == NOTEQUAL) {
if (!(ps->p_flags & CO_FUTURE_BARRY_AS_BDFL) &&
strcmp(str, "!=")) {
err_ret->error = E_SYNTAX;
break;
}
else if ((ps->p_flags & CO_FUTURE_BARRY_AS_BDFL) &&
strcmp(str, "<>")) {
err_ret->text = "with Barry as BDFL, use '<>' "
"instead of '!='";
err_ret->error = E_SYNTAX;
break;
}
}
#endif
Hmm... I'm too new to remember this joke, but here it presents a practical
problem - since Grammar/Grammar is being directly reflected into the
documentation (.. literalinclude:: ../../Grammar/Grammar) and thus can confuse.
Is it safe to just remove the whole thing from Grammar/Grammar and
correspondingly Parser/parsetok.c ?
--
___
Python tracker
<http://bugs.python.org/issue13239>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Changes by Eli Bendersky : -- nosy: +barry, brett.cannon, fdrake, ncoghlan ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13352] tutorial section 9.3.3 documentation problem
New submission from Eli Bendersky : User report on the docs@ list: - http://docs.python.org/tutorial/classes.html#instance-objects I think the "counter" attribute is mentioned for the first time in the example code, not "in Instance of MyClass created above", i.e. class MyClass does not contain "counter" attribute. "x.counter = 1 while x.counter < 10: x.counter = x.counter * 2 print x.counter del x.counter" Best Regards, Jussi Peltonen -- assignee: docs@python components: Documentation keywords: easy messages: 147137 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: tutorial section 9.3.3 documentation problem versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13353] documentation problem in logging.handlers.TimedRotatingFileHandler for 2.7
New submission from Eli Bendersky : User (Yoann Roman) report on docs@ maillist: The docs for logging.handlers.TimedRotatingFileHandler in Python 2.7 say that the "utc" keyword argument was added in 2.7: http://docs.python.org/library/logging.handlers.html#timedrotatingfilehandler This isn't correct, however, since it was available as of 2.6 (I verified the source as well): http://docs.python.org/release/2.6/library/logging.html#timedrotatingfilehandler It did appear to change to True/False in 2.7 instead of 0/1 in 2.6. I'd recommend changing it to indicate this or removing the fact that this was added in 2.7 altogether. -- assignee: docs@python components: Documentation keywords: easy messages: 147138 nosy: docs@python, eli.bendersky priority: low severity: normal status: open title: documentation problem in logging.handlers.TimedRotatingFileHandler for 2.7 versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13353> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13352] tutorial section 9.3.3 documentation problem
Eli Bendersky added the comment: Yep, I agree, Ori. The paragraph immediately preceding the code sample says: "Data attributes need not be declared; like local variables, they spring into existence when they are first assigned to [...] the following piece of code will print the value 16, without leaving a trace" Which is what the code sample demonstrates. -- ___ Python tracker <http://bugs.python.org/issue13352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13352] tutorial section 9.3.3 documentation problem
Changes by Eli Bendersky : -- resolution: -> invalid status: open -> closed ___ Python tracker <http://bugs.python.org/issue13352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13365] str.expandtabs documentation is wrong
Eli Bendersky added the comment: While we're at it, wouldn't it be clearer to say "... where each tab character is replaced by..."? -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13365] str.expandtabs documentation is wrong
Eli Bendersky added the comment: Other than that, the patch looks good. -- ___ Python tracker <http://bugs.python.org/issue13365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13368] Possible problem in documentation of module subprocess, method send_signal
New submission from Eli Bendersky : docs@ list report by Daniel Dieterle: in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug. CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%29.aspx . A workaround using CTRL_C_EVENT nevertheless is described here: http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-objects-on-windows/7980368#7980368 -- I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT. A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong. -- assignee: docs@python components: Documentation messages: 147272 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Possible problem in documentation of module subprocess, method send_signal versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13368> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13365] str.expandtabs documentation is wrong
Eli Bendersky added the comment: Committed. Thanks for contributing. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13191] Typo in argparse documentation
Changes by Eli Bendersky : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Eli Bendersky added the comment: Attaching a patch with a clarifying comment in Grammar/Grammar. Should be enough for now? -- keywords: +patch Added file: http://bugs.python.org/file23656/issue13239.patch ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13368] Possible problem in documentation of module subprocess, method send_signal
Eli Bendersky added the comment: Brian, I see this text (along with the implementation) was added by you in 60197:0ab89e8bdedc Could you state your opinion on this issue? -- nosy: +brian.curtin ___ Python tracker <http://bugs.python.org/issue13368> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13161] problems with help() documentation of __i*__ operators
Changes by Eli Bendersky : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue13161> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Changes by Eli Bendersky : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13385] Add an explicit re.NOFLAGS flag value to the re module
New submission from Eli Bendersky : The flags 're' accept are numeric underneath, and the current value of "no flags" is just 0, which is also specified in the documentation as the default value. However, using raw numeric values is not a good programming practice. The suggestion is to add a simple re.NOFLAGS constant to the 're' module with the value of 0, and use it in the documentation instead of plain 0. It's a simple change that won't break anything and may provide better readability for some code, as well as remove the need for plain integer references in the documentation. See also issues #11957 and #12875. Adding to nosy people taking part in discussion of the aforementioned issue. If you're not interested, please remove yourself - I apologize in advance. -- components: Library (Lib), Regular Expressions messages: 147443 nosy: eli.bendersky, eric.araujo, eric.smith, ezio.melotti, terry.reedy priority: normal severity: normal status: open title: Add an explicit re.NOFLAGS flag value to the re module versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue13385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13385] Add an explicit re.NOFLAGS flag value to the re module
Eli Bendersky added the comment: Antoine, what's the outcome of people wondering about the difference? I don't see what's bad about it, it's not as if people are writing (or supposed to write) code that does arithmetic on these flag values. Their only usage is to: 1. Provide no flags 2. Provide a single flag 3. Provide a few flags ORed together The "OR" (which makes no mathematical sense in this case) is bad enough, but why not provide an easy fix for (1), making it explicit instead of implicit. I think we sometimes forget that not everyone who picks up Python is an old C dog, familiar with these tricks. To newbies for whom Python is the first language, these flags aren't very intuitive to use, I imagine. -- ___ Python tracker <http://bugs.python.org/issue13385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Eli Bendersky added the comment: Amaury & Georg, Grepping through the docs disagrees with your claims ;-) Try to grep for "\=None\]" to see what I mean. There are tons of places where default values are placed inside the brackets. For example in http://docs.python.org/library/csv.html --> look at: sniff(sample[, delimiters=None]) or even: class csv.DictReader(csvfile[, fieldnames=None[, restkey=None[, restval=None[, dialect='excel'[, *args, **kwds]) That said, I have absolutely no objections to following an accepted convention. But what is it? I looked around, and found the following in the documentation guide: http://docs.python.org/dev/py3k/documenting/fromlatex.html There is no optional command. Just give function signatures like they should appear in the output: .. function:: open(filename[, mode[, buffering]]) Description. This (taken from the 3.3 guide) mentions the 2.x guideline and doesn't mention default values. So what should I do here? According to Ezio's earlier message, the new style (without brackets) is also being used in Python 2 now. I can do the switch for the 're' module, but can we first get the convention documented somewhere? -- ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Eli Bendersky added the comment: Ezio, what do you suggest to do regarding *this* issue? -- ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12767] document threading.Condition.notify
Eli Bendersky added the comment: I propose the attached patch for the documentation. Any objections? -- keywords: +patch Added file: http://bugs.python.org/file23657/issue12767.1.patch ___ Python tracker <http://bugs.python.org/issue12767> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12768] docstrings for the threading module
Eli Bendersky added the comment: Graeme, any news on this? If you re-do the patch for current tip and address the review comments, I think we can commit it. -- ___ Python tracker <http://bugs.python.org/issue12768> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12188] PEP 7 (or guide) add C style policies and explanation
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue12188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11173] Undocumented public APIs in Python 3.2
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue11173> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3849] FUD in documentation for urllib.urlopen()
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue3849> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10838] subprocess __all__ is incomplete
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue10838> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5088] optparse: inconsistent default value for append actions
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue5088> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10501] make_buildinfo regression with unquoted path
Changes by Eli Bendersky : -- nosy: -eli.bendersky ___ Python tracker <http://bugs.python.org/issue10501> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Eli Bendersky added the comment: Hmm, I've just notice that this [default=val] pattern already exists in the 're' docs in 2.7, for example: subn(repl, string[, count=0]) So my change was consistent within the documentation of this module. No doubt, the conventions are currently a mess ;-) I suggest to just convert the whole 're' RST page to the new 3.x convention (i.e. model it after the same RST in the default branch). Is this acceptable? If yes, I will submit a patch for review first. -- ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12767] document threading.Condition.notify
Eli Bendersky added the comment: Ezio, thanks for the catch. I missed that one. Attaching a new, fixed patch. -- Added file: http://bugs.python.org/file23658/issue12767.2.patch ___ Python tracker <http://bugs.python.org/issue12767> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13385] Add an explicit re.NOFLAGS flag value to the re module
Eli Bendersky added the comment: I think we have enough < 0 to reject the issue. Closing. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue13385> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Eli Bendersky added the comment: I have converted the Doc/library/re.rst doc of 2.7 to follow the new convention of 3.x, patch attached. -- keywords: +patch Added file: http://bugs.python.org/file23668/issue12875.1.patch ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13239] Remove <> operator from Grammar/Grammar
Eli Bendersky added the comment: Éric, do you feel strongly about the wording, or can I just go ahead and commit my version if I like it more :) ? -- ___ Python tracker <http://bugs.python.org/issue13239> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
New submission from Eli Bendersky : Our Hg repo has some useful hooks on commit messages that allow to specify which issue to notify for commits, and which issue to close. AFAIU, it's currently documented only in the code of the hook (http://hg.python.org/hooks/file/tip/hgroundup.py). I think adding a short description into the devguide would be a good idea, probably here: http://docs.python.org/devguide/committing.html#commit-messages-and-news-entries +1d by Brett and Georg on pydev. I'll prepare a patch. -- assignee: eli.bendersky components: Devguide messages: 147520 nosy: brett.cannon, eli.bendersky, ezio.melotti, georg.brandl priority: normal severity: normal status: open title: document hg commit hooks in the devguide ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13386] Document documentation conventions for optional args
Eli Bendersky added the comment: You should also explicitly specify what happens in several optional but not keyword args are needed. AFAIU the convention is: func(arg1, arg2[, opt1, opt2]) -- ___ Python tracker <http://bugs.python.org/issue13386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: Attaching a patch with the suggested change. Based on the doc-string in the implementation of the hook. -- keywords: +patch Added file: http://bugs.python.org/file23669/issue13388.1.patch ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: Petri, I have actually tried to stay consistent within the same document, and it uses ' for this level of heading. Perhaps it's just not following the Sphinx guide? IIRC the restructured text parser will also shout at you if these are inconsistent. -- ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: Nice, I didn't know about issue #2771 ;-) Will update the patch! -- ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12875] backport re.compile flags default value documentation
Changes by Eli Bendersky : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12875> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: An updated patch attached, explaining that several issues can be mentioned in a single commit message -- Added file: http://bugs.python.org/file23683/issue13388.2.patch ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13386] Document documentation conventions for optional args
Eli Bendersky added the comment: Ezio, regarding your latest message: "The problem is when the default placeholder is some unique object() or some _internal value (we had something similar with a socket timeout once)." I hope this should be rare enough not to present a significant problem with the _convention_. Such cases can be reviewed specifically and the best way to document will be discussed per case. "Also for something like str.strip(), would you document chars=None or chars=" \n\r\t\v\f"?" I think it would be better to document chars=None, because this is a simple value the user can pass (if he wants to do it explicitly), without thinking (and forgetting) about the specific delimeters. That None actually means " \n\r\t\v\f" should be explicitly documented below the function signature, of course. -- ___ Python tracker <http://bugs.python.org/issue13386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11836] multiprocessing.queues.SimpleQueue is undocumented
Eli Bendersky added the comment: Sandro - yep, the sentinels arg is also undocumented in multiprocessing.PipeConnection.recv() and further down the road... -- ___ Python tracker <http://bugs.python.org/issue11836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11836] multiprocessing.queues.SimpleQueue is undocumented
Eli Bendersky added the comment: However, sentinels *are* mentioned in the multiprocessing doc, below multiprocessing.Process: " sentinel A numeric handle of a system object which will become “ready” when the process ends. On Windows, this is an OS handle usable with the WaitForSingleObject and WaitForMultipleObjects family of API calls. On Unix, this is a file descriptor usable with primitives from the select module. You can use this value if you want to wait on several events at once. Otherwise calling join() is simpler. New in version 3.3. " >From a cursory glance on the implementation in >Lib/multiprocessing/connection.py, this is the same sentinel. -- ___ Python tracker <http://bugs.python.org/issue11836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13386] Document documentation conventions for optional args
Eli Bendersky added the comment: What you say makes sense, now I just have to dig up where I saw instances of [, opt1, opt2] If anything, this is another proof that such conventions must be agreed upon and meticulously documented. -- ___ Python tracker <http://bugs.python.org/issue13386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13386] Document documentation conventions for optional args
Eli Bendersky added the comment: ""So would it be worth the effort to identify each such place in the built-ins/stdlib and eventually change them all? I've seen support for doing so in other tracker issues and think it's a good idea personally."" Probably, if this will bring some added value in addition to being easier to document. -- ___ Python tracker <http://bugs.python.org/issue13386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11836] multiprocessing.queues.SimpleQueue is undocumented
Eli Bendersky added the comment: Then it appears to me that Sandro's patch is good and can be committed. -- ___ Python tracker <http://bugs.python.org/issue11836> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: Committed, with the fix suggested by Éric -- resolution: fixed -> stage: committed/rejected -> status: closed -> open ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13386] Document documentation conventions for optional args
Eli Bendersky added the comment: Eric, Spot on :-) This is *exactly* the reason that led me to open issue 12875, which eventually led to this one. -- ___ Python tracker <http://bugs.python.org/issue13386> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13388] document hg commit hooks in the devguide
Eli Bendersky added the comment: Éric, feel free to fix it to your heart's desire ;-) I think that having it documented is far more important than nuances in nomenclature, so I'm -0 on this. -- ___ Python tracker <http://bugs.python.org/issue13388> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13402] Document absoluteness of sys.executable
Eli Bendersky added the comment: LGTM -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13402> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13443] wrong links and examples in the functional HOWTO
New submission from Eli Bendersky : Michał Chałupczak reported in this docs@ list that the links to IBM developerworks articles are wrong. >From some additional observation, the code samples on the 3.x page use the >external `functional` module, which was not ported to Python 3 at all. I wonder whether it makes sense to use external modules in official Python documentation, since these are not guaranteed to be ported. This issue is a good example of this happening. The HOWTO should be probably rewritten to use only the stdlib. The links to IBM developerworks should be, IMHO, removed, since they point to articles written in 2001 and have code samples that won't work on Python 3.x -- assignee: docs@python components: Documentation messages: 148030 nosy: akuchling, docs@python, eli.bendersky priority: normal severity: normal status: open title: wrong links and examples in the functional HOWTO versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue13443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13443] wrong links and examples in the functional HOWTO
Eli Bendersky added the comment: Andrew, thanks, but I still think it's a bigger problem that the page discusses a module which is not available on Python 3.x - this means that a user following the page can't just type in the code and make it run. The links can be fixed and kept there, as Éric suggests, perhaps with a disclaimer, but code on the page itself should be valid - this is part of our official documentation, after all. -- ___ Python tracker <http://bugs.python.org/issue13443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13443] wrong links and examples in the functional HOWTO
Eli Bendersky added the comment: > Before doing that, would you have the time to contact its author and inquire > about porting plans? I hope to find the time. I was also thinking about an alternative - since the HOWTO probably uses just a handful of functions from that module perhaps they can just be re-implemented and placed in the HOWTO. This can remove the unhealthy dependency on an external module, as well as provide some extra examples. -- ___ Python tracker <http://bugs.python.org/issue13443> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13494] 'cast' any value to a Boolean?
Eli Bendersky added the comment: 'bool' is just one of many conversion functions that convert their argument to the type they designate. Does this doc problem only exist for 'bool' or also for 'int', 'float' and others? -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13494> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on How To Link With libpython
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue1040439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Eli Bendersky added the comment: Éric, this is for embedding a Python interpreter in a C/C++ application. I tend to agree that the official doc page (http://docs.python.org/extending/embedding.html) on this topic is somewhat lacking in the area of the configuration/compilation procedure. There's some info scattered around the web in tutorials, though. So I'd say it's a valid issue. -- ___ Python tracker <http://bugs.python.org/issue1040439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1040439] Missing documentation on how to link with libpython
Eli Bendersky added the comment: Antoine, this is a big improvement - LGTM. -- ___ Python tracker <http://bugs.python.org/issue1040439> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13003] Bug in equivalent code for itertools.izip_longest
Eli Bendersky added the comment: Yep, it appears that Raymond has fixed this in changeset b0065b9087ef -- resolution: wont fix -> fixed ___ Python tracker <http://bugs.python.org/issue13003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13527] Remove obsolete mentions in the GUIs page
Eli Bendersky added the comment: +1 -- keywords: +easy nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13530] Docs for os.lseek neglect to mention what it returns
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13530> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13574] refresh example in doc for Extending and Embedding
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13686] Some notes on the docs of multiprocessing
New submission from Eli Bendersky : I've decided to study the multiprocessing module a bit, and carefully went over the docs (for 2.7). Some small fixes I will commit myself, but a few issues came up on which I'd like some opinion from others. In rough order of appearance in the doc: 1. In the documentation of the 'name' argument of the multiprocessing.Process constructor, it mentions that the length of the generated name depends on the "generation", without elaborating. It could be better to briefly describe the algorithm in a sentence or two. 2. Section 16.6.2.1. is called "Process and exceptions". It only documents one exception from multiprocessing: BufferTooShort. Other exception classes exported by the module aren't documented similarly: ProcessError, TiemoutError, AuthenticationError. 3. AuthenticationError is documented as multiprocessing.connection.AuthenticationError, although in reality it exists in the root multiprocessing module, and multiprocessing.connection just imports it 4. The doc of JoinableQueue.task_done() says "Used by queue consumer threads". Shouldn't that be "consumer processes"? 5. The doc of active_children() should probably mention that it returns a list of Process objects (similarly to what current_process() says) 6. multiprocessing.freeze_support() says "If the freeze_support() line is omitted then trying to run the frozen executable will raise RuntimeError.". *Who* will raise the error? 7. class multiprocessing.Event says "This method returns..." - what method? Seems like an irrelevant documentation piece was intermixed here 8. 16.6.2.7. Managers starts by saying that Managers provide a way to create data which can be shared between different processes. Since it comes right after the section about Shared objects, I think it would be nice to mention in a sentence or two what Managers give above normal synchonized objects in multiprocessing (i.e. sharing between different machines) 9. In the programming guidelines about "Avoid shared state" it says "It is probably best to stick to using queues or pipes for communication between processes rather than using the lower level synchronization primitives from the threading module.". Surely not the "threading" module is meant here? -- assignee: docs@python components: Documentation messages: 150409 nosy: docs@python, eli.bendersky, pitrou priority: normal severity: normal status: open title: Some notes on the docs of multiprocessing type: behavior versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue13686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13686] Some notes on the docs of multiprocessing
Eli Bendersky added the comment: 10. Unless I'm missing something entirely obvious, except in the examples it says that Value has a "value" attribute for actual data access. One is expected to look in the docs of ctypes to find that? -- ___ Python tracker <http://bugs.python.org/issue13686> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13709] Capitalization mistakes in the documentation for ctypes
Eli Bendersky added the comment: And while we're at it, I would consider revising both sentences in a more fundamental way, since they're too chatty for the official docs. -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue13709> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12003] documentation: alternate version of xrange seems to fail.
Eli Bendersky added the comment: Éric, I'm not sure that the note is necessary at all, but once it's there, it should value *correctness* over conciseness and readability. -- ___ Python tracker <http://bugs.python.org/issue12003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12003] documentation: alternate version of xrange seems to fail.
Eli Bendersky added the comment: Agreed. Fix committed & issue closed. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12003> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12126] incorrect select documentation
Eli Bendersky added the comment: Closing this issue, since it specifically refers to the select error which was fixed. Tracking the removal of the sockets howto document can be done elsewhere. -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue12126> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11015] Bring test.support docs up to date
Eli Bendersky added the comment: Ezio, you're right, there are still a lot of undocumented symbols (functions, classes, globals). I compiled a list of those I could not find in the .rst docs, excluding ones that are only used in regrtest.py itself: -- get_attribute record_original_stdout/get_original_stdout unload unlink rmtree make_legacy_pyc IPV6_ENABLED TESTFN_ENCODED TESTFN_UNENCODABLE sortdict check_syntax_error open_urlresource CleanImport DirsOnSysPath transient_internet captured_output captured_stderr gc_collect python_is_optimized set_memlimit bigmemtest precisionbigmemtest bigaddrspacetest requires_resource cpython_only impl_detail check_impl_detail no_tracing refcount_test modules_setup / modules_cleanup threading_setup / threading_cleanup reap_threads reap_children swap_attr swap_item strip_python_stderr TestHandler Matcher patch -- -- ___ Python tracker <http://bugs.python.org/issue11015> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9382] os.popen referenced but not documented in Python 3.x
Eli Bendersky added the comment: os.popen() is certainly deprecated. Its documentation in both 2.6 and 2.7 notes: Deprecated since version 2.6: This function is obsolete. Use the subprocess module. Indeed, the Python 3.x library/os.rst doc mentions it several times, but the documentation was removed. I don't think this is following the rules of deprecation. If it was decided to keep os.popen alive, it *should* be documented in 3.x, possibly retaining the deprecation notice. -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue9382> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12188] PEP 7, C style: add ++ policy and explanation
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12188> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12223] Datamodel documentation page: 'operator' where 'operand' should be
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11583] os.path.isdir() is slow on windows
Eli Bendersky added the comment: Brian - great, thanks. -- ___ Python tracker <http://bugs.python.org/issue11583> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12223] Datamodel documentation page: 'operator' where 'operand' should be
Eli Bendersky added the comment: >From a cursory look at reference/datamodel and library/operator, I see no >other instances of this error. I didn't read every word, however (just grepped >for possible operator/operand mismatches). Also, AFAICS this error is only in 2.7 - the 3.x docs don't have the relevant paragraphs at all. -- ___ Python tracker <http://bugs.python.org/issue12223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12380] bytearray methods center, ljust, rjust don't accept a bytearray as the fill character
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12380> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12223] Datamodel documentation page: 'operator' where 'operand' should be
Changes by Eli Bendersky : -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue12223> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12043] Update shutil documentation
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12043> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Eli Bendersky added the comment: In my opinion, it's the error messages and docstrings that should be changed, not the documentation. This module was introduced in 2.6 and moves on to 2.7, and there's no reason to have it throw confusing errors for the sake of easier back-patching from 3.x However, when I run this example on 2.6, I get: TypeError: can't write str to text stream Which (arguably) makes sense, since the docs explicitly say that "Text I/O classes work with unicode data." -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12531] documentation index entries for * and **
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Eli Bendersky added the comment:
The difference between 2.6 and 2.7 stems from the rewrite of the IO library in
C that was made for 2.7
The error Terry sees gets thrown here (in Modules/_io/stringio.c):
if (!PyUnicode_Check(obj)) {
PyErr_Format(PyExc_TypeError, "string argument expected, got '%s'",
Py_TYPE(obj)->tp_name);
return NULL;
}
Therefore, I propose to change this error message to:
"unicode argument expected, got '%s'"
as Terry suggested.
Adding Antoine, Benjamin and Daniel (listed as experts on IO) to nosy.
Is there an objection to making this change in the error message?
--
nosy: +benjamin.peterson, pitrou, stutzbach
___
Python tracker
<http://bugs.python.org/issue12434>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12531] documentation index entries for * and **
Eli Bendersky added the comment: Peter, doesn't your patch also refer to the meaning of * and ** in function definitions? I would argue that the missing reference is to a paragraph further down: [...] If the syntax *expression appears in the function call, expression must evaluate to a sequence. Elements from this sequence [...] Terry, the glossary you compiled certainly looks comprehensive. However, I wouldn't delay local fixes like the one discussed here until "the grand scheme" is committed. -- ___ Python tracker <http://bugs.python.org/issue12531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12380] bytearray methods center, ljust, rjust don't accept a bytearray as the fill character
Eli Bendersky added the comment: On one hand, I agree that the situation isn't intuitive. Why should some methods of bytearray accept bytearrays, and some shouldn't? On the other hand, this actually has rather deep implementation reasons. Methods like 'translate' are implemented in Objects/bytearrayobject.c On the other hand, ljust, rjust and center are taken from stringlib. Now, stringlib is generic code, and has some strict argument checking. For example, in stringlib_ljust: if (!PyArg_ParseTuple(args, "n|c:ljust", &width, &fillchar)) return NULL; The 'c' format to PyArg_ParseTuple expects an object that passes PyBytes_Check, IOW a bytes object or a subclass thereof. bytearray is not a subclass of bytes, hence the problem. The solution could be global, to allow bytearray fit the 'c' format of PyArg_ParseTuple. Then one would also be able to pass a bytearray into other stringlib methods requiring the 'c' format. One way or the other, this is of course doable. A decision has to be made though - is the nuisance annoying enough to warrant such an API change? -- ___ Python tracker <http://bugs.python.org/issue12380> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12574] Documentation for Queue in 2.x has an incorrect title
Eli Bendersky added the comment: > The documentation for Queue in all versions of Python 2.7 and 2.6 (see > http://docs.python.org/release/2.6.7/library/queue.html#module-Queue for > the 2.7 docs) has the title "queue -- A synchronized queue class." The > module, however, is named "Queue" in all of 2.x. So, while the title is > appropiate for 3.x, it's incorrect for 2.x. > > I can make a patch, as well. > Sure, make a patch for 2.7 (the 2.6 line is now in "security only" mode). Eli -- nosy: +eli.bendersky Added file: http://bugs.python.org/file22676/unnamed ___ Python tracker <http://bugs.python.org/issue12574> ___ The documentation for Queue in all versions of Python 2.7 and 2.6 (see http://docs.python.org/release/2.6.7/library/queue.html#module-Queue"; target="_blank">http://docs.python.org/release/2.6.7/library/queue.html#module-Queue for the 2.7 docs) has the title "queue -- A synchronized queue class." The module, however, is named "Queue" in all of 2.x. So, while the title is appropiate for 3.x, it's incorrect for 2.x. I can make a patch, as well.Sure, make a patch for 2.7 (the 2.6 line is now in "security only" mode).Eli ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12574] Documentation for Queue in 2.x has an incorrect title
Changes by Eli Bendersky : -- resolution: -> fixed status: open -> closed ___ Python tracker <http://bugs.python.org/issue12574> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Eli Bendersky added the comment: > > Therefore, I propose to change this error message to: > > "unicode argument expected, got '%s'" > > as Terry suggested. > > > > Sounds good to me. > Terry, what are your thoughts? Can I commit the fix? -- Added file: http://bugs.python.org/file22694/unnamed ___ Python tracker <http://bugs.python.org/issue12434> ___ > Therefore, I propose to change this error message to: >  "unicode argument expected, got '%s'" >  as Terry suggested. > Sounds good to me.Terry, what are your thoughts?Can I commit the fix? ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Changes by Eli Bendersky : Removed file: http://bugs.python.org/file22687/unnamed ___ Python tracker <http://bugs.python.org/issue12434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Changes by Eli Bendersky : Removed file: http://bugs.python.org/file22694/unnamed ___ Python tracker <http://bugs.python.org/issue12434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12531] documentation index entries for * and **
Eli Bendersky added the comment: Peter, would you like to submit a corrected patch? -- ___ Python tracker <http://bugs.python.org/issue12531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12540] "Restart Shell" command leaves pythonw.exe processes running
Changes by Eli Bendersky : -- nosy: +eli.bendersky ___ Python tracker <http://bugs.python.org/issue12540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12434] Strengthen 2.7 io types warning
Changes by Eli Bendersky : -- resolution: -> fixed status: open -> closed versions: -Python 2.7 ___ Python tracker <http://bugs.python.org/issue12434> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12540] "Restart Shell" command leaves pythonw.exe processes running
Eli Bendersky added the comment: Is the problem happening only on 64-bit Windows, or 32-bit as well? -- ___ Python tracker <http://bugs.python.org/issue12540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11049] add tests for test.support
Eli Bendersky added the comment: Alright, since *some* tests are better than no tests at all, I will try to combine the patches currently attached to the issue, port them to the Hg repo and commit. -- ___ Python tracker <http://bugs.python.org/issue11049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11049] add tests for test.support
Eli Bendersky added the comment: Brett, what do you mean by "listed as an essential test in regrtest". The regrtest.STDTESTS list? -- ___ Python tracker <http://bugs.python.org/issue11049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11049] add tests for test.support
Eli Bendersky added the comment: This changeset incorporates Giampaolo's patch with a minor fix in `test.support.python_is_optimized` (which returned '' for False sometimes). -- ___ Python tracker <http://bugs.python.org/issue11049> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12540] "Restart Shell" command leaves pythonw.exe processes running
Eli Bendersky added the comment: OK, I can reproduce the problem on a clean virtual machine running a pristine XP home SP2. No Python was previously installed. Steps to reproduce: 1. Install Python 3.2.1 MSI from http://www.python.org/download/releases/3.2.1/ 2. Run IDLE from start menu 3. Close IDLE 4. A pythonw.exe process stays running after IDLE has exited Running steps 2-3 N times leaves N pythonw.exe processes alive -- ___ Python tracker <http://bugs.python.org/issue12540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12540] "Restart Shell" command leaves pythonw.exe processes running
Eli Bendersky added the comment: Am I missing something, or is there no explicit command to kill the subprocess on Windows in PyShell.py The kill_subprocess method (which does get invoked) of ModifiedInterpreter is: def kill_subprocess(self): try: self.rpcclt.close() except AttributeError: # no socket pass self.unix_terminate() self.tkconsole.executing = False self.rpcclt = None The subprocess is started with: self.rpcpid = os.spawnv(os.P_NOWAIT, sys.executable, args) Could it be that in earlier versions this ensured the subprocess exited with its parent, but this somehow got modified? Note that the same code existed in PyShell.py for ages, so it's unlikely that the culprit is there. -- ___ Python tracker <http://bugs.python.org/issue12540> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
