Which coding style is better? public API or private method inside class definition

[DevPlayer]

On Jan 4, 11:46 pm, Inyeol <inyeol.... at gmail.com> wrote:
> Which coding style do you prefer? I'm more toward public API way,
> since it requires less code change if I refactor private data
> structure later.
> Plz give pros and cons of these.

Great question. It gets at the heart of Python style.
It's a tricky question and can be answered so many ways. I'm not a pro-
programmer anymore so here's my hobbyst's take on it.

First, API is application programming interface. Follow me for a sec.
It's the interface that your programmers use to use your "package".
But WHICH programmers? For large apps like game developers or large
all encompassing apps for companys there are many different types of
programmers. That helps determine how heavy to lean towards private
verse public interfaces.

Funny thing is I end up using the private interfaces as much as the
public interaces for certain things. For example when coding in
wxPython I rarely use any private apis (ie. __dict__ or other "special
or magic named" attributes). But when coding outside of wxPython I'm
all over the place defining new classes with special named attributes
like __new__ or __metaclass__, and lots and lots of other magic named
methods and private attributes.

So one way to decide whether to be coding towards more public verse
private is where in your project you are. Building infrastructure and
framework verse building "application" and end-user interfaces.

Or similarly the interface TO the API interface is private (as far as
Python considers things private that is). The interface to all others
to use your "package" is public.

And if your code is not a package for other coders, then what is the
sense in having private anythings?

One thing that mungles one's mind into thinking it matters is your IDE
tools. When you run your scripts as an end user, who cares that
there's tons of objects cluttering your namespace - I'm implying that
using private API in that case is somewhat a waste. When in your IDE
coding like PyCrust and you type in the interface something like wx.
you'll get a popup of "attributes" and you think "ah, these attributes
and methods I can use". But in use of that program, there's no sense
in hidding stuff with underscored names.

On the otherhand. I like to think my namespaces are simple, clean,
uncluttered. There's less "What the heck is that thing" while looking
at dir() and debugging.

Personally I do not like the underscore. My hands don't like the
keystroke pattern. And the underscore is butt ugly to me. Ugly does
not equal "less readable". I find underscore easier to read then camel
case/Hungarian Notation (wx and .NET has a lot of that). Although name
mangling and camel case usage are different things, from a visual (of
source code), to me they are the same. Also when there is name
mangling, there is often an unmangled version of it in some usage
somewhere in your code.

Another thought. Although private interfaces are not intended to be
SEEN, you code your private interfaces (i.e. attributes and methods,
functions, etc) to denote themselves as private when you LOOK at them
by using underscores. I'd rather have my source code just color
private attributes differently. However editors are not at that level
yet (meaning they'd have to interpret the code to know what's
private).

Lastly. Shouldn't it be better to use APIs based on the docs instead
of analyzing the code for intended public interfaces verse private
ones?

Although not explicidly listing pros and cons to public verse private
APIs I hope I spark some useful insight.