[issue13489] collections.Counter doc does not list added version
Shawn Ligocki added the comment: It doesn't seem like the styling is the issue, but the placement. You say that the standard style is to put this at the end of the section, is there somewhere it would be appropriate to bring this up for discussion? I think it would be much more intuitive if it was always placed right after the section name. -- keywords: +patch Added file: http://bugs.python.org/file23811/collections.diff ___ Python tracker <http://bugs.python.org/issue13489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13489] collections.Counter doc does not list added version
Shawn Ligocki added the comment: Ah, I see, it seems like that would be better suited directly after the section title, don't you? -- ___ Python tracker <http://bugs.python.org/issue13489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13489] collections.Counter doc does not list added version
New submission from Shawn Ligocki : collections.Counter doc does not list added version: http://docs.python.org/library/collections.html It appears to only have been added in 2.7 (while the rest of the doc says it is valid since 2.4) -- assignee: docs@python components: Documentation messages: 148443 nosy: docs@python, sligocki priority: normal severity: normal status: open title: collections.Counter doc does not list added version versions: Python 2.6, Python 2.7 ___ Python tracker <http://bugs.python.org/issue13489> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10860] Handle empty port after port delimiter in httplib
Shawn Ligocki added the comment: Great! Glad it landed :) -- ___ Python tracker <http://bugs.python.org/issue10860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10860] Handle empty port after port delimiter in httplib
Shawn Ligocki added the comment: Here's a patch for 2.7 (from the hg checkout http://code.python.org/hg/branches/release2.7-maint/) How does it look? Apparently there was already a testcase for "www.python.org:" failing! -- keywords: +patch Added file: http://bugs.python.org/file20308/issue.10860.patch ___ Python tracker <http://bugs.python.org/issue10860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10861] urllib2 sporadically falsely claims infinite redirect
Shawn Ligocki added the comment: Ahha, what a mess, thanks for investigating! I agree, this is bankofamerica's problem. -- ___ Python tracker <http://bugs.python.org/issue10861> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10860] Handle empty port after port delimiter in httplib
Shawn Ligocki added the comment: Sure, I can work on a patch. Should an empty port default to 80? In other words does "http://foo.com/"; == "http://foo.com:/";? -- ___ Python tracker <http://bugs.python.org/issue10860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10861] urllib2 sporadically falsely claims infinite redirect
New submission from Shawn Ligocki :
urllib2 sporadically falsely claims that http://www.bankofamerica.com/ has
infinite redirect:
$ python -c 'import urllib2; print
urllib2.urlopen("http://www.bankofamerica.com/";).geturl()'
https://www.bankofamerica.com/
$ python -c 'import urllib2; print
urllib2.urlopen("http://www.bankofamerica.com/";).geturl()'
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 595, in http_error_302
self.inf_msg + msg, headers, fp)
urllib2.HTTPError: HTTP Error 302: The HTTP server returned a redirect error
that would lead to an infinite loop.
The last 30x error message was:
Found
Since it is sporadic, it could just be a problem with bankofamerica.com's
servers. Is there an easy way to see what response urllib2 got that made it
unhappy?
--
components: Library (Lib)
messages: 125693
nosy: sligocki
priority: normal
severity: normal
status: open
title: urllib2 sporadically falsely claims infinite redirect
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue10861>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10860] urllib2 crashes on valid URL
New submission from Shawn Ligocki :
urllib2 crashes with stack trace on legal URL http://118114.cn
Transcript:
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> urllib2.urlopen("http://118114.cn";)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.6/urllib2.py", line 126, in urlopen
return _opener.open(url, data, timeout)
File "/usr/lib/python2.6/urllib2.py", line 397, in open
response = meth(req, response)
File "/usr/lib/python2.6/urllib2.py", line 510, in http_response
'http', request, response, code, msg, hdrs)
File "/usr/lib/python2.6/urllib2.py", line 429, in error
result = self._call_chain(*args)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 605, in http_error_302
return self.parent.open(new, timeout=req.timeout)
File "/usr/lib/python2.6/urllib2.py", line 391, in open
response = self._open(req, data)
File "/usr/lib/python2.6/urllib2.py", line 409, in _open
'_open', req)
File "/usr/lib/python2.6/urllib2.py", line 369, in _call_chain
result = func(*args)
File "/usr/lib/python2.6/urllib2.py", line 1161, in http_open
return self.do_open(httplib.HTTPConnection, req)
File "/usr/lib/python2.6/urllib2.py", line 1107, in do_open
h = http_class(host, timeout=req.timeout) # will parse host:port
File "/usr/lib/python2.6/httplib.py", line 657, in __init__
self._set_hostport(host, port)
File "/usr/lib/python2.6/httplib.py", line 682, in _set_hostport
raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
httplib.InvalidURL: nonnumeric port: ''
>>>
I think the problem is that "http://118114.cn"; says it redirects to
"http://www.118114.cn:";, but it seems like urllib2 should be able to deal with
that or at least report back a more useful error message.
$ nc 118114.cn 80
GET / HTTP/1.1
Host: 118114.cn
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13)
Gecko/20101206 Ubuntu/10.04 (lucid) Firefox/3.6.13
HTTP/1.1 301 Moved Permanently
Server: nginx/0.7.64
Date: Fri, 07 Jan 2011 19:06:32 GMT
Content-Type: text/html
Content-Length: 185
Connection: keep-alive
Keep-Alive: timeout=60
Location: http://www.118114.cn:
301 Moved Permanently
301 Moved Permanently
nginx/0.7.64
--
components: Library (Lib)
messages: 125687
nosy: sligocki
priority: normal
severity: normal
status: open
title: urllib2 crashes on valid URL
type: crash
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue10860>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: ping Please look at the last patch. It's very simple and would be helpful. This is not very complicated and shouldn't take months to consider. -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: There is a whole paragraph about WichmanHill at the top of this page already and (if anything) I think that WichmanHill is less notable (basically only used in legacy applications). However SystemRandom is very useful. I don't want to make claims about urandom that I can't back up, but urandom is very useful and I think that there ought to be some note of it in the opening for people who want a stronger random instance. All I'm suggesting is a sentence to point it out. That would have been enough for me not to have reinvented the wheel. -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: How about this, sweet and simple. -- Added file: http://bugs.python.org/file15252/random.patch ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: So, all I really want to do is call attention to SystemRandom from the top of the page, because it is easily not noticed at the bottom. Do you guys have any suggestions for how to do that that doesn't repeat too much and doesn't claim things that you aren't comfortable with claiming? -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: I rewrote the description, mostly using the claims form urandom, so that we don't claim something new. What do you guys think? -- Added file: http://bugs.python.org/file15251/random.patch ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: A major pro for pseudo-random number generators is that they are deterministic, that is, you can save a load the state, start from the same seed and reproduce results, etc. At least in science (and probably other areas) this reproducibility can be vital in a random class. It really depends on your application though. In my use, I was originally using normal random to produce seeds for another programs random number generator. This ended up producing many identical results and thus not producing an appropriate random sampling. Rather than trying to figure out a proper way to do this with a PRNG I decided to just use a completely random source, urandom was close enough for my needs. I believe that is its strongest value, not having the strange artifacts that PRNGs have. But I'm not completely sure how true that claim is :) -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: Ah, sorry for the misunderstanding. I agree, better not to mislead. Perhaps we should side with the urandom documentation and say that it is a cryptographically secure random number generator with no accessible state? -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
Shawn Ligocki added the comment: Oh, urandom is almost always non-deterministic. It mixes completely random bits from hardware sources with its pseudo-random number state. The more random bits it gets from hardware, the less predictable its output is. However, as long as it's getting any random bits, it's output is not deterministic (because it's based on some random information). But perhaps there is better wording that conveys the power of the urandom source? -- ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7076] Documentation add note about SystemRandom
New submission from Shawn Ligocki : I did not notice the existence of random.SystemRandom until after I had implemented my own version. I thought it would be nice to mention it in the opening section. I've added a tiny note about random.SystemRandom. What do you guys think, feel free to reword it, I just think that it should be mentioned. http://docs.python.org/library/random.html -- assignee: georg.brandl components: Documentation files: random.patch keywords: patch messages: 93678 nosy: georg.brandl, sligocki severity: normal status: open title: Documentation add note about SystemRandom type: feature request versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file15065/random.patch ___ Python tracker <http://bugs.python.org/issue7076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1727780] 64/32-bit issue when unpickling random.Random
Shawn Ligocki added the comment: Yep, tested it on a 64-bit machine and 2 32-bit machines and back and forth between them. It seems to resolve the problem. _ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1727780> _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1727780] 64/32-bit issue when unpickling random.Random
Shawn Ligocki added the comment:
I've got a patch! The problem was that the state was being cast from a
C-type unsigned long to a long.
On 32-bit machines this makes large 32-bit longs negative.
On 64-bit machines this preserves the sign of 32-bit values (because
they are stored in 64-bit longs).
My patch returns the values with PyLong_FromUnsignedLong() instead of
PyInt_FromLong(), therefore there is no casting to long and both 32-bit
and 64-bit machines produce the same result.
I added code to read states from the old (buggy) version and decypher it
appropriately (from either 32-bit or 64-bit source!). In other words,
old pickles can now be opened on either architecture with the new patch.
This patch is taken from the svn head, but also works on Python 2.5.1 .
I haven't tested this patch fully on 64-bit machine yet. I'll let you
know when I have.
Cheers,
-Shawn
_
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1727780>
_Index: Lib/random.py
===
--- Lib/random.py (revision 58178)
+++ Lib/random.py (working copy)
@@ -83,7 +83,7 @@
"""
-VERSION = 2 # used by getstate/setstate
+VERSION = 3 # used by getstate/setstate
def __init__(self, x=None):
"""Initialize an instance.
@@ -120,9 +120,20 @@
def setstate(self, state):
"""Restore internal state from object returned by getstate()."""
version = state[0]
-if version == 2:
+if version == 3:
version, internalstate, self.gauss_next = state
super(Random, self).setstate(internalstate)
+elif version == 2:
+version, internalstate, self.gauss_next = state
+# In version 2, the state was saved as signed ints, which causes
+# inconsistencies between 32/64-bit systems. The state is
+# really unsigned 32-bit ints, so we convert negative ints from
+# version 2 to positive longs for version 3.
+try:
+internalstate = tuple( long(x) % (2**32) for x in internalstate )
+except ValueError, e:
+raise TypeError, e
+super(Random, self).setstate(internalstate)
else:
raise ValueError("state with version %s passed to "
"Random.setstate() of version %s" %
Index: Modules/_randommodule.c
===
--- Modules/_randommodule.c (revision 58178)
+++ Modules/_randommodule.c (working copy)
@@ -319,12 +319,12 @@
if (state == NULL)
return NULL;
for (i=0; istate[i]));
+ element = PyLong_FromUnsignedLong(self->state[i]);
if (element == NULL)
goto Fail;
PyTuple_SET_ITEM(state, i, element);
}
- element = PyInt_FromLong((long)(self->index));
+ element = PyLong_FromLong((long)(self->index));
if (element == NULL)
goto Fail;
PyTuple_SET_ITEM(state, i, element);
@@ -339,7 +339,8 @@
random_setstate(RandomObject *self, PyObject *state)
{
int i;
- long element;
+ unsigned long element;
+ long index;
if (!PyTuple_Check(state)) {
PyErr_SetString(PyExc_TypeError,
@@ -353,16 +354,16 @@
}
for (i=0; istate[i] = (unsigned long)element;
+ self->state[i] = element & 0xUL; /* Make sure we get sane state */
}
- element = PyInt_AsLong(PyTuple_GET_ITEM(state, i));
- if (element == -1 && PyErr_Occurred())
+ index = PyLong_AsLong(PyTuple_GET_ITEM(state, i));
+ if (index == -1 && PyErr_Occurred())
return NULL;
- self->index = (int)element;
+ self->index = (int)index;
Py_INCREF(Py_None);
return Py_None;
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
