At 06:22 PM 5/2/02 -0500, you wrote:
>On Thu, 2 May 2002, Ray Nawara Jr wrote:
> > Why, at this point, is that useful information? Both sequences and maps
> > work with the len() builtin.
>It's useful because people who are adding/looking at/fixing code in that
>area would be more aware of the fact it's a map and not a sequence. Right
>now, Sebastian is doing a smidgeon of work, but I'm gettind diffs from
>Brian and Josh is changing code as well. It's somewhat chaotic in some
>ways. I know I keep committing things to the codebase that don't entirely
>work correctly as I fix other people's code which didn't work for me.
>Lyntin 3.0 is not ready for prime time yet. It's still undergoing some
>huge overhauls of overhauls of overhauls. In the process, the code is
>getting a bit messy and it's getting a bit krufty--as often pointed out by
>Until we've got some of the bigger algorithmic issues solved, I'd rather
>keep things super readable and not worry too much about one-line
>optimizations like this because ultimately if we start focusing on
>optimization throughout the codebase while it's in a state of flux, it'll
>make things more difficult.
>That's the general idea and the priority here.
>Also, it irks me no end that people say certain things are faster without
>doing the analysis. I have no clue which one's faster, though I could see
>possible implementations. But I'm not going to change the code just
>because someone says it's faster this way versus that way if I'm not sure
>either way. There's too much code and we'd be in a constant state of
>changing this and that and the other thing and in some cases changing it
>back later on.
Well, a function call is going to be less efficient than not calling the
function at all.
The worst possible implementation of __len__ for dictionaries will call
though it's a lot more likely that it stores the length internally. A call
to keys() is unlikely
to be more efficient than O(n). In some of the mud work I've done, we've
had severe issues
with dramatically large mappings. Unlikely to happen within the context of
Lyntin, which is
why I mentioned previously that really I'm just nitpicking, but I feel it's
better to not
produce code that may some point in the future come back to bite you. What
I really don't understand is, if you want clarity and such, why not just
use a comment or a variable
name standardization? (e.g. all dictionaries are named foo_dict or such).
I guess that really totally sums up my problem with the len(map.keys()) vs
Yes, it's more important to get the big issues out of the way first, but it
never hurts to make
sure your code is as clean and efficient as possible in the process,
particularly when dealing with
commonly used code mechanisms.
>Should I sit down and do all the analysis to figure out which way is
>faster? Yes. Is it realistic for me to do so? No--I just don't have
>that much time.
>To be honest, I haven't sat down and read through the entire codebase in
>some 4 months or so. I'm handling diffs from a bunch of different people
>who have different coding styles. So right now I'm working between 3 and
>4 hours a night on Lyntin coding, stabalization, testing, conversation,
>and general project maintenance.
>I'm definitely not against optimization, just that I want to keep
>readability a priority over optimization right now. At some point after
>we've gone into beta and the change rate slows down, then I'll be all over
>optimizations because things at that point will be in concrete and the
>problem domains won't be changing.
>I hope that gets across what I'm thinking at this stage.
Certainly. It's not a big issue, just something that mildly irked me so I
mention it. No more nitpicking from me. Anyway, keep up the good work!
Ray Nawara Jr.