[ python-Bugs-1621367 ] random import works?
Bugs item #1621367, was opened at 2006-12-23 11:04 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: [EMAIL PROTECTED] Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1257255 ] tarfile local name is local, should be abspath
Bugs item #1257255, was opened at 2005-08-12 04:26 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&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: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Martin Blais (blais) Assigned to: Lars Gustäbel (gustaebel) Summary: tarfile local name is local, should be abspath Initial Comment: I ran into a bug using the tarfile module with compression from a directory that did not exist anymore, and this exhibits a bug in the tarfile module. I'm not completely sure how to fix it with certainty, so instead of filing a quick patch, I submit a bug so people familiar with the module can have a look first. The problem is that when you open a tarfile with gz or bz2 compression, the TarFile object is opened with a filename that is not absolute, just local (basename is called) but the actual file is using a file-like object. Now, when you add a new entry, there is a check in the TarFile.add method that checks if we're not adding the archive itself into the tarfile, and this method calls abspath. Calling abspath on the name that has been basename'd is incorrect and a bug. It happens not to fail nor cause any problems when called from an existing directory (the test returns false), but it does not do the job it is supposed to. When the CWD has been deleted, calling abspath fails with an OSError, which brings out the problem. Some code to reproduce the bug is provided in an attachment. -- >Comment By: Lars Gustäbel (gustaebel) Date: 2006-12-23 19:17 Message: Logged In: YES user_id=642936 Originator: NO Fixed. See patch #1262036. -- Comment By: Georg Brandl (birkenfeld) Date: 2005-08-25 11:04 Message: Logged In: YES user_id=1188172 The patch has been reversed, so reopening. -- Comment By: Martin v. Löwis (loewis) Date: 2005-08-24 08:08 Message: Logged In: YES user_id=21627 This was fixed with said patch. -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-08-17 14:34 Message: Logged In: YES user_id=642936 Thank you very much for your report. I added patch #1262036 that ought to fix the problem. -- Comment By: Martin Blais (blais) Date: 2005-08-15 19:34 Message: Logged In: YES user_id=10996 Oops, that was silly. My apologies. Here goes the file... -- Comment By: Lars Gustäbel (gustaebel) Date: 2005-08-15 13:39 Message: Logged In: YES user_id=642936 Could you please attach the test code you mentioned? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257255&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1621367 ] random import works?
Bugs item #1621367, was opened at 2006-12-23 17:04 Message generated for change (Comment added) made by dallison You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Msword (msword) Assigned to: Nobody/Anonymous (nobody) Summary: random import works? Initial Comment: I'm just starting working with python, and it seems that random.choice() isn't all that random. After running the program(attached) a few times, each and every time it selects 1 < 2 < 3 < 4 < 5 and I can expect this to happen, meaning it isn't all that random. Email: [EMAIL PROTECTED] Thanks -- Comment By: Dennis Allison (dallison) Date: 2006-12-23 18:32 Message: Logged In: YES user_id=31903 Originator: NO I believe the problem is with your test framework and not with random.choice(). The library function random.choice( seq ) selects, using a uniform distribution, one item from the sequence at each call. By the law of large numbers, if you have K items in the sequence, each should be returned K/N times, on average, after N calls. You should expect deviations even for fairly large N. If you want to test the randomess, use a chi-square test to test against the hypothes of uniform random selection with replacement. Of course there are many other statistical properties which ought to be checked, for example, the distribution of runs. Consider the program: import random dist = [0,0,0,0,0] for i in range(10): j = random.choice([0,1,2,3,4]) dist[j] += 1 print dist which prints the distribution observed for each choice. With 10 tries you'd expect each one to appear (on average) 2 time. Running it on my a three times gives: [19839, 19871, 19996, 20035, 20259] [20043, 19870, 20025, 20109, 19953] [19947, 20033, 19970, 20111, 19939] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1621367&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1371937 ] minidom namespace problems
Bugs item #1371937, was opened at 2005-12-02 19:47 Message generated for change (Comment added) made by paulpach You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&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 Private: No Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: minidom namespace problems Initial Comment: Noted on c.l.py: the minidom writexml() function doesn't tidy up namespace declarations, so you can output documents that have incorrect namespace declarations. DOM Level 3, appendix B, specifies an algorithm for normalizing namespaces; see http://www.w3.org/TR/DOM-Level-3-Core/namespaces-algorithms.html . minidom probably needs to acquire the normalizeNamespace method, and then writexml() can call it before doing its work. -- Comment By: Paul Pacheco (paulpach) Date: 2006-12-23 20:04 Message: Logged In: YES user_id=794762 Originator: NO I implemented this and uploaded a patch and test case here: http://sourceforge.net/tracker/index.php?func=detail&aid=1621421&group_id=5470&atid=305470 enjoy :) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1371937&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1612113 ] Dictionary ordering docs are too unclear of dangers
Bugs item #1612113, was opened at 2006-12-09 03:57 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&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: None >Status: Closed Resolution: Works For Me Priority: 5 Private: No Submitted By: Calvin Spealman (ironfroggy) Assigned to: Nobody/Anonymous (nobody) Summary: Dictionary ordering docs are too unclear of dangers Initial Comment: The footnote #3 on this page of the documentation details some thoughts on the order of dictionaries and the results of the different key and value retreival methods. I think it promises more than it should. The current content tells the reader they can expect consistant results from a dictionary as far as order goes, and we know this to be simply untrue and even in the circumstances where its likely (but still not impossible), such as `zip(d.values(), d.keys())` there is not even any compelling reason to use such odd methods, making the very fact that the idea is documented suspect. I recommend the footnote be removed entirely, or replaced with "Keys and values are listed in an arbitrary order which is non-random, varies across Python implementations, and depends on the dictionary's history of insertions and deletions. Do not expect anything of the order of the items(), keys(), values(), iteritems(), iterkeys(), and itervalues() methods' results." Page in question: http://docs.python.org/lib/typesmapping.html -- >Comment By: SourceForge Robot (sf-robot) Date: 2006-12-23 19:20 Message: Logged In: YES user_id=1312539 Originator: NO 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: Tim Peters (tim_one) Date: 2006-12-09 06:51 Message: Logged In: YES user_id=31435 Originator: NO The statement that the various ways of extracting info from a dict are consistent /provided that/ they're "called with no intervening modifications to the dictionary" (did you miss that crucial qualification?) is part of the language definition: it definitely and deliberately constrains the set of possible implementations. The docs didn't originally say this, but people noted it was true in then-current CPython, and asked whether they could rely on it. At that point, Guido decided to elevate this property of the CPython implementation to a language requirement, and the footnote was added. Of course you're not /required/ to rely on it ;-). -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-09 06:31 Message: Logged In: YES user_id=21627 Originator: NO You seem to be saying (without actually saying it) that the footnote is untrue. Can you give an example that demonstrates it is untrue? I believe the footnote is correct, precise, and complete as it stands, and fail to see a bug here. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1612113&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
