Magic function

[Michael Tobis]

On Jan 11, 8:40 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:

> Read the OP's post again. His (her?) users aren't expected to create the
> toolkit, merely to use it. To create good toolkits you need both a master
> programmer and an expert in the field. It is an advantage if they are the
> same person. But to use such a good toolkit, you shouldn't need to be a
> master programmer.

It appears we are in agreement, then.

But that leaves me in a position where I can't understand your
complaint. There's no reason I can see for the sort of compromise you
ask for.

Clean abstractions benefit from their cleanliness.

Of course the users will have a lot to learn regardless, but that's
the point. A user has to decide whether to take on a new tool.

If that learning is about meaningless incantations (the way beginning
programmers are currently taught to say "abracadabra public static
void main") users will be less impressed with the advantage of the
abstractions and be less likely to engage the new methods on offer. If
the learning exposes new potential, that makes your tool more
attractive.

What's more, the next higher layer of abstraction will be easier to
compose if the composer of that abstraction doesn't have to make the
sort of compromise you suggest. Abstractions that stay out of the way
until you need to expand on them is a big part of what Python is all
about.

It's not clear that this is the sort of application where cutting
corners makes sense, so I don't see how your advice is justified.

mt