[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: Done now. Thanks, Zbyszek -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: Both appear to be commonly used. Both sound OK to me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
New submission from Zbyszek Szmek zbys...@in.waw.pl: http://docs.python.org/dev/faq/design.html#why-are-floating-point-calculations-so-inaccurate This whole paragraph is wrong since #9337 (Make float.__str__ behave identically to float.__repr__). The str() function prints fewer digits and this often results in the more sensible number that was probably intended: 1.1 - 0.9 0.20007 print(1.1 - 0.9) 0.2 Applies from 3.2 onwards. -- assignee: docs@python components: Documentation messages: 155300 nosy: docs@python, zbysz priority: normal severity: normal status: open title: float rounding examples in FAQ are outdated versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: On 03/10/2012 12:26 PM, Mark Dickinson wrote: Mark Dickinsondicki...@gmail.com added the comment: Proposed rewrite: Hi, thanks for the quick reply. If we were to rewrite the whole entry, some more changes could be done: I think it would be useful to mention explicitly that Python simply uses the native floating-point implementation in hardware and thus behaves very similarly to other languages which do this, for instance C or Java. This should clear up a lot of the behaviour for people who know other programming languages. how the underlying platform handles floating-point says something very similar, but the reader needs to understand what the underlying platform exactly is. It is easy to count, that exactly 17 digits are accurate. I have to admit, that I'm completely lost here --- why would a vastly inaccurate number (with more than half of digits wrong) be ever stored? If 1.2 is converted to a float (a C double in current implementation), it has 15.96 decimal digits of precision. Similarly, the result of a floating-point operation must be rounded to fit into the fixed precision, often resulting in another tiny error. ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: [part mangled by the tracker] 1.1999555910790149937383830547332763671875 which is accurate to around 16 decimal digits.) It is easy to count, that exactly 17 digits are accurate. I have to admit, that I'm completely lost here --- why would a vastly inaccurate number (with more than half of digits wrong) be ever stored? If 1.2 is converted to a float (a C double in current implementation), it has 15.96 decimal digits of precision. Similarly, the result of any floating-point operation must often be rounded to fit into the internal format, resulting in another tiny error. Similarly, the result of a floating-point operation must be rounded to fit into the fixed precision, often resulting in another tiny error. ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: Proposed rewrite (building on Mark's version): - mention C doubles - explain ``1.2`` example a bit more Why are floating-point calculations inaccurate? --- Users are often surprised by results like this:: 1.2 - 1.0 0.16 and think it is a bug in Python. It's not. This has little to do with Python, and much more to do with how the underlying platform handles floating-point numbers. The float type in CPython simply uses C ``double`` for storage. The number is stored in binary floating-point with a fixed precision (typically 53 bits) and Python uses C operations, which in turn rely on the hardware implementation in the processor, to perform floating-point operations. This means that as far as floating-point operations are concerned, Python behaves like many popular languages including C and Java. Many numbers that can be written easily in decimal notation (``1.2``, for example), cannot be expressed exactly in the binary format. After:: x = 1.2 the value stored for ``x`` is a (very good) approximation of the value ``1.2``, but is not exactly equal to it. On a typical machine, the actual stored value is:: 1.0011001100110011001100110011001100110011001100110011 (binary) which is approximately:: 1.19995559 (decimal) 53 binary digits are equivalent to about 16 decimal digits and in this case the first 17 digits are correct after the conversion back to decimal. Similarly, the result of any floating-point operation must be rounded to fit into the fixed precision, often resulting in another tiny error. For a more detailed explanation of what's involved, please see the chapter on :ref:`floating point arithmetic tut-fp-issues` in the Python tutorial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14245] float rounding examples in FAQ are outdated
Zbyszek Szmek zbys...@in.waw.pl added the comment: On 03/10/2012 07:52 PM, Martin v. Löwis wrote: - explain ``1.2`` example a bit more +1 for giving the binary representation; -1 for rounding the decimal version of it. Oh, 1.1999555910790149937383830547332763671875 is exactly equal to 1.0011001100110011001100110011001100110011001100110011. In this case yes, rounding it is not beneficial. So one more version (without this rounding): Why are floating-point calculations inaccurate? --- Users are often surprised by results like this:: 1.2 - 1.0 0.16 and think it is a bug in Python. It's not. This has little to do with Python, and much more to do with how the underlying platform handles floating-point numbers. The float type in CPython simply uses C ``double`` for storage. The number is stored in binary floating-point with a fixed precision (typically 53 bits) and Python uses C operations, which in turn rely on the hardware implementation in the processor, to perform floating-point operations. This means that as far as floating-point operations are concerned, Python behaves like many popular languages including C and Java. Many numbers that can be written easily in decimal notation (``1.2``, for example), cannot be expressed exactly in the binary format. After:: x = 1.2 the value stored for ``x`` is a (very good) approximation of the value ``1.2``, but is not exactly equal to it. On a typical machine, the actual stored value is:: 1.0011001100110011001100110011001100110011001100110011 (binary) which is exactly:: 1.1999555910790149937383830547332763671875 (decimal) 53 binary digits are equivalent to about 16 decimal digits and in this case the first 17 digits are correct after the conversion back to decimal. Similarly, the result of any floating-point operation must be rounded to fit into the fixed precision, often resulting in another tiny error. For a more detailed explanation of what's involved, please see the chapter on :ref:`floating point arithmetic tut-fp-issues` in the Python tutorial. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14245 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] argparse: provide a simple way to get a programmatically useful list of options
Zbyszek Szmek zbys...@in.waw.pl added the comment: ZSH can just present it in a prettier way, and also includes slightly more info (the short explanations, ordering). could print out enough information for both systems. Exactly. ZSH can use bash completion, but then it doesn't display the extra info. It would be nice to keep those optional features in mind to avoid limiting the exported information to that useful for bash. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14101] example function in tertools.count is misindented
New submission from Zbyszek Szmek zbys...@in.waw.pl: Indentation is broken. diff --git a/Modules/itertoolsmodule.c b/Modules/itertoolsmodule.c --- a/Modules/itertoolsmodule.c +++ b/Modules/itertoolsmodule.c @@ -3221,10 +3221,10 @@ Return a count object whose .__next__() method returns consecutive values.\n\ Equivalent to:\n\n\ def count(firstval=0, step=1):\n\ -x = firstval\n\ -while 1:\n\ -yield x\n\ -x += step\n); +x = firstval\n\ +while 1:\n\ +yield x\n\ +x += step\n); -- assignee: docs@python components: Documentation, Library (Lib) files: itertools-count-indentation.diff keywords: patch messages: 154084 nosy: docs@python, zbysz priority: normal severity: normal status: open title: example function in tertools.count is misindented type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file24618/itertools-count-indentation.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14101 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Zbyszek Szmek zbys...@in.waw.pl added the comment: OK, I guess that this could now be closed, since 13609 has been commited. (It is currently reopened, but the proposed tweaks wouldn't influence the usage in argparse, even if accepted). I'm attaching a patch which updates the tests to the new $COLUMNS logic. Previously, unsetting COLUMNS would fix the width on 80, now setting COLUMNS=80 is the proper way to do this. -- Added file: http://bugs.python.org/file24602/issue13041.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23241/patch1.1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23238/patch1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file24152/patch2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Zbyszek Szmek zbys...@in.waw.pl added the comment: I suppose here is where I should volunteer to update the patch file... @GraylinKim: do you still intend to work on this? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
Zbyszek Szmek zbys...@in.waw.pl added the comment: Maybe this could be closed? I'm attaching a small patch with a documentation clarification. (Adds In either case the list of subdirectories is retrieved before the tuples for the directory and its subdirectories are generated.). -- keywords: +patch Added file: http://bugs.python.org/file24603/issue13779.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] argparse: provide a simple way to get a programmatically useful list of options
Zbyszek Szmek zbys...@in.waw.pl added the comment:
zsh completion is much more powerful. E.g. for gitSPlogSPTAB I see:
completing head
list-of-heads
completing commit object name
completing cached file
abspath.c git-lost-found.sh README
aclocal.m4 git-merge-octopus.shreflog-walk.c
...
gitSPTAB
completing alias
diffab-- alias for 'diff --src-prefix=a/ --dst-prefix=b/'
lol -- alias for 'log --graph --decorate --pretty=oneline
--abbrev-commit'
lola -- alias for 'log --graph --decorate --pretty=oneline
--abbrev-commit --all'
mergeu-- alias for 'merge --ff-only @{u}'
completing main porcelain command
add -- add file contents to index
am-- apply patches from a mailbox
...
The header parts ('completing commit object name', 'completing head',
'completing cached file') are in bold red. So different completions
types are supported, and some help is provided, and completions
are split in groups.
Completion for options knows which short/long options go together:
git log -TAB prints:
...
--oneline -- shorthand for
--pretty=oneline --abbrev-commit
--ours-2 -- diff against our branch
version
--parents -- display parents of commit
--patch -u -p -- generate diff in patch
format
...
fish (a friendly interactive shell which I don't use but
which has some very cool features) prints something like
a\%b
(Branch)
abspath.c
(C source code, 4.2kB)
abspath.o
(Object code, 13kB)
aclocal.m4
(M4 macro, 1.4kB)
adres
(File, 23B)
advice.c
(C source code, 2.4kB)
advice.h
(C header, 555B)
I think that for --help-options to be usefull, it should list more information
than is needed just for bash completion. At least:
- options, with long and short options specified together
- short help for options (or maybe all of the help)
- option groups if such are used
- metavar names
This last part could be used by the completion script to customize completions
for a specific program. E.g. the completion script could know that FILE means a
file,
and HOST means a host name.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4256
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Stdout can be connected to a pipe, e.g to less, which in turn might be connected to a terminal. The program can then display output properly scaled for the terminal, assuming that because stdin is connnected to a terminal, output will eventually reach the same terminal. Sometimes this is true, sometimes not. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: New try (I fixed my email address and the patch). The purpose of os.get_terminal_size() is the same as `stty size`, so `stty size` could be a model for behavior of os.get_terminal_size(). I guess that this fallback will make some things easier. As long it is documented, the user should be able to get whatever behaviour they want. I have four small questions: - -1 is used as the argument meaning try stdout and stdin. But -1 is also used the error return value for open(2) and other system functions. I know that Python checks the return value to throw an exception, and -1 shouldn't leak and be passed by mistake to os.get_terminal_size(). Can someone confirm that this is the case? - Why stderr is not checked too? It would make os.get_terminal_size() return the real terminal value in a the middle of a pipe: cat | python -c 'import os; os.get_terminal_size()' | cat. - some doc change is missing - in the new version the line with ioctl(fd, TIOCGWINSZ, w) repeats three times. It think it could be reduced to two without loss of readability. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Wouldn't this be quite unwieldy to use: os.get_terminal_size(sys.__stdout__.fileno(), sys.__stdin__().fileno(), sys.__stderr__.fileno()) ? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Using strace, I see that stty calls ioctl(TIOCGWINSZ) on stdin (fd=0) if it failed on stdout (fd=1), whereas Python only tries stdout. It was done this way by design. Maybe checking stdin can be also useful, but it is a rather big change in semantics. I think it should be a separate bug. It is pretty common for programs to behave differently when run through pipe, even if stdin is on a tty. stty is rather the exception than the rule. E.g. almost all programs disable color when piped explicitly through less. 'dpkg | cat' ignores terminal width. So does git and ls. stty is special, because the only purpose of that program is to query terminal size, but it cannot be taken as a model for the behaviour of a general purpose program. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Hi, looking at the tests, the test should be skipped with 'stty invocation failed'. Does something different happen? Can you post the output from the tests? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Thanks for merging! I'll try to keep an eye on the buildbot results, but please add me to any bugs in case I miss something. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Well, right now it's just one function. Functionality which you propose could of course be useful, but let's leave if for another day, another issue. See also http://bugs.python.org/issue13609#msg149627 and #444582 and #12442 -- shutil is growing in different directions, and terminal size can be one of them. Antoine Pitrou added the comment: except Exception clauses in the tests are too broad. Fixed. Otherwise, looks fine. STINNER Victor added the comment: - shutil.get_terminal_size(): I would prefer columns and lines variable names instead of ccc and rrr Changed (this was a leftover from the version when there was no named tuple). - I would prefer os.get_terminal_size() instead of os.query_terminal_size(), I didn't know other function using the verb query in Python Changed. I used os.g_t_s and shutil.g_t_s in docs so it should be clear which is which. - To keep os simple, os.query_terminal_size() can return a simple, whereas shutil.get_terminal_size() returns a namedtuple We would have two very similar functions returning something different. Also, the amount of code saved will be negligible, because the named tuple is mostly docs. I prefer to keep it in os to keep both functions similar. - test_os.py: use @unittest.skipUnless() on TermsizeTests to check if os.query_terminal_size() is available - To keep os simple, os.query_terminal_size() can return a simple, whereas shutil.get_terminal_size() returns a namedtuple AttributeError should be catched here, not NameError. Or better, check if os has a query_terminal_size() function. Fixed. I changed the tests a bit, e.g. to take into account that stty queries stdin, not stdout. Hum, you may document the default value: (80, 24). Done. shutil.get_terminal_size() is tied to COLUMNS and ROWS and thus makes most sense for stdout. But I guess that an optional parameter could be added: shutil.get_terminal_size(fd=None, fallback=(80, 24)) where fd could be either an integer, or an object with .fileno(). I don't know. - Right now the values are not cached, but this might change. why would it be cached? this sentence can just be removed Done. In theory it could be cached with watching for SIGWINCH, but I'll just remove the comment for now. Thanks for the review and comments! Patch version nine attached: termsize.diff.8 -- Added file: http://bugs.python.org/file24379/termsize.diff.8 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___diff --git a/Doc/library/os.rst b/Doc/library/os.rst --- a/Doc/library/os.rst +++ b/Doc/library/os.rst @@ -1408,6 +1408,44 @@ .. versionadded:: 3.3 +.. _terminal-size: + +Querying the size of the output terminal + + +.. versionadded:: 3.3 + +.. function:: get_terminal_size(fd=STDOUT_FILENO) + + Return the size of the terminal window as ``(columns, lines)``, + tuple of type :class:`terminal_size`. + + The optional argument ``fd`` (default ``STDOUT_FILENO``, or standard + output) specifies which file descriptor should be queried. + + If the file descriptor is not connected to a terminal, an :exc:`OSError` + is thrown. + + This function is only present if an implementation is available for + this system (currently POSIX and Windows). + + :func:`shutil.get_terminal_size` is the high-level function which + should normally be used, ``os.get_terminal_size`` is the low-level + implementation. + +.. class:: terminal_size(tuple) + + A tuple of ``(columns, lines)`` for holding terminal window size. + + .. attribute:: columns + + Width of the terminal window in characters. + + .. attribute:: lines + + Height of the terminal window in characters. + + .. _os-file-dir: Files and Directories diff --git a/Doc/library/shutil.rst b/Doc/library/shutil.rst --- a/Doc/library/shutil.rst +++ b/Doc/library/shutil.rst @@ -450,3 +450,33 @@ -rw-r--r-- tarek/staff 37192 2010-02-06 18:23:10 ./known_hosts +Querying the size of the output terminal + + +.. versionadded:: 3.3 + +.. function:: get_terminal_size(fallback=(columns, lines)) + + Get the size of the terminal window. + + For each of the two dimensions, the environment variable, ``COLUMNS`` + and ``LINES`` respectively, is checked. If the variable is defined and + the value is a positive integer, it is used. + + When ``COLUMNS`` or ``LINES`` is not defined, which is the common case, + the terminal connected to :data:`sys.__stdout__` is queried + by invoking :func:`os.get_terminal_size`. + + If the terminal size cannot be successfully queried, either because + the system doesn't support querying, or because we are not + connected to a terminal, the value given in ``fallback`` parameter + is used. ``fallback`` defaults to ``(80, 24
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: the Python script is executed. Will get_terminal_size() return new value? Please see previous discussion and the docs (and the SUSv2 specs). The env. var. is for overriding. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Here's is an updated version: termsize.diff.6 Following Antoine Pitrou's comment get_terminal_size_raw is renamed back to query_terminal_size. Tests are moved to test_os.py, and there's a new test for query_terminal_size -- the output from 'stty size' is parsed. If something fails (e.g. stty is not available), the test is skipped. I noticed that bash uses $LINES, not $ROWS. I have renamed rows to lines everywhere, to follow existing convention. The big remaining question seems to be one function vs. two functions. I'm still convinced that the high-level two function is better. This issue originated in the argparse module, which can use proper terminal size to efficiently format messages. Of course argparse must use a function with a fallback -- if it cannot query, some default must be used. So argparse would implement the high-level function anyway. It might just as well be in os, available for others to be used. Anyway, the second function is 18 lines of python code (excluding docstring and whitespace) -- a bit too much to copy and paste. -- Added file: http://bugs.python.org/file24369/termsize.diff.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Updated version following comments by Victor Stinner: termsize.diff.7 - os.get_terminal_size() is moved to shutil.get_terminal_size() - some small doc updates Victor STINNER wrote: I noticed that bash uses $LINES, not $ROWS. I have renamed rows to lines everywhere, to follow existing convention. The stty program has rows and columns commands to set the terminal Yes, also struct winsize uses 'rows' and 'cols'. But since we use the variable $LINES, it seems better to use 'lines'. Thanks for the link to SUSv2! I've added a link in the docs, since it adds a nice justification to the COLUMNS/query/fallback behaviour. Now get_terminal_size() lives in shutil. I don't think it matters much, but I see the point of keeping os clean. I also looked at some programs, to see who behaves how. dpkg - COLUMNS first aptitude - ignores COLUMNS git - COLUMNS first systemctl, loginctl, systemd-cgls (systemd cmdline interface) - COLUMNS first less, w - ioctl, COLUMNS as fallback (Of course this is very unscientific, because I just picked some programs at random which I remembered to care about the terminal size). I guess that the case of 'less' is special, because less is very much dependent on the terminal and does quite a lot of manipulations on it. Otherwise, taking COLUMNS as highest priority seems well established, even if not universal. -- Added file: http://bugs.python.org/file24373/termsize.diff.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Zbyszek Szmek zbys...@in.waw.pl added the comment: What about PYTHONHASHSEED= - off, PYTHONHASHSEED=0 - random, PYTHONHASHSEED=n - n ? I agree with Jim that it's better to have one env. variable than two. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Zbyszek Szmek zbys...@in.waw.pl added the comment: The hashing with random seed is only marginally slower or more complicated than current version. The patch is big because it moves random number generator initialization code around. There's no per object tax, and the cost of the random number generator initialization is only significant on windows. Basically, there's no tax. Zbyszek -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
Zbyszek Szmek zbys...@in.waw.pl added the comment: Hi, I think that the documentation is pretty clear ([if topdown=False] ... the directories in dirnames have already been generated by the time dirnames itself is generated). And such behaviour is what one would expect, since it is the result of the simplest implementation (listdir(), yield subdir, yield subdir, yeild subdir, yeild dir). I don't think that the implementation will be changed, since it is pretty to do listdir() yourself if needed, and it would make the function slower for the common use case. Improving the documentation is always possible, what sentence would you see added (what would make the behaviour clearer to you?) ? -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1692335 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
Zbyszek Szmek zbys...@in.waw.pl added the comment: The documentation of this function is generally ambiguous, because os.walk is a generator. Thus generate means (1) yielded from a generator and (2) prepared for later use within the generator. To avoid the ambiguity, generate should be avoided if possible. (1) might be replaced by return and (2) by prepare. It think that you are wrong here: generate is consistently used in meaning (1) in the docstring. Also return means something completely different. generate is better than prepare, because it is more specific, especially from the POV of the user of the function, who only cares about when something is yielded, not when it is prepared. Proposal (very verbose I'm afraid): If you change the directory structure below dirpath while topdown=True, you can modify dirnames in-place so that walk will visit the right directories. If you change the directory structure below dirpath while topdown=False (maybe while you where there), dirnames and filenames can still reflect the old situation and it might be necessary to call os.listdir again. Hm, I think that the difference in behaviour between topdown=False and topdown=True is smaller then this proposal implies. When topdown=True, the list is not updated after changes on disk. So both removing and adding directories does _not_ cause them to added or removed from the list of subdirectories to visit. Nevertheless, the default behaviour on error is to do nothing, so it _looks_ like they were skipped. So I think that the documentation could only clarify that the list of subdirectories is queried first, before the dir or the subdirectories are generated. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13779] os.walk: bottom-up
Zbyszek Szmek zbys...@in.waw.pl added the comment:
os.makedirs('/tmp/a/b/c')
gen = os.walk('/tmp/a')
next(gen)
('/tmp/a', ['b'], [])
os.makedirs('/tmp/a/b2')
next(gen)
('/tmp/a/b', ['c'], [])
next(gen)
('/tmp/a/b/c', [], [])
gen = os.walk('/tmp/a', onerror=print)
next(gen)
('/tmp/a', ['b2', 'b'], [])
os.rmdir('/tmp/a/b2')
next(gen)
[Errno 2] No such file or directory: '/tmp/a/b2'
('/tmp/a/b', ['c'], [])
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13779
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Does this need need more discussion, code review, testing, or just more time? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Zbyszek Szmek zbys...@in.waw.pl added the comment: Added some small comments in http://bugs.python.org/review/13703/show. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
Zbyszek Szmek zbys...@in.waw.pl added the comment:
#11682 will likely be merged. The part of this patch about yielding everything
from an iterator becomes obsolete:
def flatten(iterables):
...for it in iterables:
... yield from it
...
L = [ [0,1,2], (3, 4), {5}, {6: None}, (i for i in range(7, 10)) ]
list(flatten(L))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
The rest is of course still valid and useful.
--
nosy: +zbysz
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- hgrepos: -66 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment: Some minor comments in http://bugs.python.org/review/11682/show. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13703] Hash collision security issue
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Zbyszek Szmek zbys...@in.waw.pl added the comment: What system and version are you running? Linux (debian amd64), Python is compiled from hg (1ea8b7233fd7). The error directly comes from textwrap. In the other hand, textwrap.wrap works with widths down to 1 (on 3.2.2), which suggests that argparse is calling it wrong. Except that it is not on my system. That's really surprising, because it is all pure Python code and don't really see how it _could_ be right: take $COLUMNS, subtract, subtract, and sooner or later _width will go below 0. Could you add 'print(width)' before the call to textwrap return _textwrap.wrap(text, width) to see if -1 is being passed? Prints -1. The code works fine on 3.2.2, Win7, IDLE, narrowest window possible (about 14 chars), which actually wraps to the window width. Oh, I just tried it in IDLE and it prints: 64 64 64 64 usage: ... in a very small window (30 cells wide). So IDLE is just doesn't allow you to go below a certain size. See also #13107. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
Zbyszek Szmek zbys...@in.waw.pl added the comment: I am not setting columns, so that might be the important difference. Yeah, the whole example with IDLE is moot: argparse only checks $COLUMNS and defaults to 80, so if COLUMNS is not set, you are only checking if the code works with 80 columns. Please try my commandline example or set os.environ['COLUMNS'] = 15. I get the exception in IDLE too. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Following comments by Martin and Victor, here is next version: termsize.diff.4 Changes: - just check for defined(MS_WINDOWS) and rely on windows.h. - rename query_terminal_size to get_terminal_size_raw This way it should be clearer that the second one is low-level, and should be less exposed. I don't want to call it _get_terminal_size() because it is not just an implementation detail and would sometimes be called directly. - NotImplementedError is gone. get_terminal_size_raw() is not defined if not possible. Non-changes: - sys.__stdout__.fileno() is not changed to 1, because as Antoine pointed out, it is set at runtime. - STDOUT_FILENO: not defined on windows, so just use 1 and add a comment - fd argument is retained, because we might want to test terminals opened with openpty. - two functions: still there. I think that get_terminal_size() should provide an easy-to-use, even trivial-to-use, way to get a sensible value without writing a wrapper. In the _majority_ of cases the wrapper would be something like get_terminal_size() currently. - named tuple: like Antoine said, it gives nice syntax. - testing for sys/ioctl.h: in termios and other modules, setup.py first tests if we are on unix. But there might be unices without TIOCGWINSZ, and non-unix systems where TIOCGWINSZ _is_ defined, so it seems a functional test is simpler and more robust. Tested on linux and windows XP. -- Added file: http://bugs.python.org/file24150/termsize.diff.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Zbyszek Szmek zbys...@in.waw.pl added the comment: New version to use after #13609 is implemented: patch2.diff -- Added file: http://bugs.python.org/file24152/patch2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: One more comment on $COLUMNS overriding the actual terminal size: Zbyszek, I just looked at [1] and I disagree that the environment variable should have higher precedence. In fact, I believe it should have lower precedence, and should be used as a fallback. To fix issue #9553 test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80, sys.env['COLUMNS']=80 is set during tests. If issue #13041 is fixed and a real terminal size is used, then unless $COLUMNS have higher preference, the tests would break again. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13720] argparse print_help() fails if COLUMNS is set to a low value
New submission from Zbyszek Szmek zbys...@in.waw.pl: % cat test_argparse_narrow.py import argparse argparse.ArgumentParser().print_help() % COLUMNS=15 ./python test_argparse_narrow.py Traceback (most recent call last): File test_argparse_narrow.py, line 2, in module argparse.ArgumentParser().print_help() File /home/zbyszek/python/cpython/Lib/argparse.py, line 2347, in print_help self._print_message(self.format_help(), file) File /home/zbyszek/python/cpython/Lib/argparse.py, line 2321, in format_help return formatter.format_help() File /home/zbyszek/python/cpython/Lib/argparse.py, line 276, in format_help help = self._root_section.format_help() File /home/zbyszek/python/cpython/Lib/argparse.py, line 206, in format_help func(*args) File /home/zbyszek/python/cpython/Lib/argparse.py, line 206, in format_help func(*args) File /home/zbyszek/python/cpython/Lib/argparse.py, line 514, in _format_action help_lines = self._split_lines(help_text, help_width) File /home/zbyszek/python/cpython/Lib/argparse.py, line 615, in _split_lines return _textwrap.wrap(text, width) File /home/zbyszek/python/cpython/Lib/textwrap.py, line 316, in wrap return w.wrap(text) File /home/zbyszek/python/cpython/Lib/textwrap.py, line 291, in wrap return self._wrap_chunks(chunks) File /home/zbyszek/python/cpython/Lib/textwrap.py, line 220, in _wrap_chunks raise ValueError(invalid width %r (must be 0) % self.width) ValueError: invalid width -1 (must be 0) argparse should not fail if the user resizes the window to something very thin... -- components: Library (Lib) files: test_argparse_narrow.py messages: 150733 nosy: zbysz priority: normal severity: normal status: open title: argparse print_help() fails if COLUMNS is set to a low value versions: Python 3.3 Added file: http://bugs.python.org/file24154/test_argparse_narrow.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Some remarks on the Windows implementation in termsize.diff.4: - On Windows, the C runtime always sets fileno(stdout) to 1, so hardcoded values are OK. But on Unix, I'm quite sure that embedded interpreters (mod_python?) sometimes close the standard descriptor, so fd=1 can refer to something entirely different. Does it makes sense to initialize fd=fileno(stdout) (this is C code) instead? OK, I agree that fd=fileno(stdout) is better. Now it matches the docstring which says defaults to stdout better. - When GetStdHandle() returns INVALID_HANDLE_VALUE, PyErr_SetFromWindowsErr(0) should be used. OK. And it's not necessary to use GetLastError(), 0 is enough. OK, good no know. - GetStdHandle will return NULL in a non-console application (try with pythonw.exe or IDLE), I think a specific error message should be raised in this case. OK. I tried and I see that the GetStdHandle documentation says so, but I couldn't get it to return NULL. Nevertheless, I added a check: +if (handle == NULL) +return PyErr_Format(PyExc_OSError, stdout not connected); Thanks for the review! Updated: termsize.diff.5 -- Added file: http://bugs.python.org/file24157/termsize.diff.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment:
- fd argument is retained, because we might want to test terminals
opened with openpty.
You mean a terminal different than the one used for stdin, stdout and
stderr?
For example, let's see what is the size of my two xterms:
os.get_terminal_size_raw()
os.terminal_size(columns=125, rows=39)
fd = os.open('/proc/22736/fd/1', os.O_RDONLY)
fd
6
os.get_terminal_size_raw(6)
os.terminal_size(columns=95, rows=33)
I'm not saying that this serves a clear purpose, but it is possible
and it is good not the restrain the API. I'm sure somebody could find
a use for it.
- two functions: still there. I think that get_terminal_size() should
provide an easy-to-use, even trivial-to-use, way to get a sensible
value without writing a wrapper. In the _majority_ of cases the
wrapper would be something like get_terminal_size() currently.
get_terminal_size() looks like [less?] reliable than raw_get_terminal_size()
because environment variables are not updated when the terminal is
resized.
Please look at my comment above: http://bugs.python.org/issue13609#msg149620
$COLUMNS is only used for overriding -- it normally _isn't_ set.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13609
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: I haven't read much of this issue, but I strongly dislike the use of named tuples. I don't really have a very strong opinion, but (cols, rows) does seem a lot like a tuple -- it really is just a pair of values without other function or state. Still I would much prefer to say get_terminal_size().columns than get_terminal_size()[0] So a bare tuple seems like the worst choice. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Thanks for the reviews! - build the namedtuple in Python rather than in C I started this way, but if two functions are used, it is nicer to have them both return the same type. If it was defined in the Python part, there would be loop in the sense that os would import the function from _posixmodule, and _posixmodule would import the namedtuple from os. The code for the tuple is fairly simple, mostly docs, and saving a few lines just doesn't seem to be worth the complication of doing it other way around. - I don't particularly like CamelCased names for nametuples (I would use size instead of TerminalSize) I was following the style in _posixmodule: there is WaitidResultType and SchedParamType. size seems to generic, maybe something like terminal_size would be better (SchedParamType is exported as sched_param). Will change to terminal_size. - on UNIX, the ioctl() stuff can be done in python rather than in C It can, but it requires extracting the bytes by hand, doing it in C is cleaner. The C implementation is only 5 lines (in addition to the code necessary for windows) and again it seems simpler this way. Also the configuration is kept in one place in the #ifdefs at the top, not in two different files. - use C only on Windows to deal with GetStdHandle/GetConsoleScreenBufferInfo; function name should be accessed as nt._get_terminal_size similarly to what we did for shutil.disk_usage in issue12442. - do not raise NotImplementedError; if the required underlying functions are not available os.get_terminal_size should not exists in the first place (same as we did for shutil.disk_usage / issue12442) I think that there is a difference in importance -- shutil.disk_usage cannot be faked, or ignored, and if it is unavailable, then some work-around must be implemented. OTOH, the terminal size is an embellishment, and if a wrong terminal size is used, the output might wrap around or be a bit narrow (the common case), but like in argparse.FancyFormatter, just continuing is probably reasonable. So to save the users of the function the trouble to wrap it in some try..except, let's cater for the common case. This same argument goes for defining the function only if an implementation is available: argparse would need something like: try: os.get_terminal_size except NameError: def get_terminal_size(): return (80, 25) which just doesn't seem to _gain_ anything. Also, I'm not sure I like fallback=(80, 25) as default, followed by: [...] That means we're never going to get an exception. Instead I would: - provide fallback as None - let OSError propate unless fallback is not None Again, if the user forgets to add the fallback, and only tests in a terminal, she would get an unnecessary surprise when running the thing in a pipe. So the fallback would have to be almost always provided... and it will almost always be (80, 25). So let's just provide it upfront, and let the user call the low-level function if they want full control. --- I think the two function approach works well. :) Since you have already checked that termsize is not NULL, Py_DECREF can be used instead of Py_CLEAR. OK. Would it not be better to use sys.__stdout__ instead of 1 in the documentation and to use STDOUT_FILENO instead of 1 in the code? OK. A brief google suggested that Solaris requires sys/termios.h for TIOCGWINSZ. Perhaps also only define TERMSIZE_USE_IOCTL if TIOCGWINSZ is defined. Hm, I don't have solaris available, so I won't be able to check easily, but maybe sys/termios.h should be imported if TIOCGWINSZ is not available. Would be nice to provide the implementation if possible. Like so: Something like: #if defined(HAVE_SYS_IOCTL_H) #include sys/ioctl.h #if defined(TIOCGWINSZ) #define TERMSIZE_USE_IOCTL #else #if defined(HAVE_SYS_TERMIOS_H) #include sys/termios.h #if defined(TIOCGWINSZ) #define TERMSIZE_USE_IOCTL #else #define TERMSIZE_USE_NOTIMPLEMENTED #endif #elif defined(HAVE_CONIO_H) #include windows.h #include conio.h #define TERMSIZE_USE_CONIO #else #define TERMSIZE_USE_NOTIMPLEMENTED #endif -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Updated patch termsize.diff.3 - s/TerminalSize/terminal_size/ in Python code - change the fallback to (80, 24) (seems to be the commonest default) - s/Py_CLEAR/Py_DECREF/ - use STDOUT_FILENO - add more hrefs in docs - include termios.h is available (untested fix for solaris compatibility) - rename TerminalSize as terminal_size in Python code I tested this iteration only on linux and windows, but it is not substantially changed, so should still work on *bsd. (I previously tested on debian/kfreebsd and dragonflybsd and it seemed functional). -- Added file: http://bugs.python.org/file24127/termsize.diff.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment:
Thanks for the review!
New version is attached. The code is actually slightly shorter, but
there are more docs.
Doc/library/os.rst| 52 +++
Doc/whatsnew/3.3.rst |5 +
Lib/os.py | 43 +++
Lib/test/test_termsize.py | 31 +++
Misc/NEWS |3 +
Modules/posixmodule.c | 125 ++
configure |2
configure.in |2
pyconfig.h.in |3 +
9 files changed, 264 insertions(+), 2 deletions(-)
The patch also lacks some documentation update in Doc/library/os.rst.
Added as a subsection under File Descriptor Operations section.
I also added an entry to Misc/NEWS and Doc/whatsnew/3.3.rst.
Lib/os.py:833: def get_terminal_size(columns=80, rows=25):
The arguments seem ignored in the function body, so I think they should simply
be removed.
The implementation was borked and didn't actually do what the
docstring said. It should be fixed now.
I want to retain the default values, because get_terminal_size()
should do the right thing in case stdout is not a terminal,
without the user needing to wrap it in a try..except block
or some other test. Putting the default values as parameters
makes it clear what will be returned in case query fails, and
makes it easy to override those defaults.
To make it clearer that those are the fallback values, I renamed the
parameter to 'fallback=(c, r)', which should be understandable even
without reading the docstring. Having it as a single parameter might
also make it easier to add something like 'minimum=(c, r)' in the
future.
I wonder if you shouldn't try to explicitly pass sys.stdout.fileno() here, or
perhaps sys.__stdout__.fileno() since the former could be overriden.
OK, changed to sys.__stdout__.fileno().
I think that sys.__stdout__ is better, because when stdout is overridden,
it is usually with something that is not a terminal. Changing the output
terminal is probably pretty rare.
Actually, perhaps get_terminal_size() should have an optional file descriptor
argument.
Querying anything other than stdout should be pretty rare. If
necessary, query_terminal_size() can be called explicitly. Also,
the variables $COLUMNS and $ROWS are usually meant to refer to stdout,
so get_terminal_size() is about stdout and ROWS and COLUMNS, and the
other function allows full control.
Lib/test/test_termsize.py:1: import unittest
This file seems to lack an ``if __name__ == '__main__'`` like other test files
OK.
Besides, why not simply put the tests in test_os.py?
The tests were nicely self-contained. I wanted to be able to do:
./python Lib/test/test_termsize.py
and
./python Lib/test/test_termsize.py | cat
but I guess it can be easily moved to test_os.py if necessary.
Lib/test/test_termsize.py:7: def set_environ(**variables):
There's already EnvironmentVarGuard in test.support.
OK.
Lib/test/test_termsize.py:7: def set_environ(**variables):
There's already EnvironmentVarGuard in test.support.
Lib/test/test_termsize.py:25: self.assertTrue(0 size.columns)
Better to use assertGreater here, failure messages will be more informative.
Lib/test/test_termsize.py:33: self.assertTrue(size.columns == 777)
And better to use assertEqual here.
OK.
Typo here (imlmented).
OK.
Modules/posixmodule.c:10571: return PyErr_Format(PyExc_ValueError)
I don't think there's any point in changing the error here. Just let
a normal OSError be raised.
OK, s/ValueError/OSError/ here and the the windows case below too.
Modules/posixmodule.c:10573: return PyErr_SetFromErrno(PyExc_IOError);
For the record, in 3.3, PyExc_IOError is an alias of PyExc_OSError.
OK, s/IOError/OSError/ for clarity.
Modules/posixmodule.c:10599: return PyErr_Format(PyExc_IOError, error %i,
(int) GetLastError());
Just use PyErr_SetFromWindowsErr(GetLastError()).
OK.
Modules/posixmodule.c:11086: {query_terminal_size, query_terminal_size,
METH_VARARGS, termsize__doc__},
I don't think there's any point in making this helper function public, so I'd
rename it _query_terminal_size or something.
The idea is that query_terminal_size() can be used to do the
low-level query ignoring $COLUMNS and $ROWS and returing the real
error if something goes wrong. If is documented, so I think that
it can be public.
I've also improved the docstrings slightly.
--
Added file: http://bugs.python.org/file24117/termsize.diff.2
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13609
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7719] distutils: ignore .nfsXXXX files
Zbyszek Szmek zbys...@in.waw.pl added the comment:
Review of both patches (python-2.5.1-distutils-aixnfs.patch and
dir_util.py.diff) as they are essentially the same:
I think that the test is in wrong place: we would want to ignore those .nfs*
files always, not just when checking for symlinks. A separate test
at the top of the loop would be better:
for n in names:
+ if n.startswith('.nfs'):
+ continue
src_name = os.path.join(src, n)
dst_name = os.path.join(dst, n)
if preserve_symlinks and os.path.islink(src_name):
BTW: under linux 2.6.20 I see files like: .nfs059241390036, always
of this length, with hexadecimal digits after .nfs).
--
nosy: +zbysz
versions: +Python 3.3 -3rd party, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7719
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Seems to work also on kfreebsd/debian (with eglibc). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
New submission from Zbyszek Szmek zbys...@in.waw.pl:
Extended attribute support was added in issue 12720. Doesn't compile on
kfreebsd/debian, which uses eglibc and gcc. The error is that the symbols
XATTR_LIST_MAX and XATTR_SIZE_MAX are not defined.
After http://hg.python.org/cpython/rev/f325439d7f84 xattr compilation tests for
'defined(HAVE_SYS_XATTR_H) defined(__GLIBC__)', but in this case this test
doesn't work. Anyway, XATTR_SIZE_MAX is defined (on Linux) in linux/limits.h,
and sys/xattr.h doesn't know anything about it.
(When defined XATTR_{SIZE,LIST}_MAX to 65536 like on linux to go through with
the compilation, and os.listxattr('/') returns 'OSError: [Errno 78] Function
not implemented'...)
--
components: Extension Modules
messages: 150289
nosy: Arfrever, benjamin.peterson, pitrou, skrah, zbysz
priority: normal
severity: normal
status: open
title: XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with
eglibc
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13669
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
Zbyszek Szmek zbys...@in.waw.pl added the comment: Unless I'm completely confused, XATTR_SIZE_MAX is defined by linux kernel headers, not the libc. On my linux debian box: $ grep -r XATTR_SIZE_MAX -I /usr include/linux/limits.h:#define XATTR_SIZE_MAX 65536 $ dpkg -l libc6 libc6 2.11.2-10 Embedded GNU C Library: Shared libraries $ dpkg -S /usr/include/linux/limits.h linux-libc-dev: /usr/include/linux/limits.h On debian/kfreebsd grep XATTR_SIZE_MAX doesn't find anything. On fedora 16: $ grep -r XATTR_SIZE_MAX -I /usr /usr/include/linux/limits.h:#define XATTR_SIZE_MAX 65536 $ rpm -qf /usr/include/linux/limits.h kernel-headers-3.1.0-0.rc10.git0.1.fc16.x86_64 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
Zbyszek Szmek zbys...@in.waw.pl added the comment: Forgot to add (on the fedora box): $ rpm -q glibc glibc-2.14.90-13.x86_64 (The GNU libc libraries from http://www.gnu.org/software/glibc/) So the glibc/eglibc split is not important here. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
Zbyszek Szmek zbys...@in.waw.pl added the comment: Yes, it must be, because XATTR_SIZE_MAX is only defined in linux/limits.h. The problem is that with the kfreebsd kernel, /usr/include/sys/limits.h doesn't define or include anything that defines XATTR_SIZE_MAX. Maybe the test should be 'defined(HAVE_SYS_XATTR_H) defined(XATTR_SIZE_MAX)'? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
Zbyszek Szmek zbys...@in.waw.pl added the comment: That's the one. No. I'm putting the complete list below. Actually python2.5-7 and 3.2 is normally packaged by debian for is arch, so it mostly works. $ gcc -dM -E - /dev/null #define __DBL_MIN_EXP__ (-1021) #define __UINT_LEAST16_MAX__ 65535 #define __FLT_MIN__ 1.17549435082228750797e-38F #define __UINT_LEAST8_TYPE__ unsigned char #define __INTMAX_C(c) c ## L #define __CHAR_BIT__ 8 #define __UINT8_MAX__ 255 #define __WINT_MAX__ 4294967295U #define __ORDER_LITTLE_ENDIAN__ 1234 #define __SIZE_MAX__ 18446744073709551615UL #define __WCHAR_MAX__ 2147483647 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1 #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 1 #define __DBL_DENORM_MIN__ ((double)4.94065645841246544177e-324L) #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1 #define __FLT_EVAL_METHOD__ 0 #define __unix__ 1 #define __x86_64 1 #define __UINT_FAST64_MAX__ 18446744073709551615UL #define __SIG_ATOMIC_TYPE__ int #define __DBL_MIN_10_EXP__ (-307) #define __FINITE_MATH_ONLY__ 0 #define __GNUC_PATCHLEVEL__ 2 #define __UINT_FAST8_MAX__ 255 #define __DEC64_MAX_EXP__ 385 #define __INT8_C(c) c #define __UINT_LEAST64_MAX__ 18446744073709551615UL #define __SHRT_MAX__ 32767 #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __UINT_LEAST8_MAX__ 255 #define __UINTMAX_TYPE__ long unsigned int #define __DEC32_EPSILON__ 1E-6DF #define __unix 1 #define __UINT32_MAX__ 4294967295U #define __LDBL_MAX_EXP__ 16384 #define __WINT_MIN__ 0U #define __SCHAR_MAX__ 127 #define __WCHAR_MIN__ (-__WCHAR_MAX__ - 1) #define __INT64_C(c) c ## L #define __DBL_DIG__ 15 #define __SIZEOF_INT__ 4 #define __SIZEOF_POINTER__ 8 #define __USER_LABEL_PREFIX__ #define __GLIBC__ 1 #define __STDC_HOSTED__ 1 #define __LDBL_HAS_INFINITY__ 1 #define __FLT_EPSILON__ 1.1920928955078125e-7F #define __LDBL_MIN__ 3.36210314311209350626e-4932L #define __DEC32_MAX__ 9.99E96DF #define __INT32_MAX__ 2147483647 #define __SIZEOF_LONG__ 8 #define __UINT16_C(c) c #define __DECIMAL_DIG__ 21 #define __LDBL_HAS_QUIET_NAN__ 1 #define __GNUC__ 4 #define __MMX__ 1 #define __FLT_HAS_DENORM__ 1 #define __SIZEOF_LONG_DOUBLE__ 16 #define __BIGGEST_ALIGNMENT__ 16 #define __DBL_MAX__ ((double)1.79769313486231570815e+308L) #define __INT_FAST32_MAX__ 9223372036854775807L #define __DBL_HAS_INFINITY__ 1 #define __DEC32_MIN_EXP__ (-94) #define __INT_FAST16_TYPE__ long int #define __LDBL_HAS_DENORM__ 1 #define __DEC128_MAX__ 9.9E6144DL #define __INT_LEAST32_MAX__ 2147483647 #define __DEC32_MIN__ 1E-95DF #define __DBL_MAX_EXP__ 1024 #define __DEC128_EPSILON__ 1E-33DL #define __SSE2_MATH__ 1 #define __PTRDIFF_MAX__ 9223372036854775807L #define __amd64 1 #define __LONG_LONG_MAX__ 9223372036854775807LL #define __SIZEOF_SIZE_T__ 8 #define __SIZEOF_WINT_T__ 4 #define __GCC_HAVE_DWARF2_CFI_ASM 1 #define __GXX_ABI_VERSION 1002 #define __FLT_MIN_EXP__ (-125) #define __INT_FAST64_TYPE__ long int #define __DBL_MIN__ ((double)2.22507385850720138309e-308L) #define __LP64__ 1 #define __DEC128_MIN__ 1E-6143DL #define __REGISTER_PREFIX__ #define __UINT16_MAX__ 65535 #define __DBL_HAS_DENORM__ 1 #define __UINT8_TYPE__ unsigned char #define __NO_INLINE__ 1 #define __FLT_MANT_DIG__ 24 #define __VERSION__ 4.6.2 #define __UINT64_C(c) c ## UL #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __INT32_C(c) c #define __DEC64_EPSILON__ 1E-15DD #define __ORDER_PDP_ENDIAN__ 3412 #define __DEC128_MIN_EXP__ (-6142) #define __INT_FAST32_TYPE__ long int #define __UINT_LEAST16_TYPE__ short unsigned int #define unix 1 #define __INT16_MAX__ 32767 #define __SIZE_TYPE__ long unsigned int #define __UINT64_MAX__ 18446744073709551615UL #define __INT8_TYPE__ signed char #define __ELF__ 1 #define __FLT_RADIX__ 2 #define __INT_LEAST16_TYPE__ short int #define __LDBL_EPSILON__ 1.08420217248550443401e-19L #define __UINTMAX_C(c) c ## UL #define __SSE_MATH__ 1 #define __k8 1 #define __SIG_ATOMIC_MAX__ 2147483647 #define __SIZEOF_PTRDIFF_T__ 8 #define __x86_64__ 1 #define __DEC32_SUBNORMAL_MIN__ 0.01E-95DF #define __INT_FAST16_MAX__ 9223372036854775807L #define __UINT_FAST32_MAX__ 18446744073709551615UL #define __UINT_LEAST64_TYPE__ long unsigned int #define __FLT_HAS_QUIET_NAN__ 1 #define __FLT_MAX_10_EXP__ 38 #define __LONG_MAX__ 9223372036854775807L #define __DEC128_SUBNORMAL_MIN__ 0.1E-6143DL #define __FLT_HAS_INFINITY__ 1 #define __UINT_FAST16_TYPE__ long unsigned int #define __DEC64_MAX__ 9.999E384DD #define __CHAR16_TYPE__ short unsigned int #define __PRAGMA_REDEFINE_EXTNAME 1 #define __INT_LEAST16_MAX__ 32767 #define __DEC64_MANT_DIG__ 16 #define __INT64_MAX__ 9223372036854775807L #define __UINT_LEAST32_MAX__ 4294967295U #define __INT_LEAST64_TYPE__ long int #define __INT16_TYPE__ short int #define __INT_LEAST8_TYPE__ signed char #define __DEC32_MAX_EXP__ 97 #define __INT_FAST8_MAX__ 127 #define __INTPTR_MAX__ 9223372036854775807L
[issue13669] XATTR_SIZE_MAX and XATTR_LIST_MAX undefined on kfreebsd/debian with eglibc
Zbyszek Szmek zbys...@in.waw.pl added the comment: [Why does roundup remove quoted text being replied to???] On 12/28/2011 06:05 PM, Stefan Krah wrote: http://www.debian.org/ports/kfreebsd-gnu/ That's the one. Is __FreeBSD__ defined on that system? No. I'm putting the complete list below. I'm not sure though if we should start supporting hybrid systems. Actually python2.5-7 and 3.2 is normally packaged by debian for is arch, so it mostly works. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13669 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: The patch is already almost there (in #13041). I'll post an updated version here in a moment. -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: One reply to three comments: [To myself]: I'll post an updated version here in a moment. Hm, it's not so simple. The implementation is simple, but the configure defines are harder than I thought. But I'm getting there :) Zbyszek, I just looked at [1] and I disagree that the environment variable should have higher precedence. In fact, I believe it should have lower precedence, and should be used as a fallback. I disagree. $COLUMNS will usually _not_ be set: $ echo $COLUMNS 119 $ ./python -c 'import os; print(COLUMNS in os.environ)' False As I wrote before, the shell only sets COLUMNS for use in the shell, without exporting. Giving a precedence to the environment variable (if it is set by the user) allows to do something like this: $ COLUMNS=80 python program.py ... do whatever is to be dome for 80 columns ... and the normal case (with dynamic checking) will also work correctly. Anyway, I think that two functions should be provided: a raw one, which does the ioctl, and the normal one, which queries $COLUMNS and the the raw function. If different behaviour is wanted, than just the raw one can be called. Also, the Windows implementation should not rely on ctypes. Of course. For windows I have: #include conio.h ... GetConsoleScreenBufferInfo(handle, csbi) ... This looks like something which would fit better into shutil module rather than os. This is problematic. The docstring for shutil says: Utility functions for copying and archiving files and directory trees. So it doesn't seem to fit at all. OTOH, there's termios and tty, but they are UNIX only. Module curses is also UNIX only, and slightly different topic, because get_terminal_width should be independent of curses. Plus, you should provide also heigth, not only width, possibly as a namedtuple. Agreed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: This is proof-of-concept implementation. This adds two modules: termsize (python) and _termsize (C). The first one contains the get_terminal_size user-facing function and namedtuple definition. The second on contains the function query_terminal_size which does the real job. Two simple tests are added. I'm not sure if it is feasible to test with different terminal sizes: it certainly _could_ be done, e.g. by launching an xterm with a specified geometry, but this would be much more complicated than this implementation, so probably not worth it. This was only tested on 64-bit linux, seems to work. I'm not sure how to the configure tests should be done: right now the presence of sys/ioctl.h is checked, and it is used. If not available, conio.h is checked, and used. Otherwise NotImplementedError is thrown. Would be nice to test on a mac and other systems, but I don't have one available at the moment unfortunately. I think that the python part (termsize.py) should be either merged with os.py (or whatever home we find for this function), or rewritten in C in _termsizemodule.c and only imported into os. But since it hasn't yet been decided where this should go, keeping it separate is easier for now. -- keywords: +patch Added file: http://bugs.python.org/file23981/termsize.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13609] Add os.get_terminal_size() function
Zbyszek Szmek zbys...@in.waw.pl added the comment: Here's updated version: termsize.diff.1 Ok, a couple of general comments: - there is no point having a separate module for a single function; I think the os module (and posixmodule.c for the C side) is a reasonable place where to put this Done. (But posixmodule.c is so enourmous... I feel bad making it even longer.) - C code should be indented with 4 spaces increments and no tabs (see PEP 7) - constants in C code should be uppercase - C code should be C89-compliant and therefore we don't use named struct initializers (such as .m_size = 0) All done, I hope. This version was tested on linux/amd64 and win32 (XP). -- Added file: http://bugs.python.org/file23983/termsize.diff.1 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13609 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment:
f((yield))
This requirement seems unnecessary. And surprising, because
f(generator-expression) or f('a' if 'a' else 'b') doesn't require parenthes.
There's no room for confusion if parentheses were omitted in the
single-argument case. (Following the rule given in documentation for generator
expressions: The parentheses can be omitted on calls with only one argument.).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11682
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment: Updated doc patch 0001-2.diff: following ncoghlan's request, the bulk of yield documentation is kept in expressions.rst, and simple_stmts.rst mostly refers to the other one. (In previous version it was the other way around). After doing this change, I still think that it is better to have most of the documentation in the _statement_ part, and keep the _expression_ part relatively simple. The reason is that yield does more than just return a value, but also throws exceptions, suspends execution, etc. This is detached from the fact that is can be used in an expression. Unfortunately yield as an expression is the only case where a statement can be used in an expression. Therefore there aren't any other cases which could be used as a guide. -- Added file: http://bugs.python.org/file23759/0001-2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23217/0002.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment: Nick Coghlan wrote: I don't want to completely rearrange the yield related sections of the language reference as part of incorporating this PEP. If you're happy to submit a new pull request with a minimalist change just documenting the new features, that would be great, otherwise I'll eventually figure out my own set of updates. OK, I should have it ready before Monday. The cross-linking fixes are independent of this PEP, and should be handled as a separate tracker issue rather than being rolled into the PEP update. Will do so. Zbyszek -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
Zbyszek Szmek zbys...@in.waw.pl added the comment: I see that adding a separate module was proposed in issue #8408, which was rejected/closed. I don't have the rights to reopen, so I'll continue here. #8408 was proposing a new module, which seems a bit overkill, since the implementation for unix and windows is about 20 lines. I'm attaching a second version of the patch which works on windows (tested with python3.2.2 on XP). Thanks to techtonik for pointing to a windows imlementation. -- Added file: http://bugs.python.org/file23241/patch1.1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Zbyszek Szmek zbys...@in.waw.pl added the comment:
On 09/25/2011 01:50 AM, Graylin Kim wrote:
Graylin Kimgraylin@gmail.com added the comment:
I fully support taking blank line based line-wrapping approach and agree with
Zbyszek's suggested indentation approach as well. I am not sure why they
didn't occur to me at the time but they are certainly a more effective and
widely adopted approaches to the structured text problem.
I suppose here is where I should volunteer to update the patch file...
Re: Bike-shedding
dash '-' has special meaning in brackets:
Good catch, I had intended on '-' being a valid list item character. It
clearly needs to be escaped. Not that it would matter given your proposed
alternative.
if(list_match):
Parenthesis unnecessary.
In my defense I have the sadistic pleasure of coding in PHP where they are
necessary for 8 hours a day for my day job. I can only apologize profusely
for my offense and beg for forgiveness :)
:)
lines = list()
Why not just 'lines = []'?
Not to get off topic, but I happen to like list() and dict() instead of []
and {} for empty collections. If there are non-religious reasons for avoiding
this practice I'll consider it. I don't want to invoke a holy war here, just
wondering if there are practical reasons.
In general brevity is good, but I agree that this is just a style
question, and not very important here.
This wasn't my intention, I was only saying that due to this bug the
wrapping uses fixed width, but I'm hoping that #13041 will be
successfully resolved.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12806
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Zbyszek Szmek zbys...@in.waw.pl added the comment:
[I now see that roundup ate half of my reply. I have no idea why,
because the e-mail is formatted correctly. Maybe I'll have more
luck this time, but since there's no preview, I must try to see.]
On 09/25/2011 01:50 AM, Graylin Kim wrote:
if(list_match):
Parenthesis unnecessary.
In my defense I have the sadistic pleasure of coding in PHP where
they are necessary for 8 hours a day for my day job. I can only
apologize profusely for my offense and beg for forgiveness
:)
lines = list()
Why not just 'lines = []'?
Not to get off topic, but I happen to like list() and dict() instead
of [] and {} for empty collections. If there are non-religious
reasons for avoiding this practice I'll consider it. I don't want to
invoke a holy war here, just wondering if there are practical reasons.
In general brevity is good, but I agree that this is just a style question, and
not very important here.
One a side note: due to #13041 the terminal width is normally stuck
at 80 chars.
Not a good reason to remove the flexibility from the implementation
I don't think.
This wasn't my intention, I was only saying that due to this bug the wrapping
uses fixed width, but I'm hoping that #13041 will be successfully resolved.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12806
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12353] argparse cannot handle empty arguments
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12353 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4256] argparse: provide a simple way to get a programmatically useful list of options
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13041] argparse: terminal width is not detected properly
New submission from Zbyszek Szmek zbys...@in.waw.pl: COLUMNS is a shell variable (updated whenever the window size changes), that usually isn't exported to programs. Therefore checking for COLUMNS in sys.environ will not work in the majority of cases. The proper check is to use the TIOCGWINSZ ioctl on stdout. Why COLUMNS is not exported? Because it can change during the lifetime of a program. Therefore it is better to use the dynamic ioctl. -- components: Library (Lib) files: patch1.diff keywords: patch messages: 144507 nosy: zbysz priority: normal severity: normal status: open title: argparse: terminal width is not detected properly type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23238/patch1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13041 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13042] argparse: terminal width is not detected properly
New submission from Zbyszek Szmek zbys...@in.waw.pl: COLUMNS is a shell variable (updated whenever the window size changes), that usually isn't exported to programs. Therefore checking for COLUMNS in sys.environ will not work in the majority of cases. The proper check is to use the TIOCGWINSZ ioctl on stdout. Why COLUMNS is not exported? Because it can change during the lifetime of a program. Therefore it is better to use the dynamic ioctl. -- components: Library (Lib) files: patch1.diff keywords: patch messages: 144508 nosy: zbysz priority: normal severity: normal status: open title: argparse: terminal width is not detected properly type: behavior versions: Python 3.3, Python 3.4 Added file: http://bugs.python.org/file23239/patch1.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12806] argparse: Hybrid help text formatter
Zbyszek Szmek zbys...@in.waw.pl added the comment: This is a great idea! I think that this formatter is much more useful than the default one. I was pretty surprised the first time I added a multi-paragraph epilog to a program and it got all jumbled into a single line. I would vote to make this (or a variant, see the comments below) the default formatter for the description and epilog fields. Notes on the interface (a bit of bike-shedding :)): Continuation backslashes are best avoided. Other means, like parenthesis in case of expressions, are encouraged to avoid adding backslashes. Continuation symbols also interfere with paragraph reflowing in text editors. Using backslash continuations wouldn't be necessary, if the rules were slightly changed to be more LaTeX like: just line-wrap paragraphs, and paragraphs are separated by a blank line. This would make it impossible to have two line-wrapped parts not separated by an empty line, but I think that this is less common and less important than having a natural representation of paragraphs. In current implementation, lines that are not wrapped (IIUC) are those which start with *, +, , anything., or something). This seems error prone. Maybe it would be better to just detect lines which are indented at least one space in comparison to the first line. This would work for examples and lists: this is a text that is subject to line-wrapping and this line not and this line would again be wrapped: - and a line, not merged with the one above or below - and a second point, not merged with the one above Review of argparse_formatter.py: list_match = re.match(r'( *)(([*-+]+|\w+\)|\w+\.) +)',line) A dash '-' has special meaning in brackets: [*-+] means (characters in range from '*' to '+', or ''). Because star and plus are adjacent in ASCII, this is equivalent to [*+] but quite unclear. if(list_match): Parenthesis unnecessary. lines = list() Why not just 'lines = []'? One a side note: due to #13041 the terminal width is normally stuck at 80 chars. -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12806 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13042] argparse: terminal width is not detected properly
Zbyszek Szmek zbys...@in.waw.pl added the comment: Hm, I have somehow submitted the same tex ttwwiiccee. Sorry about that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13023] argparse should allow displaying argument default values in addition to setting a formatter class
Zbyszek Szmek zbys...@in.waw.pl added the comment: Yeah, adding a formatter instance seems overkill for the usual case of wanting to preserver formatting of the epilog. -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13023 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12729 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment: Here are the un-reflowed documentation changes, as a patch this time. I've split the changes in two: 0001 is the real documentation change 0002 is the link fixes [optional]. -- Added file: http://bugs.python.org/file23210/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23210/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Removed file: http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file23216/0001.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Zbyszek Szmek zbys...@in.waw.pl: Added file: http://bugs.python.org/file23217/0002.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Zbyszek Szmek zbys...@in.waw.pl added the comment: I've created some documentation... The patches are the bitbucket repo. Nothing is added to the tutorial, because I think that this isn't material for a newcomer to python. The tutorial doesn't mention generator.throw() and send() either, just talks a little about writing simple generator functions. -- hgrepos: +66 nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10416] UnicodeDecodeError when 2to3 is run on a dir with numpy .npy files
New submission from Zbyszek Szmek zbys...@in.waw.pl: 1. 2to3 should work only only files ending with '.py', but it takes anything which has a dot and ends with 'py'. I'm having trouble with numpy .npy files. 2. 2to3 tries to decode the file and fails with traceback that is not useful: the name of the failing file is not given. A patch is attached. % ls *.npy|head -n1 S_18_7000_899811b572b309161cbb34f185b82fb618ed81da.npy % 2to3-3.2 /usr/local/bin/2to3-3.2 . RefactoringTool: Skipping implicit fixer: buffer RefactoringTool: Skipping implicit fixer: idioms RefactoringTool: Skipping implicit fixer: set_literal RefactoringTool: Skipping implicit fixer: ws_comma Traceback (most recent call last): File /usr/local/bin/2to3-3.2, line 6, in module sys.exit(main(lib2to3.fixes)) File /usr/local/lib/python3.2/lib2to3/main.py, line 172, in main options.processes) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 699, in refactor items, write, doctests_only) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 294, in refactor self.refactor_dir(dir_or_file, write, doctests_only) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 313, in refactor_dir self.refactor_file(fullname, write, doctests_only) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 740, in refactor_file *args, **kwargs) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 335, in refactor_file input, encoding = self._read_python_source(filename) File /usr/local/lib/python3.2/lib2to3/refactor.py, line 331, in _read_python_source return _from_system_newlines(f.read()), encoding File /usr/local/lib/python3.2/codecs.py, line 300, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) UnicodeDecodeError: 'utf8' codec can't decode byte 0x93 in position 0: invalid start byte -- components: 2to3 (2.x to 3.0 conversion tool) files: diff.diff keywords: patch messages: 121188 nosy: zbysz priority: normal severity: normal status: open title: UnicodeDecodeError when 2to3 is run on a dir with numpy .npy files type: crash versions: Python 3.2 Added file: http://bugs.python.org/file19605/diff.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10416 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10407] missing errno import in distutils/dir_util.py
New submission from Zbyszek Szmek zbys...@in.waw.pl: Fix is trivial: diff -r 8daacdacf720 -r 1a821081b470 Lib/distutils/dir_util.py --- a/Lib/distutils/dir_util.py Sat Nov 13 13:27:49 2010 +0100 +++ b/Lib/distutils/dir_util.py Sat Nov 13 14:37:49 2010 +0100 @@ -5,6 +5,7 @@ __revision__ = $Id: dir_util.py 86244 2010-11-06 04:48:05Z eric.araujo $ import os, sys +import errno from distutils.errors import DistutilsFileError, DistutilsInternalError from distutils import log -- assignee: tarek components: Distutils messages: 121137 nosy: eric.araujo, tarek, zbysz priority: normal severity: normal status: open title: missing errno import in distutils/dir_util.py type: crash versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10407 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10224] Build 3.x documentation using python3.x
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10224 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10220] Make generator state easier to introspect
Changes by Zbyszek Szmek zbys...@in.waw.pl: -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10220 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1514420] Missing module code does spurious file search
Zbyszek Szmek zbys...@in.waw.pl added the comment: The bug is certainly not catastrophic, but creates a slight security risk: ln -s /etc/shadow 'stdin' some-suid-program -with-error or whatever. -- nosy: +zbysz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1514420 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5668] file stdin on disk creates garbage output in stack trace
New submission from Zbyszek Szmek zbys...@in.waw.pl: When running interactively, python checks for existence of file stdin when trying to display a stack trace with code input from stdin. # cat stdin asdf asdf asdf # python Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32) [GCC 4.3.1] on linux2 Type help, copyright, credits or license for more information. asdf Traceback (most recent call last): File stdin, line 1, in module asdf asdf asdf NameError: name 'asdf' is not defined # strace -efile python ... open(stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/home13/zbyszek/pm/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib/python25.zip/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/plat-linux2/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/lib-tk/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/lib-dynload/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/site-packages/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/site-packages/Numeric/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/site-packages/PIL/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/site-packages/gtk-2.0/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) open(/usr/lib64/python2.5/site-packages/wx-2.8-gtk2-unicode/stdin, O_RDONLY) = -1 ENOENT (No such file or directory) This is exactly the same in python 2.4, 2.5 and 3.0. I haven't tested other versions. -- components: Interpreter Core messages: 85192 nosy: zbysz severity: normal status: open title: file stdin on disk creates garbage output in stack trace versions: Python 2.4, Python 2.5, Python 3.0 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
