New submission from shawn :
 File "D:\yolov3\train.py", line 430, in
train() # train normally
 File "D:\yolov3\train.py", line 236, in train
for i, (imgs, targets, paths, _) in pbar: # batch
-
File "D:
Shawn added the comment:
Could we get someone to evaluate this please?
--
nosy: +swalker
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Shawn <binarycrusa...@gmail.com>:
--
nosy: +swalker
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26414>
___
__
Changes by Shawn binarycrusa...@gmail.com:
--
nosy: +swalker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22148
___
___
Python-bugs-list mailing
Changes by Shawn binarycrusa...@gmail.com:
--
nosy: +swalker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13405
___
___
Python-bugs-list mailing
Changes by Shawn binarycrusa...@gmail.com:
--
nosy: +swalker
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21412
___
___
Python-bugs-list mailing
Shawn Krisman added the comment:
This fix is actually backwards compatible. This is a more powerful patch too
because not only does it provide a better default for truthiness, but it also
provides a better default for length. I also fixed a spelling mistake involving
the word calculate
Shawn Krisman added the comment:
Yeah in my head I was thinking it would affect relatively few people who
depended on the change, but it's definitely hard to prove that!
How about a change that special cases namedtuple?
--
___
Python tracker rep
New submission from Shawn Krisman:
import mock
from collections import namedtuple
Foo = namedtuple('Foo', bar)
mock_foo = mock.create_autospec(Foo)
if mock_foo:
print('the namedtuple is truthy')
else:
print('the namedtuple is not truthy')
The expected behavior is that it should print
Shawn Brown 03sjbr...@gmail.com added the comment:
Here's a patch for 3.3 -- as well as two new assertions in test_pprint.py
The added try/catch also fixes the issues mentioned in issue 10017 so I added a
test for that case as well.
--
keywords: +patch
Added file: http
New submission from Shawn Brown 03sjbr...@gmail.com:
This is related to resolved issue 3976 and, to a lesser extent, issue 10017.
I've run across another instance where pprint throws an exception (but works
fine in 2.7 and earlier):
Python 3.2 (r32:88445, Mar 25 2011, 19:28:28)
[GCC 4.5.2
Shawn swal...@opensolaris.org added the comment:
I'm seeing this when a year *is* specified with Python 2.6 and 2.7:
import time
time.strptime(20090229T184823Z, %Y%m%dT%H%M%SZ)
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/lib/python2.6/_strptime.py, line 454
Shawn swal...@opensolaris.org added the comment:
I'm an idiot; nevermind my comment. The original date was bogus.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14157
Shawn Ligocki sligo...@gmail.com 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
New submission from Shawn Ligocki sligo...@gmail.com:
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
Shawn Ligocki sligo...@gmail.com added the comment:
Ah, I see, it seems like that would be better suited directly after the section
title, don't you?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13489
Shawn Ligocki sligo...@gmail.com added the comment:
Great! Glad it landed :)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10860
___
___
Python
New submission from Shawn Ligocki sligo...@gmail.com:
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
New submission from Shawn Ligocki sligo...@gmail.com:
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
Shawn Ligocki sligo...@gmail.com 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 rep...@bugs.python.org
http://bugs.python.org
Shawn Ligocki sligo...@gmail.com added the comment:
Ahha, what a mess, thanks for investigating! I agree, this is bankofamerica's
problem.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10861
Shawn Ligocki sligo...@gmail.com 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
Shawn swal...@opensolaris.org added the comment:
I specifically mentioned *SPARC* as the performance problem area, but the reply
about 0.5s to dump fails to mention on what platform they tested
My problem is not undiagnosable. I'll be happy to provide you with even more
data files. But I
New submission from Shawn swal...@opensolaris.org:
The error handling present in the implementation of shutil.copytree in python
2.6.4 (and perhaps other versions) is non-standard and partially broken.
In particular, I'm unable to find any pydoc documentation that indicates that
when copytree
Shawn Ligocki sligo...@gmail.com 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 rep...@bugs.python.org
http
Shawn swal...@opensolaris.org added the comment:
The attached patch doubles write times for my particular case when
applied to simplejson trunk using python 2.6.2. Not good.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Shawn swal...@opensolaris.org added the comment:
You are right, an environment anomaly let me to falsely believe that
this had somehow affected encoding performance.
I had repeated the test many times with and without the patch using
simplejson trunk and wrongly concluded that the patch
Shawn swal...@opensolaris.org added the comment:
I've attached a sample JSON file that is much slower to write out on
some systems as described in the initial comment.
If you were to restructure the contents of this file into more of a tree
structure instead of the flat array structure it uses
Shawn Ligocki sligo...@gmail.com 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
Shawn Ligocki sligo...@gmail.com 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
Shawn Ligocki sligo...@gmail.com added the comment:
How about this, sweet and simple.
--
Added file: http://bugs.python.org/file15252/random.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7076
Shawn Ligocki sligo...@gmail.com 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
Shawn Ligocki sligo...@gmail.com 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
Shawn Ligocki sligo...@gmail.com 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
Shawn Ligocki sligo...@gmail.com 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
New submission from Shawn Ligocki sligo...@gmail.com:
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
Shawn swal...@opensolaris.org added the comment:
First, I want to apologise for not providing more detail initially.
Notably, one thing you may want to be aware of is that I'm using python
2.4.4 with the latest version of simplejson. So my timings and
assumptions here are based on the fact
Shawn swal...@opensolaris.org added the comment:
As I mentioned, there's also noticeable performance penalties on recent
SPARC systems, such as Niagra T1000, T2000, etc. The degradation is
just less obvious (a 10-15 second penalty instead of a 20 or 30 second
penalty). While x86 enjoys
New submission from Shawn swal...@opensolaris.org:
The json serializer's performance (when using the C speedups) appears to
be tied to the depth of the structure being serialized on some systems.
In particular, dict structure that are more than a few levels deep,
especially when they content
New submission from Shawn Smout silroq...@yahoo.com:
When calling the union method of a set with several arguments, if one of
those sets is the original set, all arguments appearing after it are
ignored. For example:
x = set()
x.union(set([1]), x, set([2]))
evaluates to set([1]), not set([1
New submission from Shawn Ashlee shawn.ash...@rackspace.com:
using .add_section() and .set() for the DEFAULT section adds it twice:
[u...@srv ~]$ cat test_configparser.py
#!/usr/bin/env python
import ConfigParser
a = ConfigParser.SafeConfigParser()
# borked
a.add_section('DEFAULT')
a.set
Shawn Morel [EMAIL PROTECTED] added the comment:
gpolo: The argument still doesn't hold. As you point out, it's the
Values class output from __str__ and other behaviour that is being un-
pythonic and leading you to believe it's a dictionary. Adding the
__itter__ method would only make
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
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
44 matches
Mail list logo
