for each his own. Any more word on userio?
On Sat, Jan 3, 2009 at 6:14 PM, Russ P. <russ.paie...@gmail.com> wrote: > On Jan 2, 10:50 pm, Ben Finney > <bignose+hates-s...@benfinney.id.au<bignose%2bhates-s...@benfinney.id.au> > > > wrote: > > s0s...@gmail.com writes: > > > On Jan 2, 7:20 pm, Ben Finney > > > <bignose+hates-s...@benfinney.id.au<bignose%2bhates-s...@benfinney.id.au> > > > > > wrote: > > > > They don't need to be creative; they merely need to conform with > > > > the naming scheme as laid out in the PEP. > > > > > If it's something to be included in the standard library, I agree > > > (just for consistency, not because using_underscores is better). > > > > > But for user code, I prefer mixedCase. > > > > That seems superficially like an easy distinction. Indeed, PEP 8 > > explicitly is meant to apply only to code intended for inclusion in > > the Python standard library. > > > > But consider: > > > > Python libraries generally don't get into the standard library until > > they've had a history of widespread public use as an external library. > > This helps ensure many of the harder-to-find wrinkles get discovered > > through wide exposure and ironed out before becoming standard. > > > > Code bases, especially library interfaces, that get a lot of use > > across wide communities are naturally going to have a whole lot of > > other people's code directly using those interfaces. > > > > Interfaces that are so widely used garner a high resistance to change, > > especially for something as non-functional as a naming convention. > > > > Choosing the naming convention for one's code is much easier to do > > when its usage base is smaller than when that base is larger. > > Therefore the easiest time to choose when to code in conformance to > > PEP 8 is right at the start. > > > > The best conclusion I can come to from this? Unless you explicitly > > *never* intend sharing your code with *anyone*, it's best to code all > > your Python code in accordance with PEP 8 anyway. You then don't have > > to make the decision about whether this is the time to follow PEP 8 or > > not; just do it by default, and you avoid the needless pain on those > > occasions, often unforeseeable at the start, where your code later > > ends up widely used. > > > > -- > > \ "One of the most important things you learn from the internet | > > `\ is that there is no 'them' out there. It's just an awful lot of | > > _o__) 'us'." —Douglas Adams | > > Ben Finney > > Fair enough, but for code that is not intended for general public > usage (i.e., most code) so-called camelCase is every bit as good if > not better than using underscores to divide variable names. It saves a > few characters, and in my opinion it's significantly easier to read. > Identifiers divided by underscores always appear to me at first glance > to be multiple words, and I find that very annoying. > > So unless you think the standard library will someday include code for > air traffic management, I'll stick with camelCase, and I'll thank you > for not making an issue of it. > > As far as I am concerned, this is one of the most important bits of > advice in PEP 8: > > A Foolish Consistency is the Hobgoblin of Little Minds > -- > http://mail.python.org/mailman/listinfo/python-list > -- А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
-- http://mail.python.org/mailman/listinfo/python-list
