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
<http://bugs.python.org/issue23287>
___
___
Python-bug
Changes by Shawn :
--
nosy: +swalker
___
Python tracker
<http://bugs.python.org/issue26414>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Shawn :
--
nosy: +swalker
___
Python tracker
<http://bugs.python.org/issue22148>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Shawn :
--
nosy: +swalker
___
Python tracker
<http://bugs.python.org/issue13405>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Changes by Shawn :
--
nosy: +swalker
___
Python tracker
<http://bugs.python.org/issue21412>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
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 "calc
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
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 be
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
Shawn Brown <03sjbr...@gmail.com> added the comment:
Currently, I'm monkey patching _safe_key (adding a try/except) as follows:
>>> import pprint
>>>
>>> class _safe_key(pprint._safe_key):
>>> def __lt__(self, other):
>>>
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)
Shawn added the comment:
I'm an idiot; nevermind my comment. The original date was bogus.
--
___
Python tracker
<http://bugs.python.org/issue14157>
___
___
Shawn 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 "", line 1, in
File "/usr/lib/python2.6/_s
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 intuiti
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/is
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
Shawn Ligocki added the comment:
Great! Glad it landed :)
--
___
Python tracker
<http://bugs.python.org/issue10860>
___
___
Python-bugs-list mailing list
Unsub
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://
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/is
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://bug
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
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
Shawn 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. Bu
New submission from Shawn :
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 raises shutil.
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.
Shawn 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 now, you will
n
Shawn 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 was to blame.
After
Shawn 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
<http://bugs.python.org/issue6
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 ur
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/issue7
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
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
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
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
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 r
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 r
Shawn 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 that simplejso
Shawn 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 no penalty at all (
New submission from Shawn :
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 mixed values (
New submission from Shawn Smout :
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, 2]) as expected
New submission from Shawn Ashlee :
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('DEFAUL
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
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/iss
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
45 matches
Mail list logo