#apache #archlinux #asterisk #centos #debian #gentoo #haskell #kde #kubuntu #lisp #math #mysql #perl #python #ruby-lang #rubyonrails #suse #ubuntu #vim #wikipedia 0 1 2 3 4 5 6 7 8 9 10 11
Top Prev 6405 6406 6407 6408 6409 6410 6411 6412 6413 6414 6415 6416 6417 6418 6419 6420 6421 6422 6423 Next
#python
<Jerub> guido_g: 'new' isn't a special word at all in python
<Jerub> guido_g: it's not even a builtin
<guido_g> Jerub: /me knows
<guido_g> it'S just a name, as i said
<guido_g> still, i can'T figure out what's wrong with the code from CJLucas
<CJLucas> ya, heres the code if you guys want to take a look http://pastebin.com/885071
<CJLucas> traceback at the bottom
<alus> so (long_string.lower() == another_long_string.lower()) is bothering me.
<alus> it converts both strings to lower case before even starting the compare
<alus> perhaps the first character is different - a smart compare would stop there
<guido_g> you said .lower() and now you complain that it does what you demand?
<alus> is there another paradigm in python?
<SevenInchBread> that's because lower() happens before ==
<deitarion> guido_g: alus is trying to pre-optimize, I think.
<guido_g> pfff
<alus> perhaps just form a good habit.
<alus> python is slow enough as it is - no need to make it worse
<SevenInchBread> doesn't sound like something you'd want to optimize... the only time .lower() would cause any performance issues is if you were handling like a 2 gigabyte string... in which case a lower() operation would be the least of your worries.
<deitarion> alus: Premature optimization is the root of all evil. :P
<deitarion> Code first, profile and optimize as necessary.
<deitarion> ...and never obfuscate your code just because you think it might cause problems.
<guido_g> *and* don't complain if you not *absolutely* sure you have something to complain about
<SevenInchBread> ...and always scrub behind your ears.
<alus> well, a better paradigm would not be obfuscation
<deitarion> and never visit ##php. They're the least helpful place on the net.
<alus> strnicmp(long_string, another_long_string) is just fine
<alus> deitarion: my previous encounters with python have been: code first, profile and optimize by rewriting in C++ instead of python
<pjd> C++? are you mad? :)
<alus> wouldn't it be nice if I didn't have to?
<SevenInchBread> sometimes I'm tempted to create a CaseInsensitiveString class that makes all the compare operations case insensitive (or at least appear case insensitive on the surface).
<SevenInchBread> so I don't have to do all those pesky lowers()
<Chousuke> That might be the most OO approach.
<SevenInchBread> I'd call it a lazy approach. :)
<pjd> sevard: think about dictionaries
<Chousuke> SevenInchBread: a simple function is easier ;P
<SevenInchBread> nah... why call something over and over throughout your program for something that could be specified once and forgotten?
<SevenInchBread> easy is a subjective term. :)
<SevenInchBread> heh... if I wanted to squeeze out every ounce of performance I could get (and if I were insane)... I'd implement CaseInsensitiveString in C.
<alus> when compared to copying two buffers, converting them to lower case, then comparse, I'd hardly say you have to squeeze to get performance
<alus> *comparing
<alus> like I said, strnicmp(). done.
<SevenInchBread> ....indeed... it takes all of a fraction-of-a-second to occur.
<Chousuke> Hmm, can you just subclass the built-in string an redefine the comparisons?
<SevenInchBread> wouldn't want to waste our previous nanoseconds would we? It's why we made microwaves and jet planes.
<alus> yes but then implementing the loop in python would make it slower for sure
<SevenInchBread> ....
<SevenInchBread> alus, seriously... it's -not- that big of a deal.
<pjd> any C/Python hackers around?
<SevenInchBread> ..erm.. kinda?
<Chousuke> It will make a difference if there are hundreds or thousands of comparisons with very long strings that are often different, though
Previous Page Next Page