I created an issue for the pylint folks:
https://github.com/PyCQA/pylint/issues/774
Skip
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Jan 11, 2016 at 6:04 PM, Skip Montanaro
wrote:
> Sorry, I should have been explicit. prob_dates (the actual argument of the
> call) is a set. As far as I know pylint does no type inference, so pylint
> can't tell if the LHS and RHS of the |= operator are appropriate, nor can
> it tell if i
Apologies for self-replying
On 12/01/16 08:24, Erik wrote:
On 12/01/16 07:13, Cameron Simpson wrote:
The former. Almost any loop _might_ be executed zero times. Compilers
and linters etc should only complain if they can prove the loop is
always executed zero times.
I was just raising the
poss
On 12/01/16 07:13, Cameron Simpson wrote:
On 11Jan2016 23:55, Erik wrote:
Is it complaining about that, or is it because the 'for' loop body
might be executed zero times?
The former. Almost any loop _might_ be executed zero times. Compilers
and linters etc should only complain if they can pro
On 11Jan2016 23:55, Erik wrote:
On 11/01/16 23:26, Skip Montanaro wrote:
If I change the last line of find_problems to call
prob_dates.update(), the message disappears. Why is pylint (1.4.2 BTW)
complaining that the prob_dates argument of find_problems is unused
when I use the |= operator?
Is
Sorry, I should have been explicit. prob_dates (the actual argument of the
call) is a set. As far as I know pylint does no type inference, so pylint
can't tell if the LHS and RHS of the |= operator are appropriate, nor can
it tell if it has an update() method.
Before writing, I had more-or-less co
On 1/11/2016 6:26 PM, Skip Montanaro wrote:
Here's a dumb little bit of code, adapted from a slightly larger script:
#!/usr/bin/env python
"dummy"
import glob
import os
def compare_prices(*_args):
"dummy"
return set()
def find_problems(cx1, cx2, cx3, prob_dates):
"dummy"
On Monday, January 11, 2016 at 3:27:21 PM UTC-8, Skip Montanaro wrote:
> Here's a dumb little bit of code, adapted from a slightly larger script:
>
> #!/usr/bin/env python
>
> "dummy"
>
> import glob
> import os
>
> def compare_prices(*_args):
> "dummy"
> return set()
>
> def find_prob
On 11/01/16 23:26, Skip Montanaro wrote:
If I change the last line of find_problems to call
prob_dates.update(), the message disappears. Why is pylint (1.4.2 BTW)
complaining that the prob_dates argument of find_problems is unused
when I use the |= operator?
Is it complaining about that, or is
Here's a dumb little bit of code, adapted from a slightly larger script:
#!/usr/bin/env python
"dummy"
import glob
import os
def compare_prices(*_args):
"dummy"
return set()
def find_problems(cx1, cx2, cx3, prob_dates):
"dummy"
for fff in sorted(glob.glob("/path/to/*.nrm")):
"Joe Goldthwaite" <[EMAIL PROTECTED]> writes:
> To do a range(100)
>
> 1. Allocate a big chunk of memory
> 2. Fill the memory with the range of integers
> 3. Setup an index into the memory array
> 4. Every time the program asks for the next item, bump
> the mem
On Dec 11, 3:55 am, "Chris Mellon" <[EMAIL PROTECTED]> wrote:
[snip]
> No. What range does is create and return a list of integers. The
> iteration is a separate step, and is traditional list iteration. In
> longhand, for x in range(y): looks something like this:
>
> range = []
> #this loop happens
On Dec 7, 2007 8:58 PM, Joe Goldthwaite <[EMAIL PROTECTED]> wrote:
> >You can't imagine why someone might prefer an iterative solution over
> >a greedy one? Depending on the conditions, the cost of creating the
> >list can be a greater or a lesser part of the total time spent. Actual
> >iteration i
>You bring up an excellent point. It might seem like I'm actually running
on
>a Macbook Pro with an Intel Core 2 Duo at 2.33 GHz with 2 GB of ram.
Err... Uhh... What I meant to say was "It might seem like I'm running on an
old
slow POS but I'm actually running on a Macbook Pro..."
Sorry, me fl
>You can't imagine why someone might prefer an iterative solution over
>a greedy one? Depending on the conditions, the cost of creating the
>list can be a greater or a lesser part of the total time spent. Actual
>iteration is essentially the same cost for both. Try looking at memory
>usage while yo
On Dec 7, 4:08 pm, "Joe Goldthwaite" <[EMAIL PROTECTED]> wrote:
> Here's the simple benchmark;
>
> start = time.time()
> for x in xrange(3):
> for y in xrange(1000):
> pass
> print 'xRange %s' % (time.time() - start)
>
> start = time.time()
> for x in range(3):
>
>90+ seconds?? What hardware, OS, and Python version? What else was
>running in the background?
>With this kit:
>OS Name: Microsoft Windows XP Professional
>Version: 5.1.2600 Service Pack 2 Build 2600
>Processor: x86 Family 15 Model 36 Stepping 2 AuthenticAMD ~1995 Mhz
>Python: Pyt
>> Here's what I get;
>>
>> xRange 92.552733
>> Range 95.266599
>
> Try tracking your memory usage during the benchmark and
> it will become very clear why xrange exists.
Or, when memory-constrained and this extra memory usage pushes
your machine to pound on your swap...not a pretty sight
On Dec 8, 8:08 am, "Joe Goldthwaite" <[EMAIL PROTECTED]> wrote:
> Here's the simple benchmark;
>
> start = time.time()
> for x in xrange(3):
> for y in xrange(1000):
> pass
> print 'xRange %s' % (time.time() - start)
>
> start = time.time()
> for x in range(3):
>
-Original Message-
> From: [EMAIL PROTECTED]
>
> [mailto:[EMAIL PROTECTED] Behalf Of
> Bjoern Schliessmann
> Sent: Thursday, December 06, 2007 3:33 PM
> To: [EMAIL PROTECTED]
> Subject: Re: I'm missing something here with range vs. xrange
>
> Joe Goldthwaite wro
On Dec 7, 2007 3:08 PM, Joe Goldthwaite <[EMAIL PROTECTED]> wrote:
> Here's the simple benchmark;
>
> start = time.time()
> for x in xrange(3):
> for y in xrange(1000):
> pass
> print 'xRange %s' % (time.time() - start)
>
> start = time.time()
> for x in range(3):
>
ern Schliessmann
Sent: Thursday, December 06, 2007 3:33 PM
To: python-list@python.org
Subject: Re: I'm missing something here with range vs. xrange
Joe Goldthwaite wrote:
> I read that the range function builds a list and that xrange
> returns an iterator and is therefore more effici
Joe Goldthwaite wrote:
> I read that the range function builds a list and that xrange
> returns an iterator and is therefore more efficient.
This is generally not true.
> In my testing, they both come out to almost exactly the same
> performance wise. Did something get changed in Python 2.4 to
I've been playing with Python a bit. Doing little performance benchmarks and
working with Psyco. It's been fun and I've been learning a lot. For
example, in a previous post, I was looking for a way to dynamically add new
runtime function to a class. Martin told me to use a class instance
variabl
24 matches
Mail list logo
