[IPython-dev] Any reason to keep user_ns() as a call?

[Fernando Perez]

On 5/18/06, Ville Vainio <vivainio at gmail.com> wrote:

> The reasoning is that a function call could theoretically return a
> different dictionary at different times. I'm ok with changing it to
> represent the dictionary directly, it could be made a property if it
> needs to become dynamic. It will require some changes in other parts
> of the code, though.

OK, I just committed some changes which cleaned up the api to use
either explicit attributes or properties, but with a homogeneous
attribute syntax.  Properties are a really nice python feature, I
really dislike classes full of getters and setters, which remind me
way too much of C++/Java code.  I still had to use properties in a few
places b/c I couldn't disentangle our initialization order hairball,
but all tests I did seem OK.

I think the code is cleaner, and in the new branch I'll do my best to
respect this new API approach, whenever possible.  As things get
complicated, we can wrap things behind properties but users will not
need to worry about syntax changes.

One thing I did /not/ do, but I'm wondering about, is making all the
getters (used by the properties internally) _private, so that anyone
poking around with a TAB key has a better clue of what they shouldn't
be doing.  Feel free to finish it off, I need to turn my attention to
other things now.

It's quite possible I didn't spot some problems still after all my
changes, so please play with this: I'd like this API to remain fairly
stable from 0.7.2 onwards in the trunk (and even in chainsaw, as I
mentioned).

Cheers,

f