> "Hendrik" == Hendrik van Rooyen <[EMAIL PROTECTED]> writes:
Hendrik> <[EMAIL PROTECTED]> wrote:
Hendrik> - as long as it works, and is fast enough, its not broken, so
Hendrik> don't fix it...
>> That's the rub. It wasn't fast enough. I only realized that had
>> been a
"Roel Schroeven" <[EMAIL PROTECTED]> wrote:
> Hendrik van Rooyen schreef:
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Hendrik> - as long as it works, and is fast enough, its not broken, so
> >> Hendrik> don't fix it...
> >>
> >> That's the rub. It wasn't fast enough. I only realized that h
Roel Schroeven schreef:
> Have you never experienced the following:
>
> A customer reports a bug. Upon investaging you find the source of the
> problem, but from studying the code you don't understand anymore how it
> has ever been able to function correctly. From that moment, it indeed
> stops
Hendrik van Rooyen schreef:
> <[EMAIL PROTECTED]> wrote:
>
>> Hendrik> - as long as it works, and is fast enough, its not broken, so
>> Hendrik> don't fix it...
>>
>> That's the rub. It wasn't fast enough. I only realized that had been a
>> problem once I fixed it though.
>
> LOL - this
<[EMAIL PROTECTED]> wrote:
> Hendrik> - as long as it works, and is fast enough, its not broken, so
> Hendrik> don't fix it...
>
> That's the rub. It wasn't fast enough. I only realized that had been a
> problem once I fixed it though.
LOL - this is kind of weird - it was working, nobod
[EMAIL PROTECTED] wrote:
> Hendrik> why? - the main point is actually that the code worked,
> and was Hendrik> stable - that should make you proud, not
> embarrassed. that Hendrik> there is far too much emphasis on
> doing things the quickest way Hendrik> - as long as it works, an
>> I will admit that way back when (maybe 8 yrs ago) I actually did this
>> in a piece of frequently executed code that's been stable for a
>> looong time. I have no idea why I might have written it that way.
>> Brain fart I suppose. I only noticed my mistake a couple months ago
<[EMAIL PROTECTED]> wrote:
> Peter> Bjoern Schliessmann wrote:
> >> Wouldn't be "if k in d.keys()" be the exact replacement?
>
> Peter> No, 'k in d' is equivalent to 'd.has_key(k)', only with less
> Peter> (constant) overhead for the function call. 'k in d.keys()' on the
> Pet
Peter> Bjoern Schliessmann wrote:
>> Wouldn't be "if k in d.keys()" be the exact replacement?
Peter> No, 'k in d' is equivalent to 'd.has_key(k)', only with less
Peter> (constant) overhead for the function call. 'k in d.keys()' on the
Peter> other hand creates a list of keys w
Paul Melis <[EMAIL PROTECTED]> wrote:
>> Ah, thx. Thought the "x in d" syntax might search in d.values() too.
>
> I don't think it does
>
> Python 2.4.3 (#1, Nov 19 2006, 13:16:36)
> [GCC 3.4.5 (Gentoo 3.4.5-r1, ssp-3.4.5-1.0, pie-8.7.9)] on linux2
> Type "help", "copyright", "credits" or "licen
Paul Melis wrote:
> I don't think it does
Thanks for trying, I was too lazy ;)
Regards,
Björn
--
BOFH excuse #52:
Smell from unhygienic janitorial staff wrecked the tape heads
--
http://mail.python.org/mailman/listinfo/python-list
"Peter Otten" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Andy Dingley wrote:
>
>>> sorted(setBugsChanged)
>
>> Out of interest, whats the Pythonic way to simply cast (sic) the set to
>> a list, assuming I don't need it sorted? The list comprehension?
>
> list(setBugsChanged
Andy Dingley wrote:
>> sorted(setBugsChanged)
> Out of interest, whats the Pythonic way to simply cast (sic) the set to
> a list, assuming I don't need it sorted? The list comprehension?
list(setBugsChanged)
Peter
--
http://mail.python.org/mailman/listinfo/python-list
Andy Dingley wrote:
> Out of interest, whats the Pythonic way to simply cast (sic) the set to
> a list, assuming I don't need it sorted? The list comprehension?
mySet = set(myList)
myList = list(mySet)
--
Roberto Bonvallet
--
http://mail.python.org/mailman/listinfo/python-list
Roberto Bonvallet wrote:
> >lstBugsChanged = [ bugId for bugId in setBugsChanged ]
> In Python > 2.4:
Hmmm. Thanks. Another reason to twist the admin's arm and get them to
upgrade the last 2.3.4 boxen
> sorted(setBugsChanged)
Out of interest, whats the Pythonic way to simply cast
Bjoern Schliessmann wrote:
> Peter Otten wrote:
>
>> No, 'k in d' is equivalent to 'd.has_key(k)', only with less
>> (constant) overhead for the function call.
>
> Ah, thx. Thought the "x in d" syntax might search in d.values() too.
I don't think it does
Python 2.4.3 (#1, Nov 19 2006, 13:16:36
Roberto Bonvallet wrote:
>> this is why e.g.
>>
>>string[:len(prefix)] == prefix
>>
>> is often a lot faster than
>>
>>string.startswith(prefix)
>
> This is interesting. In which cases does the former form perform better?
no time to doublecheck right now, but iirc, last time we benchmar
Peter Otten wrote:
> No, 'k in d' is equivalent to 'd.has_key(k)', only with less
> (constant) overhead for the function call.
Ah, thx. Thought the "x in d" syntax might search in d.values() too.
Regards,
Björn
--
BOFH excuse #12:
dry joints on cable plug
--
http://mail.python.org/mailma
I wrote:
> In Python > 2.4:
lastline.replace(">", ">=")
--
Roberto Bonvallet
--
http://mail.python.org/mailman/listinfo/python-list
Andy Dingley wrote:
> I need to generate a set (lots of intersections involved), but then I
> need to display it sorted
>
>lstBugsChanged = [ bugId for bugId in setBugsChanged ]
>lstBugsChanged.sort()
In Python > 2.4:
sorted(setBugsChanged)
--
Roberto Bonvallet
--
http://m
Andy Dingley wrote:
> I need to generate a set (lots of intersections involved), but then I
> need to display it sorted
>
>lstBugsChanged = [ bugId for bugId in setBugsChanged ]
>lstBugsChanged.sort()
lstBugsChanged = sorted(setBugsChanged)
--
http://mail.python.org/mailman
Paul Melis wrote:
> I've always been using the has_key() method to test if a dictionary
> contains a certain key. Recently I tried the same using 'in', e.g.
I've found using the set type to be the quickest way to do many of
these tasks. That leads me to another problem: how to cast / convert
sets
Fredrik Lundh wrote:
[...]
> this is why e.g.
>
>string[:len(prefix)] == prefix
>
> is often a lot faster than
>
>string.startswith(prefix)
This is interesting. In which cases does the former form perform better?
[I won't stop using str.startswith anyway :) ]
Regards.
--
Roberto Bonv
Bjoern Schliessmann wrote:
> Paul Melis wrote:
>
>> I've always been using the has_key() method to test if a
>> dictionary contains a certain key. Recently I tried the same using
>> 'in', e.g.
>>
>> d = { ... }
>> if k in d:
>> ...
>
> Wouldn't be "if k in d.keys()" be the exact replacement
Bjoern Schliessmann wrote:
> Wouldn't be "if k in d.keys()" be the exact replacement?
no. that would convert an O(1) operation to an O(n) operation, which
would be rather silly.
--
http://mail.python.org/mailman/listinfo/python-list
Paul Melis wrote:
> I've always been using the has_key() method to test if a
> dictionary contains a certain key. Recently I tried the same using
> 'in', e.g.
>
> d = { ... }
> if k in d:
> ...
Wouldn't be "if k in d.keys()" be the exact replacement?
Regards,
Björn
--
BOFH excuse #17:
Paul Melis wrote:
> I've always been using the has_key() method to test if a dictionary
> contains a certain key. Recently I tried the same using 'in', e.g.
>
> d = { ... }
> if k in d:
>...
>
> and found that it seems to perform a lot better when lots of key-tests
> are to be performed. I als
Hello,
I've always been using the has_key() method to test if a dictionary
contains a certain key. Recently I tried the same using 'in', e.g.
d = { ... }
if k in d:
...
and found that it seems to perform a lot better when lots of key-tests
are to be performed. I also noticed that has_key() i
28 matches
Mail list logo