[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by splitscreen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: splitscreen (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1451341 ] msgfmt.py: fuzzy messages not correctly found
Bugs item #1451341, was opened at 2006-03-16 15:00
Message generated for change (Comment added) made by splitscreen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hanno Schlichting (hannosch)
Assigned to: Nobody/Anonymous (nobody)
Summary: msgfmt.py: fuzzy messages not correctly found
Initial Comment:
In the msgfmt.py script which is installed in
%PYTHON_HOME%\Tools\i18n (on Windows) on line 129 to
131 it says:
# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy'):
fuzzy = 1
this should be:
# Record a fuzzy mark
if l[:2] == '#,' and l.find('fuzzy') > -1:
fuzzy = 1
or all lines beginning with '#,' will be treated as
fuzzy. Only change is the "> -1".
This applies to all versions of Python. It has been
brought to my attention by Andrey Lebedev who found
this in a product which uses a slightly modified msgfmt.py.
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 15:16
Message:
Logged In: YES
user_id=1126061
Yup, the bug is in trunk.
Although I suggest
# Record a fuzzy mark
if l[:2] == '#,' and 'fuzzy' in l:
as it's more readable (and I got shouted at by Tim the other
day for using s.find() when 'in' would have done).
Matt
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1451341&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462700 ] Errors in PCbuild
Bugs item #1462700, was opened at 2006-04-01 15:22 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=1462700&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) Assigned to: Nobody/Anonymous (nobody) Summary: Errors in PCbuild Initial Comment: pcbuild.sln: pythoncore has a different GUID to pythoncore.vsproj. _ctypes_test needs to be dependent on _ctypes. Diff attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462706 ] urllib2 bails if the localhost doens't have a fqdn hostname
Bugs item #1462706, was opened at 2006-04-01 15:40 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=1462706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bails if the localhost doens't have a fqdn hostname Initial Comment: When running the test suite I ran into a similar problem to bug #1257988. in the FileHandler class's get_names() method should be wrapped in a try, except block because it shouldn't assume that the localhost has a fqdn hostname. Attached is a minimal diff against trunk r43542. Matt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by splitscreen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: splitscreen (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462152 ] Python does not check for POSIX compliant open() modes
Bugs item #1462152, was opened at 2006-03-31 15:02
Message generated for change (Comment added) made by splitscreen
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: splitscreen (splitscreen)
Assigned to: Tim Peters (tim_one)
Summary: Python does not check for POSIX compliant open() modes
Initial Comment:
Python does not check for POSIX-compliant modes when
passing them to open() and fopen().
According to the POSIX standard all modes should start
with either an 'a', 'r' or 'w'.
This patch implements this check in the
check_the_mode() function of fileobject.c and a test
has been modified in the test_file.py test.
--
>Comment By: splitscreen (splitscreen)
Date: 2006-04-01 21:59
Message:
Logged In: YES
user_id=1126061
Ok, uploading latest patch, not quite sure I've hit the mark
here.
Please review.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 20:43
Message:
Logged In: YES
user_id=849994
Yes, I want to remove 'U' from the mode since it's at this
point already recognized by Python, and it's not meaningful
to the underlying C library.
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 19:32
Message:
Logged In: YES
user_id=1126061
Ignore my question, it's for "universal newlines", right?
Have I understood your proposal correctly in that you want
to remove the 'U' from the mode?
--
Comment By: splitscreen (splitscreen)
Date: 2006-04-01 14:14
Message:
Logged In: YES
user_id=1126061
That seems sensible. What does a mode containing 'U' mean
anyway?
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:08
Message:
Logged In: YES
user_id=849994
Instead of this patch, I'd rather like check_the_mode to
* remove any 'U' from the mode string
* if 'U' was found:
* error out if the new string begins with 'w' or 'a'
* add a 'r' and 'b' if it isn't already given
* if not:
* error out if the string doesn't begin with 'w', 'r', 'a'
What do you think of it?
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:03
Message:
Logged In: YES
user_id=31435
There's a small danger of backward-incompatibility here,
since platforms are free to support any goofy mode
characters they like, and Python just passes on whatever the
user typed. I understand that some MS compilers in debug
mode raise internal exceptions, but that's an MS bug and the
workaround is dead easy ("don't do that").
All that said, I'm in favor of this patch ;-). However, if
it goes in two things are needed:
1. The error message should be more informative, like
PyErr_Format(PyExc_ValueError, "mode argument must "
"begin with 'w', 'r', or 'a', not '%.200s'", mode);
2. The Python docs should change to match (i.e., the
manual should document this new restriction on mode
strings).
WRT the test case, it's more natural to write, e.g.,
TESTFN in s
than
s.find(TESTFN) != -1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462152&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462700 ] Errors in PCbuild
Bugs item #1462700, was opened at 2006-04-01 15:22 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: Tim Delaney (tcdelaney) >Assigned to: Martin v. Löwis (loewis) Summary: Errors in PCbuild Initial Comment: pcbuild.sln: pythoncore has a different GUID to pythoncore.vsproj. _ctypes_test needs to be dependent on _ctypes. Diff attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462700&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462706 ] urllib2 bails if the localhost doens't have a fqdn hostname
Bugs item #1462706, was opened at 2006-04-01 16:40 Message generated for change (Comment added) made by jjlee You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: splitscreen (splitscreen) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2 bails if the localhost doens't have a fqdn hostname Initial Comment: When running the test suite I ran into a similar problem to bug #1257988. in the FileHandler class's get_names() method should be wrapped in a try, except block because it shouldn't assume that the localhost has a fqdn hostname. Attached is a minimal diff against trunk r43542. Matt -- Comment By: John J Lee (jjlee) Date: 2006-04-01 23:35 Message: Logged In: YES user_id=261020 This fixes the test failure and is safe. I don't know if a more sophisticated patch is possible, but if nobody comes up with one, I think this should be applied (as happened with #1257988). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462706&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win
Bugs item #1462352, was opened at 2006-03-31 14:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl won't work together with socket.settimeout on Win
Initial Comment:
Symptoms:
>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
socket.sslerror: (2, 'The operation did not complete
(read)')
This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-01 20:57
Message:
Logged In: YES
user_id=31435
gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at
http://pastebin.com/633224
made no difference to the outcome on Windows.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 20:36
Message:
Logged In: YES
user_id=31435
Because the
s.connect(("gmail.org", 995))
line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:23
Message:
Logged In: YES
user_id=31435
Note that this is a problem in 2.4 and trunk.
The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.
Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the
s.connect(("gmail.org", 995))
line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing). At the
moment, that's timing out on my Windows box too. We clearly
need a more reliable net address to connect to.
On Bug Day IRC, "arekm" last asked that I try this patch on
Windows:
http://pastebin.com/633224
Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps. Nothing else did ;-)
On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462352 ] socket.ssl won't work together with socket.settimeout on Win
Bugs item #1462352, was opened at 2006-03-31 14:11
Message generated for change (Comment added) made by tim_one
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Georg Brandl (gbrandl)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.ssl won't work together with socket.settimeout on Win
Initial Comment:
Symptoms:
>>> import socket
>>> s = socket.socket()
>>> s.settimeout(30.0)
>>> s.connect(("gmail.org", 995))
>>> ss = socket.ssl(s)
Traceback (most recent call last):
File "", line 1, in ?
File "C:\python24\lib\socket.py", line 74, in ssl
return _realssl(sock, keyfile, certfile)
socket.sslerror: (2, 'The operation did not complete
(read)')
This does not occur on Unix, where
test_socket_ssl.test_timeout runs smoothly.
--
>Comment By: Tim Peters (tim_one)
Date: 2006-04-01 21:08
Message:
Logged In: YES
user_id=31435
BTW, does anyone understand why this part of my first
comment was true?:
"""
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
"""
How did s->sock_timeout become 0? s.settimeout(30.0) was
called, and the same s was passed to socket.ssl(). I don't
understand this at all:
>>> s.connect(("gmail.org", 995))
>>> s.gettimeout()
30.0
>>> s._sock
>>> s._sock.gettimeout()
30.0
>>> ss = socket.ssl(s)
but a breakpoint in newPySSLObject() right there shows that
Sock->sock_timeout is 0.0. HTF did that happen?
If I poke 30.0 (under the debugger) into Sock->sock_timeout
at the start of newPySSLObject(), the constructor finishes
unexceptionally.
--
Comment By: Tim Peters (tim_one)
Date: 2006-04-01 20:57
Message:
Logged In: YES
user_id=31435
gmail.com happened to respond when I tried it today, so I
can confirm (alas) that the patch at
http://pastebin.com/633224
made no difference to the outcome on Windows.
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 20:36
Message:
Logged In: YES
user_id=31435
Because the
s.connect(("gmail.org", 995))
line started timing out on all (non-Windows) buildbot slaves
some hours ago, causing all test runs to fail, I disabled
test_timeout on all boxes for now (on trunk & on 2.4 branch).
--
Comment By: Tim Peters (tim_one)
Date: 2006-03-31 18:23
Message:
Logged In: YES
user_id=31435
Note that this is a problem in 2.4 and trunk.
The sample code worked fine earlier today if (and only if) I
left out the .settimeout() call.
Note that buildbot test runs are failing in trunk and 2.4
branch now on non-Windows boxes, because the
s.connect(("gmail.org", 995))
line is timing out (the new test is disabled on Windows, and
that's why the Windows buildbots are still passing). At the
moment, that's timing out on my Windows box too. We clearly
need a more reliable net address to connect to.
On Bug Day IRC, "arekm" last asked that I try this patch on
Windows:
http://pastebin.com/633224
Unfortunately, I haven't been able to get beyond the
s.connect(("gmail.org", 995)) line since then, so still
don't know whether that helps. Nothing else did ;-)
On Windows, in newPySSLObject(),
"ret = SSL_connect(self->ssl);" returns -1
"err = SSL_get_error(self->ssl, ret);" returns 2
"if (err == SSL_ERROR_WANT_READ)" triggers.
check_socket_and_wait_for_timeout() takes the "else if
(s->sock_timeout == 0.0)" path and and returns
SOCKET_IS_NONBLOCKING.
newPySSLObject() breaks out of its loop then, and does
"PySSL_SetError(self, ret); goto fail;"
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462352&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1462485 ] StopIteration raised in body of 'with' statement suppressed
Bugs item #1462485, was opened at 2006-04-01 00:17
Message generated for change (Comment added) made by tcdelaney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 7
Submitted By: Tim Delaney (tcdelaney)
Assigned to: Nick Coghlan (ncoghlan)
Summary: StopIteration raised in body of 'with' statement suppressed
Initial Comment:
Given:
@contextmanager
def gen():
print '__enter__'
try:
yield
finally:
print '__exit__'
with gen():
raise StopIteration('body')
running the above results in:
__enter__
__exit__
I would have expected instead
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise StopIteration('body')
StopIteration: body
Note that doing:
with gen():
raise GeneratorExit('body')
does the expected thing:
__enter__
__exit__
Traceback (most recent call last):
File "test25.py", line 53, in
raise GeneratorExit('body')
GeneratorExit: body
--
>Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-02 02:42
Message:
Logged In: YES
user_id=603121
Attached diffs to test_with.py which adds tests for raising StopIteration (and
GeneratorExit) from the body of a with-statement where the context manager is
either a generator, or a class instance.
I think the correct behaviour is to return False from
GeneratorContextManager.__exit__ if the thrown exception is a StopIteration,
and the exact same instance is raised from self.gen.throw(). Diffs for this
also attached.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-04-01 07:02
Message:
Logged In: YES
user_id=849994
Nick, I can't tell whether this is intentional without
rereading the specs. Can you?
--
Comment By: Tim Delaney (tcdelaney)
Date: 2006-04-01 00:19
Message:
Logged In: YES
user_id=603121
Attached code and results.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1462485&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1427552 ] tarfile.open bug / corrupt data
Bugs item #1427552, was opened at 02/08/06 06:13
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
Resolution: None
Priority: 7
Submitted By: Chris86 (chris86)
Assigned to: Nobody/Anonymous (nobody)
Summary: tarfile.open bug / corrupt data
Initial Comment:
Hi!
I want to create a bz2 compressed tar file.
Here is my code:
full="/home/test/test.sql"
tar = tarfile.open("test.tar.bz2", "w:bz2")
tarinfo = tar.gettarinfo(full,"blubb.sql")
tar.addfile(tarinfo,file(full))
tar.close()
i think this should work, but the sql file is corrupt:
- the created sql file in the compressed tar has only
4745 Lines, the original file has 4753
Regards,
Chris
--
>Comment By: SourceForge Robot (sf-robot)
Date: 04/01/06 19:23
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 02/11/06 22:21
Message:
Logged In: YES
user_id=33168
Chris can you attach your sql file (or a small test case) so
we can reproduce the problem?
--
Comment By: Lars Gustäbel (gustaebel)
Date: 02/08/06 07:13
Message:
Logged In: YES
user_id=642936
Just to identify whether this is a tarfile or bz2 module
related issue:
- Do you have the same problem without compression or with
gzip compression?
- Have you tried compressing your sql file directly with the
bz2 module?
--
Comment By: Chris86 (chris86)
Date: 02/08/06 06:17
Message:
Logged In: YES
user_id=1133569
same error with Python 2.3.5 (#2, Aug 30 2005, 15:50:26)
[GCC 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)] on linux2
--
Comment By: Chris86 (chris86)
Date: 02/08/06 06:15
Message:
Logged In: YES
user_id=1133569
I'm using Python 2.4.2 (#2, Nov 20 2005, 17:04:48)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on linux2
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1427552&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
