Noob question: Is all this typecasting normal?

[alex goretoy]

for each his own.

Any more word on userio?

On Sat, Jan 3, 2009 at 6:14 PM, Russ P. <Russ.Paielli at gmail.com> wrote:

> On Jan 2, 10:50 pm, Ben Finney <bignose+hates-s... at benfinney.id.au<bignose%2Bhates-s... at benfinney.id.au>
> >
> wrote:
> > s0s... at gmail.com writes:
> > > On Jan 2, 7:20 pm, Ben Finney <bignose+hates-s... at benfinney.id.au<bignose%2Bhates-s... at 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
>



-- 
А-Б-В-Г-Д-Е-Ё-Ж-З-И-Й-К-Л-М-Н-О-П-Р-С-Т-У-Ф-Х-Ц-Ч-Ш-Щ-Ъ-Ы-Ь-Э-Ю-Я
а-б-в-г-д-е-ё-ж-з-и-й-к-л-м-н-о-п-р-с-т-у-ф-х-ц-ч-ш-щ-ъ-ы-ь-э-ю-я
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090103/6e2df617/attachment-0001.html>