[issue4404] os.listdir() documentation error
New submission from steve21 <[EMAIL PROTECTED]>: The documentation entry for os.listdir(path) at html docs at http://docs.python.org/dev/3.0/library/os.html#module-os says: "os.listdir(path) Return a list containing the names of the entries in the directory. The list is in arbitrary order. It does not include the special entries . and .. even if they are present in the directory. Availability: Unix, Windows. This function can be called with a bytes or string argument. In the bytes case, all filenames will be listed as returned by the underlying API. In the string case, filenames will be decoded using the file system encoding, and skipped if a decoding error occurs." The problem is that nowhere it the above documentation does it describe what the 'path' argument should be ! However, if I do $ Python3.0 >>> import os >>> help(os.listdir) # it does describe 'path' Help on built-in function listdir in module posix: listdir(...) listdir(path) -> list_of_strings Return a list containing the names of the entries in the directory. path: path of directory to list The list is in arbitrary order. It does not include the special entries '.' and '..' even if they are present in the directory. It looks like the html docs are missing some information and out of sync with the module docs. -- assignee: georg.brandl components: Documentation messages: 76307 nosy: georg.brandl, steve21 severity: normal status: open title: os.listdir() documentation error versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4404> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4478] shutil.copyfile documentation
New submission from steve21 <[EMAIL PROTECTED]>: $ python3.0 Python 3.0rc3 (r30rc3:67312, Nov 22 2008, 21:38:46) >>> import shutil >>> shutil.copyfile('/tmp/f', '/tmp/f') Traceback (most recent call last): File "", line 1, in File "/a/lib/python3.0/shutil.py", line 47, in copyfile raise Error("`%s` and `%s` are the same file" % (src, dst)) shutil.Error: `/tmp/f` and `/tmp/f` are the same file The Python 3 docs at http://docs.python.org/dev/3.0/library/shutil.html#module-shutil mention that copyfile can raise IOError, but they omit to mention that copyfile can also raise shutil.Error. Also, just out of interest, I notice that Sphinx now supports the ':raises:' field. Are there any plans for the Python documentation to start using it? -- assignee: georg.brandl components: Documentation messages: 76673 nosy: georg.brandl, steve21 severity: normal status: open title: shutil.copyfile documentation versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4478> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4776] distutils documentation
New submission from steve21 : 'data_files' and 'package_dir' are arguments for distutils.core.setup that some packages use in their setup.py. However, the manual entry for distutils.core. setup, at http://docs.python.org/dev/3.0/distutils/apiref.html#module-distutils.core does not document these arguments. -- assignee: georg.brandl components: Documentation messages: 78502 nosy: georg.brandl, steve21 severity: normal status: open title: distutils documentation versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue4776> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5031] Thread.daemon docs
New submission from steve21 : In the threading module the Thread.daemon documentation says: "The thread’s daemon flag. This must be set before start() is called, otherwise RuntimeError is raised. The initial value is inherited from the creating thread. The entire Python program exits when no alive non-daemon threads are left." I think the docs should state Thread.daemon's type (boolean, or integer, or something else?) and its default value (when you have not set .daemon in the creating thread.) -- assignee: georg.brandl components: Documentation messages: 80361 nosy: georg.brandl, steve21 severity: normal status: open title: Thread.daemon docs versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue5031> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5032] itertools.count step
New submission from steve21 : I'd like to request a 'step' argument be added for itertools.count. It would be useful in the same way that step is useful for the 'range' function. ('range' and 'count' are very similar - 'count' could even be merged into 'range', for example by making 'range(None)' equivalent to 'count()') -- components: None messages: 80368 nosy: steve21 severity: normal status: open title: itertools.count step type: feature request versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue5032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5032] itertools.count step
steve21 added the comment: Here's a couple of functions I use with count and step: def cf_e(): '''return: (iterator) the infinite continued fraction for e e=[2; 1, 2, 1, 1, 4, 1, 1, 6, 1 , ... , 1, 2k, 1, ...] ''' yield 2 for k in itertools.count(2, 2): yield 1 yield k yield 1 def prime_factors(n): '''n: (int > 1) return: (list) the sorted list of tuples (p,e) of prime factors of n p is a prime factor, e is the number of times the factor is used ''' ret = [] if n <= 1: return ret # factors: use known (small) primes, then possible primes (odd numbers) for factor in itertools.chain([2,3,5,7,11], itertools.count(13, 2)): if factor*factor > n: if n != 1: ret += [(n, 1)] break for e in itertools.count(0): div, mod = divmod(n, factor) if mod != 0: break n = div if e >= 1: ret += [(factor, e)] return ret ___ Python tracker <http://bugs.python.org/issue5032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5032] itertools.count step
steve21 added the comment: I already use the second version of the count function you give (without default arguments which I am not a big fan of). I'm not saying its difficult or unreadable to bypass itertools.count and write your own enhanced count function. But if I use a custom count function, you use a custom count function, and possibly many others too, then there could be a common requirement for a step argument and it might be a good idea too make it more widely available. Haskell has a powerful and concise list notation, some of which Python has already borrowed from: multiple3 = [3,6..] ___ Python tracker <http://bugs.python.org/issue5032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6765] math.log, log10 inconsistency
New submission from steve21 : $ python3.1 Python 3.1 (r31:73572, Jul 6 2009, 21:21:12) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import math >>> math.log10(1000) 3.0 >>> math.log(1000, 10) 2.9996 You would expect the results to be the same. Internally math.log() could call math.log10() when base==10. That would ensure they are consistent. -- components: Library (Lib) messages: 91886 nosy: steve21 severity: normal status: open title: math.log, log10 inconsistency versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6765] math.log, log10 inconsistency
steve21 added the comment: Mark, "... that's what log10 is there for". That would be a good point if the documentation said that. However, all the docs for log10 say is: math.log10(x) Return the base-10 logarithm of x. So we have a python function log10() which looks like it is redundant since we can use log(a, 10) instead. But it actually functions differently to log(a, 10), and the Python user would never know this from looking at the documentation. I think Tim Peters missed one important guideline in his "The Zen of Python". The principle of least astonishment (or surprise) - when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the human user or programmer at the time the conflict arises. Its easy for the python developer to ignore this guideline. They know the implementation, and are rarely surprised by inconsistent behaviour since they have seen it before, or even created it without documenting it. If Python functions are inconsistent then I think they should either be made consistent, or if that's not possible they should be clearly documented as being inconsistent. The docs for log(x[, base]) could be improved to say: "this function preserves the consistency of log(a,b) == log(a)/log(b) but breaks consistency with log(a,10) == log10(a)" The docs for log10(x) could be improved to say: "this function gives the correct result for powers of 10, but breaks consistency with log(a,10) == log10(a)" -- ___ Python tracker <http://bugs.python.org/issue6765> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6771] documentation/implementation error
New submission from steve21 : The documentation and implementation disagree. Documentation: "Module curses.wrapper Convenience function to ensure proper terminal setup and resetting on application entry and exit. ... 15.10. curses.wrapper — Terminal handler for curses programs This module supplies one function, wrapper() ... curses.wrapper.wrapper(func, ...) Wrapper function that initializes curses .. " Implementation: $ python3.1 Python 3.1.1 (r311:74480, Aug 24 2009, 14:50:57) [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import curses.wrapper as cw >>> cw.wrapper Traceback (most recent call last): File "", line 1, in AttributeError: 'function' object has no attribute 'wrapper' The 'curses.wrapper.wrapper' function no longer exists. The 'curses.wrapper' module no longer exists, the module is now a function. The problem is the line from curses.wrapper import wrapper in curses/__init__.py - curses has clobbered its own namespace and made the curses.wrapper module inaccessible. Instead of this tortuous sequence of module hiding and namespace clobbering it would be simpler to just place the curses.wrapper.wrapper function in curses/__init__.py and do away with the need for the curses.wrapper single-function-module. And update the docs so: references to the curses.wrapper module are removed the function curses.wrapper.wrapper(func, ...) becomes curses.wrapper.(func, ...) -- components: Library (Lib) messages: 91903 nosy: steve21 severity: normal status: open title: documentation/implementation error versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6771> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
Changes by steve21 : -- nosy: +steve21 ___ Python tracker <http://bugs.python.org/issue3451> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6228] round() error
New submission from steve21 : I wish to round the float 697.04157958254996 to 10 decimal digits after the decimal point. $ python3.0 Python 3.0.1 (r301:69556, Jun 7 2009, 14:51:41) [GCC 4.3.2 20081105 (Red Hat 4.3.2-7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> 697.04157958254996 697.04157958254996 # python float can represent this number exactly >>> 697.0415795825 # this is the expected result 697.04157958250005 # this is the closest python float representation >>> round(697.04157958254996, 10) 697.04157958259998 # error round() gives a result that is closer to 697.0415795826 than the expected result of 697.0415795825 - it has not rounded to the closest 10th decimal digit after the decimal point. (python 2.6.2 has the same problem) -- messages: 89029 nosy: steve21 severity: normal status: open title: round() error type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue6228> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com