On Dec 3, 10:41 am, Filip Gruszczyński wrote:
> I have just written a very small snippet of code and started thinking,
> which version would be more pythonic. Basically, I am adding a list of
> string to combo box in qt. So, the most obvious way is:
>
> for choice in self.__choices:
> choi
Filip Gruszczyński a écrit :
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice)
But
In article ,
Filip GruszczyÅ ski wrote:
>
>for choice in self.__choices:
> choicesBox.addItem(choice)
This is the easiest to read. I'm guessing that this is not inner-loop
stuff that needs to be optimized, so you should favor readability over
performance.
--
-Ed Falk, f...@despam
On 12/4/2009 11:44 AM, Rhodri James wrote:
map(self.__choices, choicesBox.addItem)
or
[choicesBox.addItem(choice) for choice in self.__choices]
Aside from being pythonic or non-pythonic, using map or list
comprehension with a method with side-effect is not the intention of
functional progra
Filip Gruszczyński wrote:
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice)
But I
On Thu, 03 Dec 2009 15:41:56 -, Filip Gruszczyński
wrote:
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
I have just written a very small snippet of code and started thinking,
which version would be more pythonic. Basically, I am adding a list of
string to combo box in qt. So, the most obvious way is:
for choice in self.__choices:
choicesBox.addItem(choice)
But I could also do:
map(self.__c
John Machin wrote:
On Apr 2, 2:10 am, John Posner wrote:
Dennis Lee Bieber presented a code snippet with two consecutive statements
that made me think, "I'd code this differently". So just for fun ... is
Dennis's original statement or my "_alt" statement more idiomatically
Pythonic? Are there e
On Apr 2, 2:10 am, John Posner wrote:
> Dennis Lee Bieber presented a code snippet with two consecutive statements
> that made me think, "I'd code this differently". So just for fun ... is
> Dennis's original statement or my "_alt" statement more idiomatically
> Pythonic? Are there even more Pytho
>> > mrkrs_alt2 = filter(lambda b: b > 127 or b in list("\r\n\t"),
block)
>> >
>>
>> Never tested my 'pythonicity', but I would do:
>>
>> def test(b) : b > 127 or b in r"\r\n\t"
Oops! Clearly,
b in "\r\n\t"
is preferable to ...
b in list("\r\n\t")
You do *not* want to u
On Apr 1, 5:10 pm, John Posner wrote:
> Dennis Lee Bieber presented a code snippet with two consecutive statements
> that made me think, "I'd code this differently". So just for fun ... is
> Dennis's original statement or my "_alt" statement more idiomatically
> Pythonic? Are there even more Pytho
Dennis Lee Bieber presented a code snippet with two consecutive statements
that made me think, "I'd code this differently". So just for fun ... is
Dennis's original statement or my "_alt" statement more idiomatically
Pythonic? Are there even more Pythonic alternative codings?
mrkrs = [b for b i
[EMAIL PROTECTED] wrote:
> I have a goal function that returns the fitness of a given solution. I
> need to wrap that function with a class or a function to keep track of
> the best solution I encounter. Which of the following would best serve
> my purpose and be the most pythonic?
You could write
On Jan 25, 5:14 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> I have a goal function that returns the fitness of a given solution. I
> need to wrap that function with a class or a function to keep track of
> the best solution I encounter. Which of the following would best serve
> my purpose
Well, regardless of being "pythonic" or not, the first is far more
understandable and therefore more maintainable. Objects were invented
to handle holding state; using a function to hold state is, in my
opinion, doing a language-based cheat. :)
tj
On Jan 24, 2008, at 10:14 PM, [EMAIL PROTE
I have a goal function that returns the fitness of a given solution. I
need to wrap that function with a class or a function to keep track of
the best solution I encounter. Which of the following would best serve
my purpose and be the most pythonic?
class Goal:
def __init__(self, goal):
On May 10, 2:39 pm, Steven Bethard <[EMAIL PROTECTED]> wrote:
> 7studwrote:
> >> Is there any documentation for the syntax you used with timeit?
>
> > This is the syntax the docs describe:
> [snip
> > python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
> [snip]
> > Then in the exam
Peter Otten <[EMAIL PROTECTED]> wrote:
> Note the -s before the initialization statement that Alex meant to add but
> didn't. If that is missing
Yep, sorry for erroneously skipping the -s!
Alex
--
http://mail.python.org/mailman/listinfo/python-list
7stud wrote:
>> Is there any documentation for the syntax you used with timeit?
>
> This is the syntax the docs describe:
[snip
> python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
[snip]
> Then in the examples in section 10.10.2
[snip]
> timeit.py 'try:' ' str.__nonzero__' 'exc
> Is there any documentation for the syntax you used with timeit?
This is the syntax the docs describe:
---
Python Reference Library
10.10.1:
When called as a program from the command line, the following form is
used:
python timeit.py [-n N] [-r N] [-s S] [-t] [-c] [-h] [statement ...]
---
Then
Stargaming wrote:
> Alex Martelli schrieb:
>> 7stud <[EMAIL PROTECTED]> wrote:
>>...
>>
.append - easy to measure, too:
brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
100 loops, best of 3: 1.31 usec per loop
brain:~ alex$ python -mtimeit '
Alex Martelli schrieb:
> 7stud <[EMAIL PROTECTED]> wrote:
>...
>
>>>.append - easy to measure, too:
>>>
>>>brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
>>>100 loops, best of 3: 1.31 usec per loop
>>>
>>>brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x+=
7stud <[EMAIL PROTECTED]> wrote:
...
> > .append - easy to measure, too:
> >
> > brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x.append(n)'
> > 100 loops, best of 3: 1.31 usec per loop
> >
> > brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]; x+=[n]'
> > 100 loops, be
On May 9, 11:08 am, 7stud <[EMAIL PROTECTED]> wrote:
> On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
>
>
>
> > alf <[EMAIL PROTECTED]> wrote:
> > > two ways of achieving the same effect
>
> > > l+=[n]
>
> > >
On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> alf <[EMAIL PROTECTED]> wrote:
> > two ways of achieving the same effect
>
> > l+=[n]
>
> > or
>
> > l.append(n)
>
> > so which is more pythonic/faster?
>
> .append - easy to m
On May 8, 11:05 pm, [EMAIL PROTECTED] (Alex Martelli) wrote:
> alf <[EMAIL PROTECTED]> wrote:
> > two ways of achieving the same effect
>
> > l+=[n]
>
> > or
>
> > l.append(n)
>
> > so which is more pythonic/faster?
>
> .append - easy to m
alf <[EMAIL PROTECTED]> wrote:
> two ways of achieving the same effect
>
>
> l+=[n]
>
> or
>
> l.append(n)
>
>
> so which is more pythonic/faster?
.append - easy to measure, too:
brain:~ alex$ python -mtimeit 'L=range(3); n=23' 'x=L[:]
two ways of achieving the same effect
l+=[n]
or
l.append(n)
so which is more pythonic/faster?
--
alfz1
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, 12 Sep 2005 12:52:52 +0200, gabor <[EMAIL PROTECTED]> wrote:
> hi,
>
> there are 2 versions of a simple code.
> which is preferred?
I don't know. Who cares?
> ===
> try:
> text = line[n]
> except IndexError:
> text = 'nothing'
> ===
>
>
> which is the one you would use?
The '
Peter Hansen wrote:
> def meth(self, things=None):
> self.things = things or []
>
[snip]
>
> The alternative is fine too, but insisting on it would be pedantic, and
> if you have more than one of these it is definitely less readable (and,
> therefore, not Pythonic):
>
> def meth(self, thin
Ken Seehart wrote:
> Will McGugan wrote:
>> I would actualy use the following for this particular case..
>>
>> text = line[n:n+1] or 'nothing'
> Hey are you a perl programmer? That looks perlish to me. A python
> programmer would never use "or" that way (even though it works). :)
I don't thin
Will McGugan wrote:
> gabor wrote:
>
>> hi,
>>
>> there are 2 versions of a simple code.
>> which is preferred?
>>
>>
>> ===
>> if len(line) >= (n+1):
>> text = line[n]
>> else:
>> text = 'nothing'
>> ===
>>
>>
>> ===
>> try:
>> text = line[n]
>> except IndexError:
>> text = 'nothi
"gabor" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> i'm sorry ;) it was a list of strings...
>
> the code was something like:
>
> for line in open('x.y'):
> line = line.split('\t')
>
> a better naming would be better it seems :)
Like 'fields', for a list of fields ;-?
Or your
Terry Reedy wrote:
> "Will McGugan" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>
>>You may be right. I always use plural nouns for collections.
>
>
> ditto
>
>>To me 'line' would suggest there was just one of them,
>>so I assumed it was string.
>
>
> I did too.
>
i'm sor
"Will McGugan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> You may be right. I always use plural nouns for collections.
ditto
> To me 'line' would suggest there was just one of them,
> so I assumed it was string.
I did too.
for line in file('skljflask.txt',r): # or similar
i
Steve Holden wrote:
> I'd say it's much more likely that line is a list of lines, since it
> seems improbable that absence of a character should cause a value of
> "nothing" to be required.
You may be right. I always use plural nouns for collections. To me
'line' would suggest there was just o
Steven Bethard wrote:
> Exceptions are for
> "exceptional" conditions, that is, things that you expect to happen
> infrequently[1]. So if I think the code is going to fail frequently, I
> test the condition, but if I think it won't, I use exceptions.
I think there exceptions (no pun intended)
Will McGugan wrote:
> Pierre Barbier de Reuille wrote:
>
>
>>>I would actualy use the following for this particular case..
>>>
>>>text = line[n:n+1] or 'nothing'
>>
>>
>>... and you would get either a list of one element or a string ...
>>I think you wanted to write :
>>
>>text = (line[n:n+1] or
Steven D'Aprano wrote:
> try...except... blocks are quick to set up, but slow to catch the
> exception. If you expect that most of your attempts will succeed, then the
> try block will usually be faster than testing the length of the list
> each time.
>
> But if you expect that the attempts to wri
Pierre Barbier de Reuille wrote:
>>
>>I would actualy use the following for this particular case..
>>
>>text = line[n:n+1] or 'nothing'
>
>
> ... and you would get either a list of one element or a string ...
> I think you wanted to write :
>
> text = (line[n:n+1] or ['nothing'])[0]
I was assu
Will McGugan a écrit :
> gabor wrote:
>
>> hi,
>>
>> there are 2 versions of a simple code.
>> which is preferred?
>>
>>
>> ===
>> if len(line) >= (n+1):
>> text = line[n]
>> else:
>> text = 'nothing'
>> ===
>>
>>
>> ===
>> try:
>> text = line[n]
>> except IndexError:
>> text = 'no
gabor wrote:
> hi,
>
> there are 2 versions of a simple code.
> which is preferred?
>
>
> ===
> if len(line) >= (n+1):
> text = line[n]
> else:
> text = 'nothing'
> ===
>
>
> ===
> try:
> text = line[n]
> except IndexError:
> text = 'nothing'
> ===
>
>
> which is the one you
On Mon, 12 Sep 2005 12:52:52 +0200, gabor wrote:
> hi,
>
> there are 2 versions of a simple code.
> which is preferred?
>
>
> ===
> if len(line) >= (n+1):
> text = line[n]
> else:
> text = 'nothing'
> ===
>
>
> ===
> try:
> text = line[n]
> except IndexError:
> text =
hi,
there are 2 versions of a simple code.
which is preferred?
===
if len(line) >= (n+1):
text = line[n]
else:
text = 'nothing'
===
===
try:
text = line[n]
except IndexError:
text = 'nothing'
===
which is the one you would use?
thanks,
gabor
--
http://mail.p
44 matches
Mail list logo
