Zbyszek Szmek 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
Changes by Zbyszek Szmek :
Added file:
http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Removed file:
http://bugs.python.org/file23210/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Removed file:
http://bugs.python.org/file23211/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Added file:
http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Added file:
http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Removed file:
http://bugs.python.org/file23212/0001-Document-the-yield-from-syntax-and-StopIteration-ret.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Removed file:
http://bugs.python.org/file23213/0002-Fix-references-to-__next__-__iter__-and-nearby-refer.patch
___
Python tracker
<http://bugs.python.org/issue11
Changes by Zbyszek Szmek :
Added file: http://bugs.python.org/file23216/0001.diff
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list mailin
Changes by Zbyszek Szmek :
Added file: http://bugs.python.org/file23217/0002.diff
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list mailin
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue12729>
___
___
Python-bugs-list mailing list
Unsubscribe:
Zbyszek Szmek 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
<http://bugs.python.org/issue13
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue12353>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue4256>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Zbyszek Szmek :
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 s
New submission from Zbyszek Szmek :
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 s
Zbyszek Szmek 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
Zbyszek Szmek added the comment:
Hm, I have somehow submitted the same tex ttwwiiccee. Sorry about that.
--
___
Python tracker
<http://bugs.python.org/issue13
Zbyszek Szmek 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 a
Zbyszek Szmek added the comment:
On 09/25/2011 01:50 AM, Graylin Kim wrote:
>
> Graylin Kim 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
>
Zbyszek Szmek 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:
>>&
Changes by Zbyszek Szmek :
Removed file: http://bugs.python.org/file23217/0002.diff
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list mailin
Zbyszek Szmek 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
>
Zbyszek Szmek 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
Zbyszek Szmek added the comment:
>>> f((yield))
This requirement seems unnecessary. And surprising, because
f() or f('a' if 'a' else 'b') doesn't require parenthes.
There's no room for confusion if parentheses were omitted in the
s
Zbyszek Szmek 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
<http://bugs.python.org/is
Zbyszek Szmek 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 j
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek added the comment:
Seems to work also on kfreebsd/debian (with eglibc).
--
___
Python tracker
<http://bugs.python.org/issue13609>
___
___
Python-bug
New submission from Zbyszek Szmek :
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
Zbyszek Szmek 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 Emb
Zbyszek Szmek 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
Zbyszek Szmek 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 &#x
Zbyszek Szmek 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__
Zbyszek Szmek 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.
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek 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 is available (untested fix for
Zbyszek Szmek 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
Zbyszek Szmek 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 .
- rename query_terminal_size to get_terminal_size_raw
This way it should be clearer that the second one is low-level
Zbyszek Szmek added the comment:
New version to use after #13609 is implemented: patch2.diff
--
Added file: http://bugs.python.org/file24152/patch2.diff
___
Python tracker
<http://bugs.python.org/issue13
Zbyszek Szmek 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
New submission from Zbyszek Szmek :
% 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
argparse.ArgumentParser().
Zbyszek Szmek 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?)
> sometime
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek 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
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue13703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Zbyszek Szmek 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},
Changes by Zbyszek Szmek :
--
hgrepos: -66
___
Python tracker
<http://bugs.python.org/issue11682>
___
___
Python-bugs-list mailing list
Unsubscribe:
Zbyszek Szmek added the comment:
Some minor comments in http://bugs.python.org/review/11682/show.
--
___
Python tracker
<http://bugs.python.org/issue11
Zbyszek Szmek 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
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue10224>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue10220>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Zbyszek Szmek :
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
New submission from Zbyszek Szmek :
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 u
Zbyszek Szmek added the comment:
Added some small comments in http://bugs.python.org/review/13703/show.
--
___
Python tracker
<http://bugs.python.org/issue13
Zbyszek Szmek 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
res
Changes by Zbyszek Szmek :
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org/issue1692335>
___
___
Python-bugs-list mailing list
Unsubscribe:
Zbyszek Szmek 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, "gen
Zbyszek Szmek 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',
Zbyszek Szmek added the comment:
Does this need need more discussion, code review, testing, or just more time?
--
___
Python tracker
<http://bugs.python.org/issue13
Zbyszek Szmek 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
n
Zbyszek Szmek 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
<http://bugs.pyth
Zbyszek Szmek 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
Zbyszek Szmek 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
&g
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek 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
<http://bugs.python.org/is
Zbyszek Szmek 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
<http://bu
Zbyszek Szmek 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 semant
Zbyszek Szmek 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 eas
Zbyszek Szmek 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 tr
Zbyszek Szmek 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
Zbyszek Szmek 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 $COL
Changes by Zbyszek Szmek :
Removed file: http://bugs.python.org/file23241/patch1.1.diff
___
Python tracker
<http://bugs.python.org/issue13041>
___
___
Python-bugs-list m
Changes by Zbyszek Szmek :
Removed file: http://bugs.python.org/file23238/patch1.diff
___
Python tracker
<http://bugs.python.org/issue13041>
___
___
Python-bugs-list m
Changes by Zbyszek Szmek :
Removed file: http://bugs.python.org/file24152/patch2.diff
___
Python tracker
<http://bugs.python.org/issue13041>
___
___
Python-bugs-list m
Zbyszek Szmek 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
<http://bugs.python.org/issu
Zbyszek Szmek 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.").
--
k
Zbyszek Szmek added the comment:
zsh completion is much more powerful. E.g. for gitlog I see:
completing head
completing commit object name
completing cached file
abspath.c git-lost-found.sh README
aclocal.m4 git-merge
New submission from Zbyszek Szmek :
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
Zbyszek Szmek 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 i
New submission from Zbyszek Szmek :
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
Zbyszek Szmek added the comment:
On 03/10/2012 12:26 PM, Mark Dickinson wrote:
>
> Mark Dickinson 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 mentio
Zbyszek Szmek 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
Zbyszek Szmek 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
Zbyszek Szmek 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 e
Zbyszek Szmek added the comment:
Both appear to be commonly used. Both sound OK to me.
--
___
Python tracker
<http://bugs.python.org/issue14245>
___
___
Pytho
Zbyszek Szmek added the comment:
Done now.
Thanks,
Zbyszek
--
___
Python tracker
<http://bugs.python.org/issue14245>
___
___
Python-bugs-list mailing list
Unsub
New submission from Zbyszek Szmek :
When running interactively, python checks for existence of file
"" when trying to display a stack trace with code input from stdin.
# cat >> ""
asdf asdf asdf
# python
Python 2.5.2 (r252:60911, Jun 25 2008, 17:58:32)
[GCC 4
Zbyszek Szmek added the comment:
The bug is certainly not catastrophic, but creates
a slight security risk:
ln -s /etc/shadow ''
some-suid-program -with-error
or whatever.
--
nosy: +zbysz
___
Python tracker
<http://bugs.python.org
94 matches
Mail list logo
