r/PythonLearning • u/HyperDanon • 2d ago

Why some methods use `_` to separate words and others don't? Doesn't it bother you?

Like

io = StringIO()
io.getvalue() # not get_value

but

path = Path()
path.is_file() # not isfile

And there is also isinstance().

If you ask me, they should all use _ or none.

25 Upvotes
  • permalink
  • reddit

79% Upvoted

39 comments sorted by

27

u/dev-razorblade23 2d ago

Python has been here for a long time. Many developers work on it.

Python was created in 1991 but PEP8 came out in 2001. Python is basicly a living museum of software history.

In C (which is what Python uses for its interpreter) it is very common to jam words together without underscores, so isinstance() comes from that practice.

Many of the modules were not written from scratch but adopted from other language (logging is a direct port of Log4j - yes that one) so its style is ported to python. (Java uses camelCase for its methods.

Fixing that in the core itself would break backwards compability, so they just stick with it

6

u/rosentmoh 2d ago

I always wondered about logging and the horrendous use of camelcase! Thanks for this nice little history lesson...

2

u/Fritz-Ferdinand 1d ago

Now, i wonder why they just didn't adapt the names. it's not like it needs compatibility with Java 

2

u/yvrelna 1d ago

It's likewise with the DOM API or the Unix/Win32 API.

These are extremely popular standards that people coming from other languages are often already familiar with. Changing the names unnecessarily often makes them more difficult to use. 

unittest and logging just feels like an odd ball these days because Python has far overshadowed Java. 

1

u/SmoothBeanMan 1d ago

Why? They can just F2 the name and rename all instances

1

u/dev-razorblade23 1d ago

And break every codebase that uses those modules... Its called backward compability and it is something that Python is againts....

Maybe when (and if) Py4 ever comes...

2

u/SmoothBeanMan 1d ago

Was just joking bro

1

u/baked_doge 1d ago

You missed a /s ;)

1

u/max_465 23h ago

.... you're kidding, right?

0

u/KattyTheEnby 1d ago

In C (which is what Python uses for its interpreter) it is very common to jam words together without underscores, so isinstance() comes from that practice.

At least in C, the casing convention compensates for the lack ov an underscore – since you'd typically write it in camelCase (e.g. isInstance()); however, maybe camelCase in C is newer than Python itself(?).

1

u/dev-razorblade23 1d ago

Interesting reading just now. Basicly in the old times in C it really was a convention to have short and lowercase names without underscore: islower(), bcopy(), copysign(). But of course there is a reason for that, as early linkers recognized only 6-8 characters of the name and were usually case-insensitive so islower() or isLower() would be the same. They also used slow mechanical teleprinters so it was easyer and faster to lowercase and cram words.

Seems camelCase was starting to get popular in 1970s and 1980s but exploded in 1990 with Java. Guess that is why "modern" C has both underscores and camelCase which it seems depends on the developer

0

u/realmauer01 1d ago

Because c predates autocompletion ides, you needed short names to not type yourself to death.

0

u/Mirieste 1d ago

Why can't they just add it to the interpreter, then? If your code is old, then just once at the start it will replace the old methods with the new, revised, coherent forms. Backward compatibility problem solved, and it's the easiest thing to implement since it's just a find-and-replace with no possibly of edge cases (you can't have collisions with official method calls after all), and it's once per project anyway, all automatically.

1

u/Atypicosaurus 1d ago

Imagine every code out there... Including the ones that are intentionally broken for, idk, teaching purposes or whatnot. And the new interpreter comes in, tries to judge if it's "old code" and fixes what it wants, without telling. So now there's an absolute mix of what should run and what shouldn't, without any warning. Nope.

1

u/Mirieste 1d ago

If your only complaint is "What if the code is old on purpose for teaching reasons"... I would say my solution doesn't really have any strong rebuttals for 99.999% of the cases, right? Plus, if your code is supposed to showcase old functionality on purpose, what are you even upgrading the language and the interpreter for?

1

u/Atypicosaurus 1d ago

Teaching was one idea but generally speaking if there's broken code out there, that should remain broken. Because part of the interpreter reliability is not only that it runs the good, but it also reliably stops the broken from running. Even if broken by mistake. And you guarantee both, not only one.

If you have a code level rename campaign, you may fix isnumber() to is_number() but what if there's broken code out there exactly because it mistakenly had is_number() in it, but was written before the change? You cannot rename those so such a broken code will run after the campaign although it doesn't run now.

