On Jan 4, 11:46 pm, Inyeol <inyeol....@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. -- http://mail.python.org/mailman/listinfo/python-list