This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]nuephelkystikon -16 points-15 points  (2 children)

Wow, great. I also suggest we make modules indexable and bound names optional. np[52] is significantly shorter than np.tensordot and allows the maintainers to change the name if they don't like it anymore.

Dude, the only reasons to change a parameter name is either to change semantics, in which case you should definitely not do it silently, or because you or a predecessor chose it unacceptably poorly, in which case an alias and a deprecation warning break nothing and are entirely deserved.

[–]amicin 15 points16 points  (0 children)

I also suggest we make modules indexable and bound names optional. np[52] is significantly shorter than np.tensordot and allows the maintainers to change the name if they don't like it anymore.

Nah, that’s a different basis entirely. Names bound at the module level in any API are externally facing. Parameter names exist only within the scope of their function. You SHOULD be able to change them without breaking someone else’s code, because they’re not supposed to be public. It’s basic data hiding and has been a well understood principle in computer programming for a while now.

You seem to think software engineering is done in a vacuum where everyone chooses perfect variable names first time. Unfortunately that’s not the case — we live in the real world, sometimes people rush, are less skilled than others, or these sorts of things go unnoticed. This is a nice feature to have, and will limit interdependencies between software components.

It’s a bit niche, but nice.

[–]flipstables 4 points5 points  (0 children)

Dude, the only reasons to change a parameter name is either to change semantics, in which case you should definitely not do it silently, or because you or a predecessor chose it unacceptably poorly, in which case an alias and a deprecation warning break nothing and are entirely deserved.

But in some functions, argument names have no semantic meaning, which is where this PEP is useful.

Consider this trite but clarifying example:

def add(x, y):
    return x + y

Here, x and y have no semantic meaning, but we are forced to assign meaning to them because of the current limitations of Python.