[issue3332] DocTest and dict sort.
endolith added the comment: The fundamental purpose of doctest is to test that examples in documentation work correctly: To check that a module’s docstrings are up-to-date by verifying that all interactive examples still work as documented. To perform regression testing by verifying that interactive examples from a test file or a test object work as expected. To write tutorial documentation for a package, liberally illustrated with input-output examples. Depending on whether the examples or the expository text are emphasized, this has the flavor of “literate testing” or “executable documentation”. https://docs.python.org/2/library/doctest.html (and this is not at all the purpose of the unittest module) If a function returns a set, and the normal way to use it is to call the function and get a set, then the example should be to call the function and get a set: function() set([1, 2, 3]) Doctest should therefore be able to test that the example actually works and returns the correct set, regardless of how the set elements are displayed. It should not be required to add unusual extra code to format the output specifically so that doctest can understand it: function() == set([1, 2, 3]) True (This is not a realistic example, because the user wouldn't know what the output is until they call the function.) sorted(function()) [1, 2, 3] (This is not how the method is actually used in reality. It returns a set for a reason, not a list.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3332 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3332] DocTest and dict sort.
endolith added the comment:
I ran into this bug with sets, too.
Expected:
{6, 5, 3}
Got:
set([5, 3, 6])
Documentation should illustrate how the function is actually meant to be used,
not contrived examples that convert to sorted output purely so that doctest can
understand them. doctest should be changed (or have an option) to understand
object equality rather than exact text output.
--
nosy: +endolith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue3332
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13698] Mailbox module should support other mbox formats in addition to mboxo
endolith endol...@gmail.com added the comment: - If the mailbox is written using the mboxrd format and read using the mboxo format, lines that were meant to start with From are changed to From . This is a new type of corruption. Well, yes. So the choices are: mboxrd as default: Sometimes results in corruption mboxo as default: Always results in corruption Is there a way to reliably detect the format of the file and produce an error if it seems to be reading it wrong? If not, maybe just include a function that guesses the format so the correct option can be found easily? If there are consecutive quoted lines, like this, for instance: This is the body. From my point of view there are 3 lines. then it was probably encoded with mboxrd? If instead you find: This is the body. From my point of view there are 3 lines. then it was probably encoded with mboxo? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14694] Option to show leading zeros for bin/hex/oct
New submission from endolith endol...@gmail.com: Suggestion: Add an option to bin/hex/oct functions to format binary output with a minimum fixed width, including leading zeros. Also might be useful for hex and oct. Currently, bin(18) produces '0b10010' with this change, something like bin(18, foo=8) would produce '0b00010010' Examples of people wanting this: http://stackoverflow.com/questions/3258330/converting-from-hex-to-binary-without-losing-leading-0s-python http://stackoverflow.com/questions/1002116/can-bin-be-overloaded-like-oct-and-hex-in-python-2-6 http://stackoverflow.com/a/1425558/125507 https://www.linuxquestions.org/questions/programming-9/in-python-printing-leading-zero-for-hex-numbers-0-through-f-719426/ -- components: Interpreter Core messages: 159623 nosy: endolith priority: normal severity: normal status: open title: Option to show leading zeros for bin/hex/oct type: enhancement versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14694 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13698] Mailbox module should support other mbox formats in addition to mboxo
endolith endol...@gmail.com added the comment: Ok. I'm not sure what backwards compatibility issues would exist, though. The only difference is that mboxrd converts \nFrom → \nFrom \nFrom → \nFrom making the conversion reversible, while mboxo does \nFrom → \nFrom \nFrom → \nFrom (no change) which is ambiguous, and both get converted back to \nFrom when converting back to text, corrupting the original message. mboxrd is essentially a bugfix for mboxo rather than a fundamentally different format. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13698] Should not use mboxo format
New submission from endolith endol...@gmail.com: The documentation states: Several variations of the mbox format exist to address perceived shortcomings in the original. In the interest of compatibility, mbox implements the original format, which is sometimes referred to as mboxo. http://docs.python.org/dev/library/mailbox.html#mailbox.mbox But this format is fundamentally broken, corrupting lines that start with From , and I can't find any justification for using it in Python. In fact, all four links included in that section argue against this format. If only one mbox format is used, it should be mboxrd. Otherwise, include support for all the variants, with mboxrd as the default. -- components: Library (Lib) messages: 150478 nosy: endolith priority: normal severity: normal status: open title: Should not use mboxo format type: behavior versions: Python 2.7, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13698] Mailbox module should not use mboxo format
Changes by endolith endol...@gmail.com: -- title: Should not use mboxo format - Mailbox module should not use mboxo format ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13698 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3907] for line in file doesn't work for pipes
New submission from endolith [EMAIL PROTECTED]: One of the principles of Python is that There should be one-- and preferably only one --obvious way to do it. It seems that the for line in file idiom is The Way to iterate over the lines of a file, and older more explicit methods are deprecated. PEP 234 says that this: for line in file: ... is equivalent to this: for line in iter(file.readline, ): ... or this: while 1: line = file.readline() if not line: break ... However, for line in file does not behave the same as the other two if the file is a named pipe. This is presumably due to the hidden read-ahead buffer in the low-level implementation of the next() method of the file iterator (http://docs.python.org/lib/bltin-file-objects.html), meant to increase the speed at which it reads regular physical files. Since not enough data exists in the pipe to fill the buffer yet, the lines are only read in a burst after the buffer has been filled or when the pipe is closed. My application is monitoring a pipe for new lines from a logging program, and I want each line read as soon as it is written. Sure, there are other ways to get this functionality, but I don't see why for line in file shouldn't behave the same way for any file-like object. I wonder if it can be made to internally use the read-ahead buffer for closed physical files, and a different method for open named pipes. I wonder if reading pipes character-by-character causes any significant slowdown compared to the read-ahead buffer when the pipe resides in memory instead of a disk. Forgive me if this is not really a bug, but it seems to my beginner eyes that things are not working the way they should. http://python-forum.org/pythonforum/viewtopic.php?t=9300 http://ubuntuforums.org/showthread.php?t=916518 -- components: Interpreter Core messages: 73419 nosy: endolith severity: normal status: open title: for line in file doesn't work for pipes type: behavior versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3907 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3544] expection typo
New submission from endolith [EMAIL PROTECTED]: http://docs.python.org/lib/typecontextmanager.html if any expection that occurred should be suppressed -- assignee: georg.brandl components: Documentation messages: 71035 nosy: endolith, georg.brandl severity: normal status: open title: expection typo ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3544 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
