Zbyszek Szmek zbys...@in.waw.pl added the comment:
Done now.
Thanks,
Zbyszek
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14245
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
94 matches
Mail list logo
