How complex is complex?

[pruebauno at latinmail.com]

On Mar 19, 1:25 pm, Paul Hildebrandt <paul_hildebra... at yahoo.com>
wrote:
> On Mar 19, 9:41 am, Kottiyath <n.kottiy... at gmail.com> wrote:
>
>
>
> > On Mar 19, 9:33 pm, Kottiyath <n.kottiy... at gmail.com> wrote:
>
> > > On Mar 19, 8:42 pm, Paul McGuire <pt... at austin.rr.com> wrote:
>
> > > > On Mar 19, 4:39 am, Kottiyath <n.kottiy... at gmail.com> wrote:
>
> > > > > I understand that my question was foolish, even for a newbie.
> > > > > I will not ask any more such questions in the future.
>
> > > > Gaaah! Your question was just fine, a good question on coding style.
> > > > I wish more people would ask such questions so that bad habits could
> > > > be avoided.
>
> > > > The newbie posts that are annoying are the ones that:
> > > > - are answered on page 1 of any tutorial ("how do I get the second
> > > > character of a string?")
> > > > - are obvious homework assignments with no actual effort on the
> > > > poster's part ("how do I write a Python program to find the first 10
> > > > prime numbers?")
> > > > - pontificate on what is wrong with Python, based on 2 hours'
> > > > experience with the language (often titled "What's wrong with Python",
> > > > with content like "Python sucks because it doesn't have a switch
> > > > statement/has significant whitespace/doesn't check types of arguments/
> > > > isn't totally object-oriented like Java/doesn't have interfaces/...")
> > > > - are so vague as to be just Usenet noise (titled "Help me", with no
> > > > content, or "i need to write a program and don't know where to start
> > > > can someone write it for me?")
>
> > > > I think Daniel's joke was on the rest of us, who each had to chime in
> > > > with our favorite dict processing algorithm.
>
> > > > It *would* be good for you as a newbie to get an appreciation of the
> > > > topics that were covered in these responses, though, especially the
> > > > distinction between updating the dict in-place vs. creating a new
> > > > dict.
>
> > > > -- Paul
>
> > > Daniel, Sorry for misunderstanding your post. I hope I was not being
> > > passive-aggresive - (also because I found that the second mechanism I
> > > provided was quite horrible :-), so I was indeed being foolish
> > > there. )
>
> > > Paul/Aahz, I did understand 2 things
> > > (1) When using map always consider that the function will be called
> > > everytime, so the hit on the performance is more.
> > > (2) The second mechanism and the first mechanism provides different
> > > solutions (new dict/same dict)
> > > both of which I did not think about at all.
>
> > > Also, thank you everyone for all the help. I have been following this
> > > thread for the last 4 months (when I started with python) and I have
> > > learned a lot. The amount of help provided here is amazing.
>
> > > p.s. -> English is indeed not my first language :-)
>
> > Oops, Forgot to mention the biggest learning.
>
> > Readability is better than brevity -
>
> I rewrote your sentence to be more optimized.
>
> Readability > brevity
>
> ;-)
>
> > Thanks to Rhodri.
>
> > This was a question which was bugging me all the time. When I look at
> > code, I am always envious when I see the same code written in much
> > smaller number of lines. Now, I will force myself to ask the questions
> > Rhodri proposed (esp: does it look uglier part) before deciding
> > whether or not to go ahead with brevity.
>
>

sometimes: brevity==Readability

but as in many things the trick is in finding the right tradeoff. I am
willing to accept some trivial amount of additional complexity if it
means I have to read less lines of code, but I have my limits too. I
aim for a comprehension speed of 2-10 lines per minute for somebody
proficient in the language.