Coding style change proposals

Gregory Szorc gregory.szorc at gmail.com
Sat May 13 22:21:04 EDT 2017


On Sat, May 13, 2017 at 4:27 PM, Phillip Cohen <phillip at phillip.io> wrote:

> +1 to #1, +2 to #2, +0.5 to #3.
>
> Excited about this progression of the codebase. Thanks for sending this
> out.
>
> I'd like to humbly suggest: classes in their own files, at least for
> important classes?


Until module loading in Python is ~0 cost, I don't think this is feasible
due to the overhead of loading modules.


> Or, if not that, perhaps some basic ordering rules
> for files, like that classes must come first? Some of our lengthier
> files feel like big soups of randomly ordered elements.
>

I could get behind some ordering here. Although there are exceptions to
every rule, such as a class referencing a function defined in the same
module. And vice versa. I'm not sure you'll come out significantly ahead of
"just split up modules when they get too large," which is something that's
been happening (debugcommands.py from commands.py, revsetlang.py from
revset.py, etc).


>
> On Sat, May 13, 2017 at 3:40 PM, Jun Wu <quark at fb.com> wrote:
> > Similar to smf, I think only the constant name change is worth
> considering.
> > Class and function name change are not practical - that will cause too
> much
> > pain for extensions without significant benefit (like perf etc).
> >
> > I think it's similar to Python 3 migration. Given the fact that Python3
> > migration causes us so much pain, we should probably learn the lesson
> and do
> > not make extension authors suffer.
> >
> > Excerpts from Gregory Szorc's message of 2017-05-13 14:41:34 -0700:
> >> I'd like to formally propose some changes to the code style in order to
> >> make the code more readable, similar to other Python projects, and more
> >> friendly to non-English speakers.
> >>
> >> I think each naming proposal below can be considered independently. So
> >> please don't wholesale reject this email because you don't agree with
> one
> >> part.
> >>
> >> Proposal 1: use underscores in names. Today, our names are
> >> "anamewithoutanypunctuation." I want to change that to
> >> "a_name_with_punctuation." This is vastly easier to read, especially for
> >> non-English speakers and is similar to how the rest of Python does it.
> >>
> >> Proposal 2: uppercase constants. Right now, constants are a mix of
> >> lowercase with some exceptions using uppercase. I'd like to standardize
> on
> >> using uppercase for all constants. Since Python doesn't really have the
> >> concept of constants, differentiating constants via naming helps
> reinforce
> >> that they are not regular, local scope variables. If I see mutation of
> an
> >> UPPERCASE variable when doing code review, that's a quick sign that
> >> something is wrong. It's harder to do that when the name is lowercase.
> >> Uppercase constants is how most of the Python universe does it.
> >>
> >> Proposal 3: CamelCase class names. Today, all names are lowercase except
> >> for error classes. I'd like to switch to CamelCase class names. This
> will
> >> help differentiate variables and functions from types, which improves
> >> readability. This is how most of the Python universe does things.
> >>
> >> If we adopt any of the proposals, a question becomes what to do about
> >> reformatting existing code. We can't easily do that because of API
> >> compatibility concerns. For internal names, we could certainly do that.
> But
> >> for public and more common APIs, we should be conservative so we don't
> >> break the world. I propose using the new style for new code and updating
> >> the style for old code when making significant changes. e.g. if you are
> >> rewriting a function, you would update names within first, then
> refactor.
> >> Or, you would refactor, updating names inline, and write a follow-up
> patch
> >> to clean up remaining names for consistency. This will result in mixed
> >> style throughout the code base, which is ugly. But I think we can manage
> >> until we're willing to take a mass API breakage hit.
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170513/27cd6ae6/attachment.html>


More information about the Mercurial-devel mailing list