Python style guide

With the arrival of Hops for GrassHopper ther’s gonna be a whole lotta Python on this forum in coming years so here are some words to the wise…

See also the full PEP8 style guide or just import this

6 Likes

I wonder if it’s just me, but I’ve always found PEP8 function/variable naming in direct conflict with the Zen of Python. Where subjectively I find underscores ugly and hard to read (i.e. compared to mixedCase). And objectively they are needlessly complex (in that they add unnecessary symbols), while also adding syntactical ambiguity (in that leading and trailing underscores carry actual function, while separators do not).

1 Like

I think to really get the zen of Python you need to read the source code of the this module, which contradicts all the guidlines in a massive kludge of meaningless (but functional) garbage :smiley:

2 Likes

That’s genuinely hilarious, never actually did inspect that module :exploding_head:

I guess it mainly comes down to what you’re accustomed to or where you come from programming-wise. When I started programming with Python a few years back, I wasn’t even aware of this notation debate. I simply went with the underscores.
I guess many people here, who constantly read the rhinocommon API are simply conditioned to see the C# notation style.
I started with Python before I even new about Rhino or Grasshopper, and wasn’t really much confronted with that style. I wasn’t doing much “serious” programming then either.

When I started getting into C++ about a year ago now, I was baffled that even here notation with underscores is very common, and that Python may have inherited this, since it’s a C-descendant right. I might be wrong about this, confirmation bias and such! :wink:

There is a validity in a language being specific about a preferred notation style, if only for readabilitie’s sake, and readability is a very subjective thing, as you noted.
I think the debate is superfluous, since when you learn French or any other language, you also try to submit to it’s rule set, orthography, etc. You wouldn’t start to capitalise nouns only because you are accustomed to that from your mother tongue. You kinda try to go with the flow of what’s been established before! Otherwise, you are probably going to run into communication troubles or worse down the line.

Now Python is still rather young and dynamically shaped, but I guess the underscores are here to stay. :slight_smile:

2 Likes

Indeed, it’s fascinating to track how programming languages evolve and inherit syntax etc. And just for the record, I have no issue with using whatever naming convention one prefer (or is enforced by). That said, I will totally die on “lower_case_with_underscores conflicts with Zen of Python”-hill :man_farmer:

Edit: I guess it’s called snake_case now. Which ironically seems to originate from the Ruby community.

2 Likes

My strongly held view about the zen of python was that complex is better than complicated meant you should choose a shorter synonym where possible / reasonable. Reading the thread leading up to Tim Peters’ first posting of the poem I realise that the discussion really does centre around code complexity vs ease / complication of reading. I was wrong :smiley:

30 years old this month - I guess young is subjective too :slight_smile:

2 Likes

I wasn’t trying to incite that. I was just giving my two cents, since I feel like this is an interesting topic. LOL, snake_case!! :smiley: Thanks for pointing that out.

Haha, yes, that’s my view on it too! Using underscores or any other kind of notation, what it mainly comes down to is being brief, concise, but precise.
For instance, get_unsigned_distance_to_plane_from_point(plane, point) is totally bloated, in snake or camel case. But it usually takes a huge amount of experience in the concerned language and API that you are working in, to get for instance abbreviations right, meaning that they can still be understood at least by people that work within the same ecosystem or even by yourself, if you come back to a project after a couple of weeks or even months.

Absolutely, I feel like thirty is still young, even for a programming lingo. Assembly is about 80 years old I believe. :wink:

2 Likes

More like 70 give or take. Before that it was actual machine opcodes.

I coded a simple opcode computer last year in Python for advent of code. Glad I don’t have to program like that in Rhino :slight_smile:

1 Like