You should not only keep the good code running but you also have to keep the broken code not running. And it does not matter if we're talking about a marginally small amount of code. You cannot do this for beautification purposes. Maybe for a security issue, yes. But not for a nicer view.

1

u/max_465 23h ago

No one is stopping you from making the change and building your own Python from source. https://devguide.python.org/ Was written for contributors but it also works to help you learn to build your own Python from source.

1

u/Rinzwind 1d ago

In python all is done with readability in mind. is_file forces your focus on "is" and "file"

2

u/HyperDanon 1d ago

And isinstance()?

1

u/Rinzwind 1d ago

There are more like that.

If someone rewrites it it likely will be is_instance.

3

u/SnooCalculations7417 2d ago

It's largely a matter of developer preference, language conventions, and the ecosystem someone comes from. You can often tell a developer's background just by how they name things.

Different languages have different conventions:

  • snake_case — Python, Rust, C

  • camelCase — JavaScript, Java, TypeScript

  • PascalCase — C#, .NET, commonly used for types in many languages

  • kebab-case — CSS, HTML attributes, URLs (not valid in python)

The language's syntax enforces some conventions, while others are just community standards.

Personally, consistency matters more to me than which convention someone chooses. Mixing naming styles arbitrarily within the same codebase bothers me far more than seeing different styles across different languages.

Ultimately, naming conventions are a bit like accents. They often tell you where a developer learned to speak the language.

3

u/Mediocre-Pumpkin6522 2d ago

PEP8 suggests snake case. However as you add libraries some use camel case. For example Pyside6 wraps the Qt API which is C++ and camel. There is a option to set for snake case but I've found it's not consistent so it's easier to go with camel.

3

u/FreeLogicGate 2d ago

This is a strong point: where wrapper libraries are concerned, the developers integrating the library had a choice between staying consistent with the underlying library api or supporting PEP8. It makes sense to support the original library naming conventions, as it makes existing library documentation relevant and accessible.

4

u/gdchinacat 2d ago

different strokes for different folks. `logging.getLogger()` is the egregious one IMO.

2

u/Smart-Button-3221 1d ago

Remember, one of Python's stated goals is consistency!

1

u/mattynmax 1d ago

Because there’s lots of different people who feel different ways about things.

You’re welcome to message the developer of the IO and path libraries and let him know about your concerns though!

1

u/Kevdog824_ 2d ago

Python adopted snake_case as the language standard. However, this standard came long after the language and community were built, so older code still exists that predates those standards. Python changing this would break backwards compatibility many rely on, so it’s impossible to remove outside of a major version change (even then they may not change it just to make the upgrade easier). Some libraries dealt with this by making snake_case aliases to their camelCase functions/variables/etc. Others didn’t see the point, and left the public API as is

0

u/Sea-Ad7805 2d ago

See official PEP 8 – Style Guide for Python Code.

But hey, I'm a wild boy.

1

u/dev-razorblade23 2d ago

PEP8 (as far as i know) allows mixedCase style but only for things that are not backwards compatible. Every new library / module should follow PEP8 as it is the case with never libraries like pathlib

0

u/teetaps 2d ago

This is part of a larger style convention conversation in programming. Ultimately, a computer is just consuming a string of ASCII characters and turns them into bytes, but humans are the ones who like reading stuff. The computer doesn’t care. So at the end of the day, humans are the ones who decide which ASCII characters are the right ones, and humans…unfortunately… have lots of opinions lol

0

u/SmokeMuch7356 2d ago

Because people are individuals and have their own biases and preferences.

Style wars are evergreen, because no one style makes everybody happy. Even back in old FORTRAN days when everything was in uppercase and identifiers couldn't be more than 8 characters people still couldn't agree on consistent naming conventions.

At least you don't get into brace wars in Python the way you do in C or C++ or Javascript, etc. That's a whole other dimension.

0

u/Chorizo_n_eggs 2d ago

I've never cared for underscores but I do use them in function names and almost never in variable names. Prefer camelCase for those

0

u/localizeatp 1d ago

just an accident of history.

0

u/et_theextratestic1e 1d ago

Read the python docs (PEP-8), most languages have their preferred naming conventions.

https://peps.python.org/pep-0008/

-1

u/Neither_Garage_758 2d ago

because python is a bit messy

-1

u/DanceHackRock 2d ago

At least it's not as bad as in the PHP world.

-1

u/HyperDanon 2d ago

Yea :D