Noob question: Is all this typecasting normal?

[Russ P.]

On Jan 2, 10:50 pm, Ben Finney <bignose+hates-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>
> > 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