[ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port
Bugs item #1378679, was opened at 2005-12-12 17:50 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=1378679&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1290333 ] cjkcodec compile error under AIX 5.2 on symbol 100_encode
Bugs item #1290333, was opened at 2005-09-14 02:55
Message generated for change (Comment added) made by perky
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&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: Build
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Deron Meranda (dmeranda)
Assigned to: Hye-Shik Chang (perky)
Summary: cjkcodec compile error under AIX 5.2 on symbol 100_encode
Initial Comment:
Trying to compile Python 2.4.1 under AIX 5.2 with the
native cc compiler. When compiling the module
cjkcodecs the compiler will fail with these errors on
the source file Modules/cjkcodecs/_codecs_cn.c
building '_codecs_cn' extension
cc -DNDEBUG -O -I.
-I/home/psgtools/aix52/build/Python-2.4.1/./Include
-I/opt/cmax/psgtools/include
-I/home/psgtools/aix52/build/Python-2.4.1/Include
-I/home/psgtools/aix52/build/Python-2.4.1 -c
/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c
-o build/temp.aix-5.2-2.4/_codecs_cn.o
"/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c",
line 431.3: 1506-206 (S) Suffix of integer constant
100_encode is not valid.
"/home/psgtools/aix52/build/Python-2.4.1/Modules/cjkcodecs/_codecs_cn.c",
line 431.3: 1506-196 (W) Initialization between types
"int(*)(union {...}*,const void*,const unsigned
long**,unsigned long,unsigned char**,unsigned
long,int)" and "int" is not allowed.
and so on.
This is happening because of the "hz" codec. Due to
the way the source file uses the C preprocessor macro,
and the fact that the preprocessor symbol "hz" is
predefined as 100 on this platform, it is producing
invalid lecical symbols such as "100_encode".
The simple solution is to insert the following line in
the source file immediately before the first reference
to the name "hz":
#undef hz
--
>Comment By: Hye-Shik Chang (perky)
Date: 2005-12-12 20:53
Message:
Logged In: YES
user_id=55188
Fixed in r41647. Thank you!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1290333&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378679 ] urllib2.HTTPBasicAuthHandler fails on non-default port
Bugs item #1378679, was opened at 2005-12-12 17:50 Message generated for change (Comment added) made by gusarov You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&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: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Mikhail Gusarov (gusarov) Assigned to: Nobody/Anonymous (nobody) Summary: urllib2.HTTPBasicAuthHandler fails on non-default port Initial Comment: HTTPBasicAuthHandler (or, more precise, AbstractBasicAuthHandler) does not work when non- default port is in use: passwords added to it just not being passed back in answer to the 401 error code. Default port works fine. I tracked the problem with it to the HTTPPasswordMgr. find_user_password: it accepts 'authuri' and reduce it using reduce_uri(). AbstractBasicAuthHandler passes as 'authuri' parameter just hostname, in form 'myhost:myport' and this cause reduce_uri() to parse it as URI with schema 'myhost' and netloc 'myport', which is obviously wrong. Passing to the reduce_uri() hostname in form 'myhost' works fine. I placed the the program demonstrating the bug to the attach: it throws HTTPError in my case. Of course change the host, port, user and password to the reflecting your setup. given should be protected by the basic authentication. -- >Comment By: Mikhail Gusarov (gusarov) Date: 2005-12-12 18:10 Message: Logged In: YES user_id=501458 Problem was fixed by changing user, pw = self.passwd.find_user_password(realm, host) to the user, pw = self.passwd.find_user_password(realm, req. get_full_url()) in the problem function -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378679&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char.
Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&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: Unicode Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. -- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the Python internal Unicode encoding (unicode_internal) ? This is an encoding that is only used Python internally and should not be used for anything else. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailm
[ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char.
Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by lemburg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&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: Unicode Group: Python 2.4 >Status: Closed Resolution: None Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt -- >Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-12 14:39 Message: Logged In: YES user_id=38388 Closing this bug report as "won't fix" (even though SF seems to have removed this option from the tracker, or at least I don't see it in Firefox). Removing "unicode_internal" from the docs is not an option: this is a valid encoding, albeit one that depends on the way Python is built. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. -- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() should complain. If it is valid, it should perform consistently, IMHO. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-09 23:04 Message: Logged In: YES user_id=38388 Why would you want to read a file using the P
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 15:24
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=1378755&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 15:24
Message generated for change (Comment added) made by dpinte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
>Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 15:25
Message:
Logged In: YES
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 15:24
Message generated for change (Settings changed) made by dpinte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&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: Python 2.4
Status: Open
>Resolution: Works For Me
Priority: 5
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 15:25
Message:
Logged In: YES
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378755 ] logging : fileConfig does not check existance of the file
Bugs item #1378755, was opened at 2005-12-12 15:24
Message generated for change (Comment added) made by dpinte
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&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: Python 2.4
Status: Open
Resolution: Works For Me
Priority: 5
Submitted By: Didrik Pinte (dpinte)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging : fileConfig does not check existance of the file
Initial Comment:
Hi,
The fileConfig method from the logging.config module
does not check for the existance of the config file
before trying to load it.
Worst, if the file does not exist, the exception is
totally unrelated to the file.
Example :
[EMAIL PROTECTED]:~/$ python
Python 2.3.5 (#2, Nov 20 2005, 16:40:39)
[GCC 4.0.3 2005 (prerelease) (Debian 4.0.2-4)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> from logging import config
>>> config.fileConfig('')
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.3/logging/config.py", line 68,
in fileConfig
flist = cp.get("formatters", "keys")
File "/usr/lib/python2.3/ConfigParser.py", line 505,
in get
raise NoSectionError(section)
ConfigParser.NoSectionError: No section: 'formatters'
It is really important that the exception is correctly
reported.
In fact, the problem seems to be here :
/usr/lib/python2.3/ConfigParser.py, line 258
for filename in filenames:
try:
fp = open(filename)
except IOError:
continue
self._read(fp, filename)
The documentation of the read method says "Files that
cannot be opened are silently ignored;".
The behaviour of logging.config.fileConfig is highly
related to the user actions. He must be informed of the
fact that the logging system have not opened its file.
I will provide a very basic path :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.file(fname)):
raise IOError('Provided filename is not existing')
-
Didrik
--
>Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 15:27
Message:
Logged In: YES
user_id=970259
Oups, the patch should be the following :
File /usr/lib/python2.3/logging/config.py, line 61
-
import os
if not (os.path.isfile(fname)):
raise IOError('Provided filename is not existing')
--
Comment By: Didrik Pinte (dpinte)
Date: 2005-12-12 15:25
Message:
Logged In: YES
user_id=970259
i've reported it for Python 2.4 but I reproduced it on
Python 2.3.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378755&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1378022 ] source utf8
Bugs item #1378022, was opened at 2005-12-11 07:48 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&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: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: zhao (ibear) Assigned to: Nobody/Anonymous (nobody) Summary: source utf8 Initial Comment: winxp sp2(chinese or japanese) and python 2.42 i have created a utf8 source file with BOM_UTF8 if i add a '#coding: utf8' at first line and run it, the python interpreter will crash -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 15:35 Message: Logged In: YES user_id=89016 The following patch (pythonrun.diff) should fix the segfault. However UTF-8 files with a leading BOM currently aren't supported. There's a pending patch (http://bugs.python.org/1177307) that adds a utf-8-sig codec for that. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1378022&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1377394 ] read() / readline() blow up if file has even number of char.
Bugs item #1377394, was opened at 2005-12-09 22:43 Message generated for change (Comment added) made by doerwalter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1377394&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: Unicode Group: Python 2.4 Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: superwesman (superwesman) Assigned to: M.-A. Lemburg (lemburg) Summary: read() / readline() blow up if file has even number of char. Initial Comment: Hello, I am having a problem with the read() and readline() functions. I'm using codecs.open() to open a text file, then using either read() or readline() to get its contents. In python 2.4.2, if the file has an even number of characters, I get a UnicodeDecodeError. If python 2.4.1 this works regardless of the character count. I've pasted below a sample script and the sample text file I was running. This is the command I executed at the Windows 2000 CMD prompt: python sample.py sample.txt Again, in 2.4.1, this works fine - in 2.4.2 it breaks when the file-to-be-read has an odd number of characters. Thanks. -w # start: sample.py import codecs import sys print "open the file" in_file = codecs.open( sys.argv[1], "r", "unicode_internal" ) print "read the file" the_file = in_file.read() print "close the file" in_file.close() print "done" # end: sample.py # start: sample.txt RESULTHOST=vivaldi RESULTPORT=a DB_XML=/test/art/jfw/config/DBList.xml LOGCHECK_IGNORE=art_actions.txt # end: sample.txt -- >Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 15:39 Message: Logged In: YES user_id=89016 Strange, Firefox seems to have some layout problems. The "Resolution" box has moved way to the right. -- Comment By: M.-A. Lemburg (lemburg) Date: 2005-12-12 14:39 Message: Logged In: YES user_id=38388 Closing this bug report as "won't fix" (even though SF seems to have removed this option from the tracker, or at least I don't see it in Firefox). Removing "unicode_internal" from the docs is not an option: this is a valid encoding, albeit one that depends on the way Python is built. -- Comment By: Walter Dörwald (doerwalter) Date: 2005-12-12 14:30 Message: Logged In: YES user_id=89016 With the Python 2.4.2 I get the following output both on Linux and Windows: open the file read the file close the file done This is totally independent of the type of line feeds in sample.txt or the length of the file (even or odd). > If it is a valid option (that should only be used > "Python internally" - not sure what that means) > then it should perform consistently regardless > of the number of characters in the file, should it not? unicode_internal just dumps the data bytes of the Unicode object. This means that (depending on the way Python is compiled) the length of a unicode_internal encoded byte string will always be a multiple of 2 or 4. So a byte string that has on odd number of bytes clearly is broken and decoding would have the right to complain about that. In 2.4.2 it doesn't, because it's not clear to the StreamReader API if there's more data available on subsequent calls to read() (and the last odd byte is silently dropped). BTW, the data read by your script is probably not what you might have expected. On a UCS-2 build the result is: u'\u2023\u7473\u7261\u3a74\u7320\u6d61\u6c70\u2e65\u7874\u0a74\u4552\u5553\u544c\u4f48\u5453\u763d\u7669\u6c61\u6964\u520a\u5345\u4c55\u5054\u524f\u3d54\u0a61\u4244\u585f\u4c4d\u2f3d\u6574\u7473\u612f\u7472\u6a2f\u7766\u632f\u6e6f\u6966\u2f67\u4244\u694c\u7473\u782e\u6c6d\u4c0a\u474f\u4843\u4345\u5f4b\u4749\u4f4e\u4552\u613d\u7472\u615f\u7463\u6f69\u736e\u742e\u7478' (or something similar depending on your line feeds). -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-12-10 11:57 Message: Logged In: YES user_id=1188172 I'd suggest unicode_internal to be removed from the docs. -- Comment By: superwesman (superwesman) Date: 2005-12-10 00:17 Message: Logged In: YES user_id=1401447 I didn't realize that 'unicode_internal' was not a legitimate value to pass into this function. If 'unicode_internal' is not a valid 3rd parameter to codecs.open(), shouldn't that function complain? If it is a valid option (that should only be used "Python internally" - not sure what that means) then it should perform consistently regardless of the number of characters in the file, should it not? Seems to me that pilot-error uncovered a bug. If this is not a valid choice, then codecs.open() shoul
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 17:03
Message generated for change (Comment added) made by ken668
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
>Comment By: ken668 (ken668)
Date: 2005-12-12 08:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 07:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 12:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1376775 ] Memory leak in the email package
Bugs item #1376775, was opened at 2005-12-08 20:03
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: ken668 (ken668)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Memory leak in the email package
Initial Comment:
memory leak in email.message_from_string. This is what
I did to create a leak.
You used the attached file, memleak.eml.
f = open("memleak.eml")
buffer = f.read()
f.close()
# now buffer has the email string
msg = email.message_from_string(buffer)
msg = None # this should free the memory but it doesn't
# The memory that is used in msg is not completely free
--
Comment By: ken668 (ken668)
Date: 2005-12-12 11:00
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 10:59
Message:
Logged In: YES
user_id=1400763
My mistake. I had also called gc.get_objects() too. It was
gc.get_objects() that outputed the content of the email
message. It was not gc.garbage. Sorry about that.
--
Comment By: ken668 (ken668)
Date: 2005-12-12 10:53
Message:
Logged In: YES
user_id=1400763
I added these three lines after the line "msg=None"
import gc
print "gc.collect()\n\n", gc.collect()
print "gc.garbage\n\n", gc.garbage
If you pipe the output of gc.garbage to a file, you will see
the email message you just sent are still be in the memory.
Everytime I call email.message_from_string, a copy of the
message will be kept in the memory even after I set the
returned value to None.
I tried the same thing with email package email-2.5.tar.gz,
that memory was freed right after I set the variable "msg"
to None.
Thanks
Ken
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-11 15:13
Message:
Logged In: YES
user_id=33168
What causes you to believe this is a memory leak? I ran
this under valgrind and it doesn't report any leaks.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1376775&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379209 ] socket.recv(OOB) raises exception on closed socket
Bugs item #1379209, was opened at 2005-12-12 22:14
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=1379209&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: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.recv(OOB) raises exception on closed socket
Initial Comment:
frame:pyClient$ python
Python 2.4.1 (#1, Aug 16 2005, 20:11:22)
[GCC 3.4.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
frame:pyClient$ uname -a
SunOS frame 5.8 Generic_108528-27 sun4u sparc
If you try to read out-of-band data on a closed socket, the recv() call
raises socket.error, signaling "invalid argument". This seems wrong.
Doing a normal (in-band) recv() on a closed socket returns an empty
string; trying to read OOB data should do the same thing.
At worst, it should raise a more specific error. I'm guessing this
exception is reflecting an errno of EBADF. A more specific error would
at least make it clear that it's the first argument to recv() which was
bad, not the second.
frame:pyClient$ cat oob.py
#!/usr/bin/env python
import socket
s = socket.socket()
s.connect (("localhost", 13)) # 13 = daytime
print "==> ", `s.recv(1024)`
print "OOB: ", `s.recv (1024, socket.MSG_OOB)`
frame:pyClient$ ./oob.py
==> 'Mon Dec 12 22:00:29 2005\n\r'
OOB:
Traceback (most recent call last):
File "./oob.py", line 8, in ?
print "OOB: ", `s.recv (1024, socket.MSG_OOB)`
socket.error: (22, 'Invalid argument')
frame:pyClient$
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379209&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
