[ python-Bugs-1074011 ] write failure ignored in Py_Finalize()
Bugs item #1074011, was opened at 2004-11-26 23:02
Message generated for change (Comment added) made by meyering
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1074011&group_id=5470
Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: write failure ignored in Py_Finalize()
Initial Comment:
[forwarded from http://bugs.debian.org/283108]
Write errors on stdout may be ignored, and hence may
result in loss of valuable user data.
Here's a quick demo:
$ ./close-bug
foo
$ ./close-bug > /dev/full && echo unreported write failure
unreported write failure
$ cat close-bug
#!/usr/bin/python
import sys
def main ():
try:
print 'foo'
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
This particular failure comes from the following
unchecked fflush
of stdout in pythonrun.c:
static void
call_ll_exitfuncs(void)
{
while (nexitfuncs > 0)
(*exitfuncs[--nexitfuncs])();
fflush(stdout);
fflush(stderr);
}
Flushing the stream manually, python does raise an
exception.
Please note that simply adding a test for fflush
failure is
not sufficient. If you change the above to do this:
if (fflush(stdout) != 0)
{
...handle error...
}
It will appear to solve the problem.
But here is a counterexample:
import sys
def main ():
try:
print "x" * 4095
print
sys.stdout.close ()
except IOError, e:
sys.stderr.write ('write failed: %s\n' % e)
sys.exit (1)
if __name__ == '__main__':
main ()
If you run the above with stdout redirected to /dev/full,
it will silently succeed (exit 0) in spite of a write
failure.
That's what happens on my debian unstable system.
Instead of just checking the fflush return value,
it should also check ferror:
if (fflush(stdout) != 0 || ferror(stdout))
{
...handle error...
}
--
Comment By: Jim Meyering (meyering)
Date: 2005-01-20 09:24
Message:
Logged In: YES
user_id=41497
Hi Martin,
I would have done that, but sys.stdout.close is already
defined *not* to close stdout. Here's the relevant FAQ:
1.4.7 Why doesn't closing sys.stdout (stdin, stderr)
really close it?
http://www.python.org/doc/faq/library.html#id28
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-01-19 22:28
Message:
Logged In: YES
user_id=21627
I don't think the patch is right. If somebody explicitly
invokes sys.stdout.close(), this should have the same effect
as invoking fclose(stdout) in C.
It currently doesn't, but with meyering's patch from
2004-12-02 10:20, it still doesn't, so the patch is incorrect.
It might be better to explicitly invoke fclose() if the file
object has no associated f_close function.
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-19 23:38
Message:
Logged In: YES
user_id=203860
Tim, these bugs are quite difficult to trigger, but they can
hide any kind of file error and lose arbitrarily large
amounts of data.
Here, the following program will run indefinitely:
full = open('/dev/full', 'w')
while 1:
print >>full, 'x' * 1023
print >>full
It seems to be essential that both the character that fills
the file buffer (here it is 1024 bytes long) and the next
are generated implicitly by print - otherwise the write
error will be detected.
--
Comment By: Tim Peters (tim_one)
Date: 2004-12-19 22:24
Message:
Logged In: YES
user_id=31435
Sorry, don't care enough to spend time on it (not a bug I've
had, not one I expect to have, don't care if it never
changes). Suggest not using /dev/full as an output device
.
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2004-12-19 21:47
Message:
Logged In: YES
user_id=80475
Tim, what do you think?
--
Comment By: Ben Hutchings (wom-work)
Date: 2004-12-07 00:33
Message:
Logged In: YES
user_id=203860
OK, I can reproduce the remaining problem if I substitute
1023 for 4095. The culprit seems to be the unchecked fputs()
in PyFile_WriteString, which is used for the spaces and
newlines generated by the print statement but not for the
objects. I think that's a separate bug.
--
Comment By: Jim Meyering (meyering)
Date: 2004-12-06 23:27
Message:
Logged In: YES
user_id=41497
Even w
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 16:04
Message generated for change (Comment added) made by yohell
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
>Comment By: YoHell (yohell)
Date: 2005-01-20 11:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
> clear:
On the countrary, my friend, and here's why:
> """
> ...
> If sep is not specified or is None, a different splitting
> algorithm is applied.
This sentecnce does not say that whitespace will be
implicitly stripped from the edges of the string.
> Words are separated by arbitrary length strings of whitespace
> characters (spaces, tabs, newlines, returns, and formfeeds).
Neither does this one.
> Consecutive whitespace delimiters are treated as a single
delimiter ("'1
> 2 3'.split()" returns "['1', '2', '3']").
And not that one.
> Splitting an empty string returns "['']".
> """
And that last one does not mention it either. In fact, there
is no mention in the docs of how separators on edges of
strings are treated by the split method. And furthermore,
there is no mention of that s.split(sep) treats them
differrently when sep is None than it does otherwise. Example:
>>> ",2,".split(',')
['', '2', '']
>>> " 2 ".split()
['2']
This inconsistent behavior is not in line with how
beautifully thought out the Python language is otherwise,
and how brilliantly everything else is documented on the
http://python.org/doc/ documentation pages.
> This won't change, because mountains of code rely on this
> behavior -- it's probably the single most common use case
> for .split().
I thought as much. However - it's would be Really easy for
an admin to add a line of documentation to .split() to
explain this. That would certainly help make me a happier
man, and hopefully others too.
Cheers guys!
/Joel
--
Comment By: Tim Peters (tim_one)
Date: 2005-01-19 17:56
Message:
Logged In: YES
user_id=31435
I think the docs for split() under "String Methods" are quite
clear:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. Words are separated by arbitrary length
strings of whitespace characters (spaces, tabs, newlines,
returns, and formfeeds). Consecutive whitespace delimiters
are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty string returns "['']".
"""
This won't change, because mountains of code rely on this
behavior -- it's probably the single most common use case
for .split().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105950 ] bug with idle's stdout when executing load_source
Bugs item #1105950, was opened at 2005-01-20 14:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470
Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: imperialfists (imperialfists)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug with idle's stdout when executing load_source
Initial Comment:
There is a bug in idle caused by load_source, which
switches the stdout of idle to something else.
Here is what I did:
Python 2.3.4 (#1, Nov 2 2004, 11:18:38)
[GCC 3.3.4 20040623 (Gentoo Linux 3.3.4-r1,
ssp-3.3.2-2, pie-8.7.6)] on linux2
[...i leave this out...]
IDLE 1.0.3
>>> from sys import stdout
>>> print stdout
>>> print 'a'
a
>>> from imp import load_source
>>> print 'a'
a
>>> print stdout
>>> m = load_source('bug.py', 'bug.py', open('bug.py'))
>>> print 'a'
>>> print stdout
>>>
the file 'bug.py' contains the following line:
from types import *
meanwhile i see this on my terminal:
a
when i type "import bug" or "from bug import *"
everything works fine.
This bug also works (at least for me) if I start idle
from the the "Run Command" dialog under kde, instead of
the terminal.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105950&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105998 ] os.stat int/float oddity
Bugs item #1105998, was opened at 2005-01-20 23:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) Assigned to: Nobody/Anonymous (nobody) Summary: os.stat int/float oddity Initial Comment: Since the last change to posixmodule.c(Revision 2.332) by Martin, test_os.py fails on my Linux box. The reason is that when an os.stat object is accessed through obj.attr or obj[index], they do not always represent the same type. Take, for example, st_atime, st_ctime and st_mtime. With Martin's change, if they're accessed like stat_obj.st_atime, it returns a float value. On the other hand, stat_obj[stat.ST_ATIME] still remains to return an integer value. Here is the result of running test_os.py(abbreviated) :: test_tempnam (__main__.TemporaryFileTests) ... ok test_tmpfile (__main__.TemporaryFileTests) ... ok test_tmpnam (__main__.TemporaryFileTests) ... ok test_stat_attributes (__main__.StatAttributeTests) ... FAIL [snip] == FAIL: test_stat_attributes (__main__.StatAttributeTests) --- --- Traceback (most recent call last): File "./test_os.py", line 115, in test_stat_attributes result[getattr(stat, name)]) AssertionError: 1106224156.927747 != 1106224156 --- --- Ran 23 tests in 0.032s FAILED (failures=1) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 10:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 09:04
Message:
Logged In: YES
user_id=80475
What new wording do you propose to be added?
--
Comment By: YoHell (yohell)
Date: 2005-01-20 05:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
> clear:
On the countrary, my friend, and here's why:
> """
> ...
> If sep is not specified or is None, a different splitting
> algorithm is applied.
This sentecnce does not say that whitespace will be
implicitly stripped from the edges of the string.
> Words are separated by arbitrary length strings of whitespace
> characters (spaces, tabs, newlines, returns, and formfeeds).
Neither does this one.
> Consecutive whitespace delimiters are treated as a single
delimiter ("'1
> 2 3'.split()" returns "['1', '2', '3']").
And not that one.
> Splitting an empty string returns "['']".
> """
And that last one does not mention it either. In fact, there
is no mention in the docs of how separators on edges of
strings are treated by the split method. And furthermore,
there is no mention of that s.split(sep) treats them
differrently when sep is None than it does otherwise. Example:
>>> ",2,".split(',')
['', '2', '']
>>> " 2 ".split()
['2']
This inconsistent behavior is not in line with how
beautifully thought out the Python language is otherwise,
and how brilliantly everything else is documented on the
http://python.org/doc/ documentation pages.
> This won't change, because mountains of code rely on this
> behavior -- it's probably the single most common use case
> for .split().
I thought as much. However - it's would be Really easy for
an admin to add a line of documentation to .split() to
explain this. That would certainly help make me a happier
man, and hopefully others too.
Cheers guys!
/Joel
--
Comment By: Tim Peters (tim_one)
Date: 2005-01-19 11:56
Message:
Logged In: YES
user_id=31435
I think the docs for split() under "String Methods" are quite
clear:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. Words are separated by arbitrary length
strings of whitespace characters (spaces, tabs, newlines,
returns, and formfeeds). Consecutive whitespace delimiters
are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty string returns "['']".
"""
This won't change, because mountains of code rely on this
behavior -- it's probably the single most common use case
for .split().
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.o
[ python-Bugs-1105998 ] os.stat int/float oddity
Bugs item #1105998, was opened at 2005-01-20 23:04 Message generated for change (Settings changed) made by quiver You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: George Yoshida (quiver) >Assigned to: Martin v. Löwis (loewis) Summary: os.stat int/float oddity Initial Comment: Since the last change to posixmodule.c(Revision 2.332) by Martin, test_os.py fails on my Linux box. The reason is that when an os.stat object is accessed through obj.attr or obj[index], they do not always represent the same type. Take, for example, st_atime, st_ctime and st_mtime. With Martin's change, if they're accessed like stat_obj.st_atime, it returns a float value. On the other hand, stat_obj[stat.ST_ATIME] still remains to return an integer value. Here is the result of running test_os.py(abbreviated) :: test_tempnam (__main__.TemporaryFileTests) ... ok test_tmpfile (__main__.TemporaryFileTests) ... ok test_tmpnam (__main__.TemporaryFileTests) ... ok test_stat_attributes (__main__.StatAttributeTests) ... FAIL [snip] == FAIL: test_stat_attributes (__main__.StatAttributeTests) --- --- Traceback (most recent call last): File "./test_os.py", line 115, in test_stat_attributes result[getattr(stat, name)]) AssertionError: 1106224156.927747 != 1106224156 --- --- Ran 23 tests in 0.032s FAILED (failures=1) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105998&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 10:04
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
Comment By: Jim Jewett (jimjjewett)
Date: 2005-01-20 09:28
Message:
Logged In: YES
user_id=764593
Replacing the quoted line:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. First whitespace (spaces, tabs,
newlines, returns, and formfeeds) is stripped from both
ends. Then words are separated by arbitrary length
strings of whitespace characters . Consecutive whitespace
delimiters are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty (or whitespace-
only) string returns "['']".
"""
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 09:04
Message:
Logged In: YES
user_id=80475
What new wording do you propose to be added?
--
Comment By: YoHell (yohell)
Date: 2005-01-20 05:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
> clear:
On the countrary, my friend, and here's why:
> """
> ...
> If sep is not specified or is None, a different splitting
> algorithm is applied.
This sentecnce does not say that whitespace will be
implicitly stripped from the edges of the string.
> Words are separated by arbitrary length strings of whitespace
> characters (spaces, tabs, newlines, returns, and formfeeds).
Neither does this one.
> Consecutive whitespace delimiters are treated as a single
delimiter ("'1
> 2 3'.split()" returns "['1', '2', '3']").
And not that one.
> Splitting an empty string returns "['']".
> """
And that last one does not mention it either. In fact, there
is no mention in the docs of how separators on edges of
strings are treated by the split method. And furthermore,
there is no mention of that s.split(sep) treats them
differrently when sep is None than it does otherwise. Example:
>>> ",2,".split(',')
['', '2', '']
>>> " 2 ".split()
['2']
This inconsistent behavior is not in line with how
beautifully thought out the Python language is otherwise,
and how brilliantly everything else is documented on the
http://python.org/doc/ documentation pages.
> This won't change, because mountains of code rely on this
> behavior -- it's probably the single most common use case
> for .split().
I thought as much. However - it's would be Really easy for
an admin to add a line of documentation to .split() to
explain this. That would certainly help make me a happier
man, and hopefully others too.
Cheers guys!
/Joel
--
Comment By: Tim Peters (tim_one)
Date: 2005-01-19 11:56
Message:
Logged In: YES
user_id=31435
I think the docs for split() under "String Methods" are quite
clear:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. Words are separated by arbitrary length
strings of whitespace cha
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 10:04
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 09:50
Message:
Logged In: YES
user_id=80475
The prosposed wording is fine.
If there are no objections or concerns, I'll apply it soon.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2005-01-20 09:28
Message:
Logged In: YES
user_id=764593
Replacing the quoted line:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. First whitespace (spaces, tabs,
newlines, returns, and formfeeds) is stripped from both
ends. Then words are separated by arbitrary length
strings of whitespace characters . Consecutive whitespace
delimiters are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty (or whitespace-
only) string returns "['']".
"""
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 09:04
Message:
Logged In: YES
user_id=80475
What new wording do you propose to be added?
--
Comment By: YoHell (yohell)
Date: 2005-01-20 05:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
> clear:
On the countrary, my friend, and here's why:
> """
> ...
> If sep is not specified or is None, a different splitting
> algorithm is applied.
This sentecnce does not say that whitespace will be
implicitly stripped from the edges of the string.
> Words are separated by arbitrary length strings of whitespace
> characters (spaces, tabs, newlines, returns, and formfeeds).
Neither does this one.
> Consecutive whitespace delimiters are treated as a single
delimiter ("'1
> 2 3'.split()" returns "['1', '2', '3']").
And not that one.
> Splitting an empty string returns "['']".
> """
And that last one does not mention it either. In fact, there
is no mention in the docs of how separators on edges of
strings are treated by the split method. And furthermore,
there is no mention of that s.split(sep) treats them
differrently when sep is None than it does otherwise. Example:
>>> ",2,".split(',')
['', '2', '']
>>> " 2 ".split()
['2']
This inconsistent behavior is not in line with how
beautifully thought out the Python language is otherwise,
and how brilliantly everything else is documented on the
http://python.org/doc/ documentation pages.
> This won't change, because mountains of code rely on this
> behavior -- it's probably the single most common use case
> for .split().
I thought as much. However - it's would be Really easy for
an admin to add a line of documentation to .split() to
explain this. That would certainly help make me a happier
man, and hopefully others too.
Cheers guys!
/Joel
--
Comment By: Tim Peters (tim_one)
Date: 2005-0
[ python-Feature Requests-1104021 ] wishlist: os.feed_urandom(input)
Feature Requests item #1104021, was opened at 2005-01-17 11:56 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 >Category: Python Library >Group: None Status: Open Resolution: None Priority: 5 Submitted By: Zooko O'Whielacronx (zooko) Assigned to: Nobody/Anonymous (nobody) Summary: wishlist: os.feed_urandom(input) Initial Comment: Both unixy /dev/randoms and Microsoft's CryptGenRandom offer an API for userland to feed entropy into the system's pool. It would be nice if os.urandom() supported this feature. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1104021&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105286 ] Undocumented implicit strip() in split(None) string method
Bugs item #1105286, was opened at 2005-01-19 16:04
Message generated for change (Comment added) made by yohell
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105286&group_id=5470
Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: YoHell (yohell)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Undocumented implicit strip() in split(None) string method
Initial Comment:
Hi!
I noticed that the string method split() first does an
implicit strip() before splitting when it's used with
no arguments or with None as the separator (sep in the
docs). There is no mention of this implicit strip() in
the docs.
Example 1:
s = " word1 word2 "
s.split() then returns ['word1', 'word2'] and not ['',
'word1', 'word2', ''] as one might expect.
WHY IS THIS BAD?
1. Because it's undocumented. See:
http://www.python.org/doc/current/lib/string-methods.html#l2h-197
2. Because it may lead to unexpected behavior in programs.
Example 2:
FASTA sequence headers are one line descriptors of
biological sequences and are on this form:
">" + Identifier + whitespace + free text description.
Let sHeader be a Python string containing a FASTA
header. One could then use the following syntax to
extract the identifier from the header:
sID = sHeader[1:].split(None, 1)[0]
However, this does not work if sHeader contains a
faulty FASTA header where the identifier is missing or
consists of whitespace. In that case sID will contain
the first word of the free text description, which is
not the desired behavior.
WHAT SHOULD BE DONE?
The implicit strip() should be removed, or at least
should programmers be given the option to turn it off.
At the very least it should be documented so that
programmers have a chance of adapting their code to it.
Thank you for an otherwise splendid language!
/Joel Hedlund
Ph.D. Student
IFM Bioinformatics
Linköping University
--
>Comment By: YoHell (yohell)
Date: 2005-01-20 15:59
Message:
Logged In: YES
user_id=1008220
Brilliant, guys!
Thanks again for a superb scripting language, and with
documentation to match!
Take care!
/Joel Hedlund
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 15:50
Message:
Logged In: YES
user_id=80475
The prosposed wording is fine.
If there are no objections or concerns, I'll apply it soon.
--
Comment By: Jim Jewett (jimjjewett)
Date: 2005-01-20 15:28
Message:
Logged In: YES
user_id=764593
Replacing the quoted line:
"""
...
If sep is not specified or is None, a different splitting
algorithm is applied. First whitespace (spaces, tabs,
newlines, returns, and formfeeds) is stripped from both
ends. Then words are separated by arbitrary length
strings of whitespace characters . Consecutive whitespace
delimiters are treated as a single delimiter ("'1 2 3'.split()"
returns "['1', '2', '3']"). Splitting an empty (or whitespace-
only) string returns "['']".
"""
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-01-20 15:04
Message:
Logged In: YES
user_id=80475
What new wording do you propose to be added?
--
Comment By: YoHell (yohell)
Date: 2005-01-20 11:15
Message:
Logged In: YES
user_id=1008220
In RE to tim_one:
> I think the docs for split() under "String Methods" are quite
> clear:
On the countrary, my friend, and here's why:
> """
> ...
> If sep is not specified or is None, a different splitting
> algorithm is applied.
This sentecnce does not say that whitespace will be
implicitly stripped from the edges of the string.
> Words are separated by arbitrary length strings of whitespace
> characters (spaces, tabs, newlines, returns, and formfeeds).
Neither does this one.
> Consecutive whitespace delimiters are treated as a single
delimiter ("'1
> 2 3'.split()" returns "['1', '2', '3']").
And not that one.
> Splitting an empty string returns "['']".
> """
And that last one does not mention it either. In fact, there
is no mention in the docs of how separators on edges of
strings are treated by the split method. And furthermore,
there is no mention of that s.split(sep) treats them
differrently when sep is None than it does otherwise. Example:
>>> ",2,".split(',')
['', '2', '']
>>> " 2 ".split()
['2']
This inconsistent behavior is not in line with how
beautifully thought out the Python language is otherwise,
and how brilliantly everything else is documented on the
http://python.org/doc/ documentation pages.
> This won't change, because mountains of code rely on this
> behavior -- it's probably the single most common use case
> for .split().
I thought as much. However - it's would be Really easy f
[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-20 00:52 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- >Comment By: Michael Hudson (mwh) Date: 2005-01-20 15:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106057 ] README of 2.4 source download says 2.4a3
Bugs item #1106057, was opened at 2005-01-20 16:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Roger Erens (rogererens) Assigned to: Nobody/Anonymous (nobody) Summary: README of 2.4 source download says 2.4a3 Initial Comment: When using the links http://www.python.org/ftp/python/2.4/Python-2.4.tgz or http://www.python.org/ftp/python/2.4/Python-2.4.tar.bz2 I get to see Python2.4-a3 in the README. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106057&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106262 ] semaphore errors from Python 2.3.x on AIX 5.2
Bugs item #1106262, was opened at 2005-01-20 11:55 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: The Written Word (Albert Chin) (tww-china) Assigned to: Nobody/Anonymous (nobody) Summary: semaphore errors from Python 2.3.x on AIX 5.2 Initial Comment: Newer versions of the AIX 5.2 libc implement POSIX semaphores and thus define _POSIX_SEMAPHORES in . However, when building Python 2.3.x (and I'm sure any other version with sem_init()), a few semaphore errors are encountered: building 'pcre' extension ./Modules/ld_so_aix gcc -bI:Modules/python.exp -L/opt/TWWfsw/python232/lib/support -Wl,-brtl -Wl,-blibpath:/opt/TWWfsw/python232/lib/support:/usr/lib build/temp.aix-5.2-2.3/pcremodule.o build/temp.aix-5.2-2.3/pypcre.o -L/opt/TWWfsw/python232/lib -o build/lib.aix-5.2-2.3/pcre.so sem_trywait: Permission denied sem_wait: Permission denied sem_post: Permission denied I ran the Python process under truss and saw that the sem_init() from Python/thread_pthread.h worked successfully. fork() was then called and a sem_trywait() operation (probably from PyThread_acquire_lock()) was called. From the sem_init() man page (http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/libs/basetrf2/sem_init.htm): If the pshared parameter has a nonzero value, the semaphore is shared between processes. In this case, any process that can access the sem parameter can use it for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. Only the sem parameter itself may be used for performing synchronization. If the pshared parameter is zero, the semaphore is shared between threads of the process. Any thread in this process can use the sem parameter for performing sem_wait, sem_trywait, sem_post, and sem_destroy operations. The use of the semaphore by threads other than those created in the same process returns an error. Setting the 2nd value of sem_init to 1 (was 0) solved the problem. However, I don't know if this is wise for security. Another solution is to set HAVE_BROKEN_POSIX_SEMAPHORES for "AIX/5" like for "SunOS/5.8". -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106262&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106316 ] slightly easier way to debug from the exception handler
Bugs item #1106316, was opened at 2005-01-20 20:06 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-19 19:52 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- >Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. -- Comment By: Michael Hudson (mwh) Date: 2005-01-20 10:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1106316 ] slightly easier way to debug from the exception handler
Bugs item #1106316, was opened at 2005-01-20 17:06 Message generated for change (Comment added) made by etrepum You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 Category: Python Library Group: Feature Request Status: Open Resolution: None Priority: 5 Submitted By: Leonardo Rochael Almeida (rochael) Assigned to: Nobody/Anonymous (nobody) Summary: slightly easier way to debug from the exception handler Initial Comment: When interactively developing/debugging a program it'd be nice if we could throw the user into the pdb prompt straight from the exception handler. Currently, pdb.pm() only works outside of the exception handler, after "sys.last_traceback" has already been set, which doesn't happen inside the "except:" clause. The alternative is to use: try: something... except: import sys, pdb pdb.post_mortem(sys.exc_info()[2]) I propose, as a convenience to the programmer, that the first parameter to pdb.post_mortem() be made optional, defaulting to None. In this case, it'd automatically use the value of sys.exc_info()[2] in place of it's otherwise mandatory first parameter. The example above would be reduced to: try: something... except: import pdb;pdb.post_mortem() alternatively, we could make it so that if "sys.last_traceback" is not set "pdb.pm()" would pick up sys.exc_info()[2] instead... -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:51 Message: Logged In: YES user_id=139309 Why put this in pdb.post_mortem() if we can just put it in pdb.pm()? pdb.pm() seems to already be for this purpose (except it currently only works from the interactive interpreter as you mention). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1106316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1105699 ] Warnings in Python.h with gcc 4.0.0
Bugs item #1105699, was opened at 2005-01-19 19:52 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Bob Ippolito (etrepum) Assigned to: Nobody/Anonymous (nobody) Summary: Warnings in Python.h with gcc 4.0.0 Initial Comment: (this happens for every file that includes Python.h) In file included from ../Include/Python.h:55, from ../Objects/intobject.c:4: ../Include/pyport.h:396: warning: 'struct winsize' declared inside parameter list ../Include/pyport.h:397: warning: 'struct winsize' declared inside parameter list The source lines look like this: extern int openpty(int *, int *, char *, struct termios *, struct winsize *); extern int forkpty(int *, char *, struct termios *, struct winsize *); -- >Comment By: Tim Peters (tim_one) Date: 2005-01-20 18:13 Message: Logged In: YES user_id=31435 The warning almost certainly means that there's no declaration of struct winsize in scope when these externs are declared. That's bad, because C doesn't guarantee that all pointers are the same size (although they are on all Python platforms I'm aware of). Some quality time with Google suggested that other projects wormed around this by #include'ing instead of , because the former but not the latter #include's where the winsize struct was defined. Beats me -- ain't a Windows problem . -- Comment By: Bob Ippolito (etrepum) Date: 2005-01-20 17:49 Message: Logged In: YES user_id=139309 Beats me, it's probably just "bad style". It's a problem because it shows up a lot in the output, so we should at least figure out how to disable this warning so that it doesn't become annoying. -- Comment By: Michael Hudson (mwh) Date: 2005-01-20 10:18 Message: Logged In: YES user_id=6656 Why is this a problem? Is it not valid C or something? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1105699&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
