[ python-Bugs-1700912 ] questionable results from IDLE, Windows, & several built-in
Bugs item #1700912, was opened at 2007-04-15 03:28 Message generated for change (Comment added) made by bavantgarde314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700912&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.5 >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: bavantgarde314 (bavantgarde314) Assigned to: Nobody/Anonymous (nobody) Summary: questionable results from IDLE, Windows, & several built-in Initial Comment: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Windows(ME) Attachment reveals questionable results from IDLE, Windows, & several built-in functions. Under IDLE: function swapcase() updates 120 characters. Under Windows (dos-screen) or a Windows ide swapcase() updates only 52 characters: ord values 65-90 for (uppercase)A-Z and 97-122 for (lowercase)a-z. Under IDLE: functions lower() & upper() return different results than swapcase() for hex values: 8a, 8c, 8e, 9a, 9c, 9e, 9f, ff or ord values 138, 140, 142, 154, 156, 158, 159, 255 or characters ŠŒŽšœžŸÿ -- >Comment By: bavantgarde314 (bavantgarde314) Date: 2007-04-21 02:33 Message: Logged In: YES user_id=1769863 Originator: YES Thanks import locale locale.setlocale(locale.LC_ALL, '') solved my problems. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-04-19 00:02 Message: Logged In: YES user_id=341410 Originator: NO The behaviors of those functions depend on the locale. Check the results of: import locale locale.getlocale() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1700912 ] questionable results from IDLE, Windows, & several built-in
Bugs item #1700912, was opened at 2007-04-15 03:28 Message generated for change (Comment added) made by bavantgarde314 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700912&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.5 Status: Closed Resolution: None Priority: 5 Private: No Submitted By: bavantgarde314 (bavantgarde314) Assigned to: Nobody/Anonymous (nobody) Summary: questionable results from IDLE, Windows, & several built-in Initial Comment: Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on win32 Windows(ME) Attachment reveals questionable results from IDLE, Windows, & several built-in functions. Under IDLE: function swapcase() updates 120 characters. Under Windows (dos-screen) or a Windows ide swapcase() updates only 52 characters: ord values 65-90 for (uppercase)A-Z and 97-122 for (lowercase)a-z. Under IDLE: functions lower() & upper() return different results than swapcase() for hex values: 8a, 8c, 8e, 9a, 9c, 9e, 9f, ff or ord values 138, 140, 142, 154, 156, 158, 159, 255 or characters ŠŒŽšœžŸÿ -- >Comment By: bavantgarde314 (bavantgarde314) Date: 2007-04-21 02:36 Message: Logged In: YES user_id=1769863 Originator: YES Thanks import locale locale.setlocale(locale.LC_ALL, '') solved my problems. -- Comment By: bavantgarde314 (bavantgarde314) Date: 2007-04-21 02:33 Message: Logged In: YES user_id=1769863 Originator: YES Thanks import locale locale.setlocale(locale.LC_ALL, '') solved my problems. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-04-19 00:02 Message: Logged In: YES user_id=341410 Originator: NO The behaviors of those functions depend on the locale. Check the results of: import locale locale.getlocale() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1700912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704790 ] Exception message when using subprocess.POpen
Bugs item #1704790, was opened at 2007-04-21 06:41 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=1704790&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: Exception message when using subprocess.POpen Initial Comment: module.py: om subprocess import Popen, PIPE pid = Popen(['whoami'],stdout=PIPE,stderr=PIPE) print pid.communicate() main.py: import module Running module.py directly produces the desired result. Running main.py, however, produces the following on Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25), i.e., the version of Python that is included in Ubuntu Feisty Fawn: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'maxint'" in > ignored The same script works in Python 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704790 ] Exception message when using subprocess.Popen
Bugs item #1704790, was opened at 2007-04-21 06:41 Message generated for change (Settings changed) made by rubys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704790&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.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) >Summary: Exception message when using subprocess.Popen Initial Comment: module.py: om subprocess import Popen, PIPE pid = Popen(['whoami'],stdout=PIPE,stderr=PIPE) print pid.communicate() main.py: import module Running module.py directly produces the desired result. Running main.py, however, produces the following on Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25), i.e., the version of Python that is included in Ubuntu Feisty Fawn: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'maxint'" in > ignored The same script works in Python 2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP
Bugs item #1704793, was opened at 2007-04-21 12:52
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=1704793&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: vbr (vlbrom)
Assigned to: M.-A. Lemburg (lemburg)
Summary: incorrect return value of unicodedata.lookup() - beoynd BMP
Initial Comment:
There seem to be an incorrect handling of unicode characters beyond the BMP
(code point higher than 0x) in the unicodedata module - function lookup()
on narrow unicode python builds (python 2.5.1, Windows XPh)
>>> unicodedata.lookup("GOTHIC LETTER FAIHU")
u'\u0346'
(should be u'\U00010346' - the beginning of the literal is truncated - leading
to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING
BRIDGE ABOVE")
on the contrary, the unicode string literals \N{name} work well.
>>> u"\N{GOTHIC LETTER FAIHU}"
u'\U00010346'
Unfortunately, I haven't been able to find the problematic pieces of
sourcecode, so I'm not able to fix it.
It seems, that initially the correct information on the given codepoint is
used, but finally only the last four digits of the codepoint value are taken
into account using the "narrow" unicode literal \u instead of \U
, while the same task is handled correctly by the unicodeescape codec used for
unicode string literals.
vbr
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 10:21
Message generated for change (Comment added) made by gustaebel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
>Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-21 14:25
Message:
Logged In: YES
user_id=642936
Originator: NO
I checked in a simple fix to the release25-maint branch (rev. 54908). I
will come up with a more solid approach for 2.6.
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-21 06:54
Message:
Logged In: YES
user_id=414175
Originator: YES
I see the work around, and I have already implemented similar workarounds
in my code. However, I have 2 problem with this response:
1. The behaviour changed. As the documentation did not explicitly say
tarfile does not support unicode file paths, and it worked prior to 2.5,
then I would say breaking that behaviour at the least calls for a
documentation update.
2. The error message stamps from struct failing to pack a unicode string.
First of all, I did not grasp the subtle message of it being a unicode
string as opposed to a non-unicode string. You see, I actually did not
expect unicode string in the first place, it was a by-product of TEXT_DATA
from a DOM tree. I can understand why struct.pack() throws (because no
explicit encoding scheme was specified) but it was so cryptic with regard
to tarfile itself, that I had to modify tarfile to track down the reason
for the exception.
In short, I would prefer the owner of tarfile to make an explicit support
or not-supported call on unicode file path, document said decision and make
more reasonable attempt in presenting releavant exceptions.
Thank you for looking into this.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 21:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-813986 ] robotparser interactively prompts for username and password
Bugs item #813986, was opened at 2003-09-28 13:06 Message generated for change (Comment added) made by nagle You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&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.3 Status: Open Resolution: None Priority: 6 Private: No Submitted By: Erik Demaine (edemaine) Assigned to: Martin v. Löwis (loewis) Summary: robotparser interactively prompts for username and password Initial Comment: This is a rare occurrence, but if a /robots.txt file is password-protected on an http server, robotparser interactively prompts (via raw_input) for a username and password, because that is urllib's default behavior. One example of such a URL, at least at the time of this writing, is http://www.cosc.canterbury.ac.nz/robots.txt Given that robotparser and robots.txt is all about *robots* (not interactive users), I don't think this interactive behavior is terribly appropriate. Attached is a simple patch to robotparser.py to fix this behavior, forcing urllib to return the 401 error that it ought to. Another issue is whether a 401 (Authorization Required) URL means that everything should be allowed or everything should be disallowed. I'm not sure what's "right". Reading the spec, it says 'This file must be accessible via HTTP on the local URL "/robots.txt"' which I would read to mean it should be accessible without username/password. On the other hand, the current robotparser.py code says "if self.errcode == 401 or self.errcode == 403: self.disallow_all = 1" which has the opposite effect. I'll leave deciding which is most appropriate to the powers that be. -- Comment By: John Nagle (nagle) Date: 2007-04-21 16:53 Message: Logged In: YES user_id=5571 Originator: NO The attached patch was never integrated into the distribution. This is still broken in Python 2.4 (Win32), Python 2.5 (Win32), and Python 2.5 (Linux). This stalled an overnight batch job for us. Very annoying. Reproduce with: import robotparser url = 'http://mueblesmoraleda.com' # whole site is password-protected. parser = robotparser.RobotFileParser() parser.set_url(url) parser.read() # Prompts for password -- Comment By: Wummel (calvin) Date: 2003-09-29 13:24 Message: Logged In: YES user_id=9205 http://www.robotstxt.org/wc/norobots-rfc.html specifies the 401 and 403 return code consequences as restricting the whole site (ie disallow_all = 1). For the password input, the patch looks good to me. On the long term, robotparser.py should switch to urllib2.py anyway, and it should handle Transfer-Encoding: gzip. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=813986&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704793 ] incorrect return value of unicodedata.lookup() - beoynd BMP
Bugs item #1704793, was opened at 2007-04-21 10:52
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&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.5
Status: Open
Resolution: None
>Priority: 6
Private: No
Submitted By: vbr (vlbrom)
Assigned to: M.-A. Lemburg (lemburg)
Summary: incorrect return value of unicodedata.lookup() - beoynd BMP
Initial Comment:
There seem to be an incorrect handling of unicode characters beyond the BMP
(code point higher than 0x) in the unicodedata module - function lookup()
on narrow unicode python builds (python 2.5.1, Windows XPh)
>>> unicodedata.lookup("GOTHIC LETTER FAIHU")
u'\u0346'
(should be u'\U00010346' - the beginning of the literal is truncated - leading
to the ambiguity - in this case u'\u0346' is a combining diacritics "COMBINING
BRIDGE ABOVE")
on the contrary, the unicode string literals \N{name} work well.
>>> u"\N{GOTHIC LETTER FAIHU}"
u'\U00010346'
Unfortunately, I haven't been able to find the problematic pieces of
sourcecode, so I'm not able to fix it.
It seems, that initially the correct information on the given codepoint is
used, but finally only the last four digits of the codepoint value are taken
into account using the "narrow" unicode literal \u instead of \U
, while the same task is handled correctly by the unicodeescape codec used for
unicode string literals.
vbr
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-04-21 20:29
Message:
Logged In: YES
user_id=849994
Originator: NO
Confirmed with an linux-x86 UCS-4 build here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704793&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1704790 ] Exception message when using subprocess.Popen
Bugs item #1704790, was opened at 2007-04-21 10:41 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704790&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.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Sam Ruby (rubys) Assigned to: Nobody/Anonymous (nobody) Summary: Exception message when using subprocess.Popen Initial Comment: module.py: om subprocess import Popen, PIPE pid = Popen(['whoami'],stdout=PIPE,stderr=PIPE) print pid.communicate() main.py: import module Running module.py directly produces the desired result. Running main.py, however, produces the following on Python 2.5.1c1 (release25-maint, Apr 12 2007, 21:00:25), i.e., the version of Python that is included in Ubuntu Feisty Fawn: Exception exceptions.AttributeError: "'NoneType' object has no attribute 'maxint'" in > ignored The same script works in Python 2.4. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-04-21 20:36 Message: Logged In: YES user_id=849994 Originator: NO Reproduced here; fixed in rev. 54918, 54919 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704790&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1703110 ] Incorrect example for add_password()
Bugs item #1703110, was opened at 2007-04-18 09:56
Message generated for change (Comment added) made by nnorwitz
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&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: Documentation
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Bob Kline (bkline)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect example for add_password()
Initial Comment:
In the documentation for urllib2, the example [1] for using basic HTTP
authentication has the following code for the call to add_password():
auth_handler.add_password('realm', 'host', 'username', 'password')
This actually worked in earlier (pre-2.4.3) versions of urllib2, but even in
those older versions, the documentation for HTTPPasswordMgr.add_password()
makes it clear that a URI must be passed as the second argument to the method,
not a host name.
Even though the behavior in the library method has changed (passing a full URI
versions of Python earlier than 2.4.3 didn't work, at least when a non-standard
port was specified), the documentation has not changed (the add_password()
documentation specifies a URI, even in the pre-2.4.3 versions of Python) and
the examples in the documentation for urllib2 still say 'host'.
[1] http://docs.python.org/lib/urllib2-examples.html
--
>Comment By: Neal Norwitz (nnorwitz)
Date: 2007-04-21 16:49
Message:
Logged In: YES
user_id=33168
Originator: NO
Bob, can you submit a patch to correct these problems? Note: we no
longer support the 2.4 series.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1703110&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-451607 ] SSL support in socket module needs tests
Bugs item #451607, was opened at 2001-08-16 13:00 Message generated for change (Comment added) made by facundobatista You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=451607&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: Extension Modules Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Barry A. Warsaw (bwarsaw) Assigned to: Facundo Batista (facundobatista) Summary: SSL support in socket module needs tests Initial Comment: SSL support in the socket module should have a regression test, either in test_socket.py or in a separate test_ssl.py file. -- >Comment By: Facundo Batista (facundobatista) Date: 2007-04-21 23:55 Message: Logged In: YES user_id=752496 Originator: NO I implemented local tests in test_socket_ssl. If present, it starts openssl and then tests against it. All the SSL methods are tested. Feel free to add more complex SSL tests, all infrastructure is now in place. -- Comment By: Facundo Batista (facundobatista) Date: 2007-03-30 21:45 Message: Logged In: YES user_id=752496 Originator: NO I'll try to test the socket to a (when available) local openssl server. -- Comment By: Martin v. Löwis (loewis) Date: 2006-04-12 05:01 Message: Logged In: YES user_id=21627 I don't think I will do anything about this anytime soon, so unassigning myself. -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:51 Message: Logged In: YES user_id=21627 I don't think this is relevant here: OpenSSL uses whatever device it uses; we need not to concern ourselves with OpenSSL's choice. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-10 05:39 Message: Logged In: NO Using /dev/random for a user level application is inappropriate. Use /dev/urandom instead. /dev/random actually tries to suck entropy out of the entropy pool, and blocks if there's not enough. It's best to make sure there's sufficient initial entropy in the pool, then use /dev/urandom which uses the existing entropy to seed a CPRNG. Assuming the CPRNG is properly designed, /dev/urandom should be fine for OpenSSL, since if someone magically breaks the cryptography in the CPRNG then they can probably break OpenSSL's cryptography the same way. --phr -- Comment By: Martin v. Löwis (loewis) Date: 2002-10-10 05:13 Message: Logged In: YES user_id=21627 Things have changed a bit since: Solaris 9 has /dev/random. -- Comment By: Luke Kenneth Casson Leighton (lkcl) Date: 2002-10-09 15:25 Message: Logged In: YES user_id=80200 yes it definitely does because on solaris, which doesn't have a /dev/random, urlretrieve fails to operate because openssl cannot get enough entropy for the PRNG in order to make the SSL connection. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 16:39 Message: Logged In: YES user_id=21627 1) When prngd runs on a TCP socket, it still won't accept connections from remote systems. 2) Sure, but would that simplify testing? 3) My comment was actually directed at bug #232460, which is Solaris specific: Solaris does not have a /dev/[u]random, so prngd is the only choice. I agree that using /dev/random is better if available. Furthermore, OpenSSL will already make this choice for you at installation time. -- Comment By: paul rubin (phr) Date: 2001-10-11 15:44 Message: Logged In: YES user_id=72053 1) I think it's dangerous to run a prngd on an IP socket instead of a Unix domain socket. It creates the possibility of (either accidentally or by ignorance) running OpenSSL on a separate host from the prngd, making the random numbers vulnerable to network sniffing. That's bad--the numbers are cryptographic secrets and should not be exposed. 2) It's simple to set up a local SSL server with the command line openssl s_server option. 3) I'm not crazy about the whole prngd concept. I haven't looked at the CHILL interface yet, but if it's possible to abandon prngd and get random numbers through CHILL, that might be best. On Linux, /dev/urandom should be used. -- Comment By: Martin v. Löwis (loewis) Date: 2001-10-11 15:32 Message: Logged In: YES user_id=21627 On PRNG problems, it seems we have two options:
[ python-Bugs-1704156 ] TarFile.addfile() throws a struct.error
Bugs item #1704156, was opened at 2007-04-20 01:21
Message generated for change (Comment added) made by dvusboy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&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.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: K. C. Wong (dvusboy)
Assigned to: Lars Gustäbel (gustaebel)
Summary: TarFile.addfile() throws a struct.error
Initial Comment:
When adding a file to a TarFile instance using addfile(), if the file paths
(name and arcname) are unicode strings, then a struct.error will the raised.
Python versions prior to 2.5 do not show this behaviour.
Assuming the current directory has a file name 'mac.txt', here is an
interactive session that shows the problem:
Python 2.5 (r25:51908, Apr 18 2007, 19:06:57)
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import tarfile
>>> t=tarfile.open('test.tar', 'w')
>>> i=t.gettarinfo(u'mac.txt', u'mac.txt')
>>> t.addfile(i, file(u'mac.txt', 'r'))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/tarfile.py", line 1422, in addfile
self.fileobj.write(tarinfo.tobuf(self.posix))
File "/usr/lib/python2.5/tarfile.py", line 871, in tobuf
buf = struct.pack("%ds" % BLOCKSIZE, "".join(parts))
File "/usr/lib/python2.5/struct.py", line 63, in pack
return o.pack(*args)
struct.error: argument for 's' must be a string
--
>Comment By: K. C. Wong (dvusboy)
Date: 2007-04-21 21:13
Message:
Logged In: YES
user_id=414175
Originator: YES
Much thanks for your effort.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-21 05:25
Message:
Logged In: YES
user_id=642936
Originator: NO
I checked in a simple fix to the release25-maint branch (rev. 54908). I
will come up with a more solid approach for 2.6.
--
Comment By: K. C. Wong (dvusboy)
Date: 2007-04-20 21:54
Message:
Logged In: YES
user_id=414175
Originator: YES
I see the work around, and I have already implemented similar workarounds
in my code. However, I have 2 problem with this response:
1. The behaviour changed. As the documentation did not explicitly say
tarfile does not support unicode file paths, and it worked prior to 2.5,
then I would say breaking that behaviour at the least calls for a
documentation update.
2. The error message stamps from struct failing to pack a unicode string.
First of all, I did not grasp the subtle message of it being a unicode
string as opposed to a non-unicode string. You see, I actually did not
expect unicode string in the first place, it was a by-product of TEXT_DATA
from a DOM tree. I can understand why struct.pack() throws (because no
explicit encoding scheme was specified) but it was so cryptic with regard
to tarfile itself, that I had to modify tarfile to track down the reason
for the exception.
In short, I would prefer the owner of tarfile to make an explicit support
or not-supported call on unicode file path, document said decision and make
more reasonable attempt in presenting releavant exceptions.
Thank you for looking into this.
--
Comment By: Lars Gustäbel (gustaebel)
Date: 2007-04-20 12:25
Message:
Logged In: YES
user_id=642936
Originator: NO
tarfile.py was never guaranteed to work correctly with unicode filenames.
The fact that this works with Python < 2.5 is purely accidental.
You can work around this (sticking to your example):
i = t.gettarinfo(u'mac.txt', 'mac.txt')
or:
i = t.gettarinfo('mac.txt')
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1704156&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1705170 ] contextmanager eats StopIteration
Bugs item #1705170, was opened at 2007-04-22 00:56 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=1705170&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 Private: No Submitted By: Adam Olsen (rhamphoryncus) Assigned to: Nobody/Anonymous (nobody) Summary: contextmanager eats StopIteration Initial Comment: This is the same bug recently reported by Bob Sidebotham on python-dev (http://mail.python.org/pipermail/python-dev/2007-April/072484.html), but my test-case doesn't involve an overly broad try/except block. It also seems similar to Bug 1462485, which has been closed and marked fixed, but I can reproduce with my test-case using both python 2.5 and python-trunk (revision 54759). The irony is that catching the exception to add debugging forces it to be instantiated, thereby avoiding the bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1705170&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
