[Pandas-dev] On merging new APIs into pandas

[yoval p.]

Hi,

>From time to time, new ideas for user APIs pop up on the issue
tracker. some are wacky and experimental, some a bade idea,
and some genuinely useful to users.

Adding user APIs is possibly the most sensitive type of change
because you only get one shot at getting it right before it
becomes legacy you have to support in existing code, so getting
a form/functionality/signature right is a real concern. Also, whenever
you add a new one , you "burn" a verb, since you replace
it's meaning down the line without unacceptable confusion,
so if you're targetting a "big one" like "choose" or "pick"
or "grep", you had better be damn sure you got it right.

Because of these reasons, I'm obviously hesitant to introduce
new APIs without a reasonable amount of discussion and concensus,
and to be honest, an ok from wes.
OTOH, I think there are good ideas stagnating on the issue tracker
because we don't have an accepted way (ad-hoc, light, but known
and sanctioned by wes) for making these types of "crucial" changes.

I'd like a couple of things to happen:
1) we should introduce a "sandbox" formalism, for shipping
experimental new features in a release while retaining the freedom to
make breaking changes when/if they are rolled back into
the "official" API, this could be backed by a pd.option.sandbox.enable_foo = True
mechanism
2) Would be glad to hear from wes on what he considers an acceptable
way to get new APIs in.

Cheers,
Yoval
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pandas-dev/attachments/20130407/57578d2c/attachment-0001.html>