On Wed, May 9, 2012 at 3:51 PM, Fernando Perez
<reply@reply.github.com>
wrote:
>> @@ -0,0 +1,23 @@
>> +/* We need an invisible input field on top of the sentense*/
>
> Well, I think the point is to consider common sense, even when it leads to a bit of variability: as pep8 also says ("A Foolish Consistency is the Hobgoblin of Little Minds"), it's important to be flexible with rules, and to know when it makes sense to break them.  Ithinkwecanallagreethattypingthiswayisnotagoodideaevenifitwouldmakeforveryconsistentposts.  Right?
>
> IPython used to have underscores and in 'the big refactor' I think all new files ended up without underscores.   I was so focused on moving forward with the work at the time, and we had so many bigger fish to fry, that I didn't want to worry about this issue at the time (perhaps I should have).  But I think it's important that we don't become slaves to prescriptive rules: pep8 was explicitly written for a multi-author open source project, and I think it's by and large a good balance of rules and common sense.

Here is my recollection of how we got to where we are with module
names.  During the big refactor of three summer's ago (wow, time
flies) we had a conversation about various code style issues.  I even
remember the room in my house I was in at the time.  In that
conversation, we agreed to go without underscores in our names for the
most part for consistency.  At the time we had much more of a mixed
bag of module names.  I was creating lots of new modules, moving
things around and renaming things and I needed some consistent way of
naming lots of things.  This is the solution that we came up with (for
better or worse) together.  Since then we have mostly followed this
pattern, with a few mostly random exceptions.

I bring this up because I don't feel like the current dominance of
names without underscores is something that I or anyone else slipped
by when you weren't looking.  In my mind, when I suggested renaming
this css file to not use underscores, I felt like I was simply stating
what our established policy has been for a few years.  I think the
lack of many names with underscores shows that this indeed has been
our policy for a while now.

> In my mind, a reasonable cutoff point is somewhere around 8 letters or so: anything longer than that can probably benefit a lot from a well-placed underscore, a very short two-word filename would be OK.

Given the above history, I believe this would constitute a significant
change in our file naming scheme.  Many of our current filenames
clearly don't follow this new rule and adopting this change would
produce confusion (why is it foo_bar.py here but powbam.py there?)
(when I import something from IPython, when is there underscores and
when are there not) etc.

> In summary: I can let this one go, but I won't let go of the notion that common sense should prevail over blind allegiance to rules.

I don't feel like I am blindly following some rule - just the policy
that we had decided on for IPython.  I am open to changing the policy
to something more underscore friendly, but we would need to come up
with something that is more clear than PEP8.  Something like you
suggest above (multiple words longer than 8-10 total letters = put
underscores between words) would indeed work.  We would also need to
figure out how to handle the many current non-conforming names this
policy change would create.

> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/ipython/ipython/pull/1658/files#r798622



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger@calpoly.edu and ellisonbg@gmail.com