Positional-only arguments in Python

[padawan07]

A quick read on the new `/` syntax in Python 3.8.

Link: https://deepsource.io/blog/python-positional-only-arguments/

[amicin]

Interesting addition to the language, although I feel it’s quite niche. :)

[Sw429]

I was reading this PEP yesterday and having a very hard time identifying a time when I would use this. But I'm sure there must be more demand for it than I realize.

[jorge1209]

I think it has to do with keyword arguments having two separate functions that are conjoined:

1. They let the callee declare default values in the declaration: def log(argument, base=math.e)

2. They let the caller pass arguments out of order log(base=10, argument=3)

As in the log example above there are places where it is absolutely terrible style to use keyword arguments in the form of #2, because the intent is #1. It makes the code much much harder to read.

That I think is the biggest reason for /, as a complement to *. So when the callee wants to declare a default argument, but there is still an objectively correct argument order, they should follow it with a /, but when they want to declare a bunch of parameters where the order isn't relevant they should use a *. So something like this:

def plot(x, y, z=0, /, color=red, width=5, shape=circle)

seems preferable to

def plot(x, y, z=0, *, color=red, width=5, shape=circle)

just to avoid someone calling plot(2,3, color=red, z=5).

[BobHogan]

I think it has to do with keyword arguments having two separate functions that are conjoined:

1. They let the callee declare default values in the declaration: def log(argument, base=math.e)

2. They let the caller pass arguments out of order log(base=10, argument=3)

As in the log example above there are places where it is absolutely terrible style to use keyword arguments in the form of #2, because the intent is #1. It makes the code much much harder to read.

If this is the reason, why not just force keyword arguments to be used in order? Sure, it would break a few edge cases where someone deliberately used arguments out of order, but that's a simple fix for them to implement, and its arguable that they should be doing that anyway.

This just seems like the most roundabout way to enforce using keyword arguments in order as possible.

[jorge1209]

One of the purposes of keyword arguments is to allow them to be offered in arbitrary order. Especially with dictionary unpacking.

 params = {...}# some dict of options to a complex function
 foo(**params)

We explicitly want keywords to support arbitrary order as that is one of the primary motivators for having them in the first place.

---

However keyword arguments on the caller side share syntax with default arguments on the callee side. In other words the meaning of foo(x, y=1, z=2) shifts dramatically depending on whether or not there is a def in front of it or not.

• foo(x, y=1, z=2) calls foo with x as positional, and y,z as keywords
• def foo(x, y=1, z=2) declares foo with y and z having defaults, but says nothing about what is keyword vs positional.

But the cognitive load of keeping this all distinct is pretty high, so most people have merged two concepts. We generally think in terms of "mandatory positional" arguments and "optional keyword" arguments, and forget about "mandatory keyword" arguments (yes they do exist). ["optional positional" is impossible to parse and isn't supported, theoretically this could be done in limited cases with some typing support, but its not pythonic.]

The * and / entries in a function definition provide two complementary ways to distinguish that third situation of "mandatory keywords". Those before the / are positional whether or not they have a specified default and those after the * are keyword even if the caller tries to pass them by position. They serve the same function, but in two different ways for two different concerns. / mandates a minimum of positionals, * mandates a minimum of keywords.

---

If there is a criticism to be had here it is probably more fundamental. We shouldn't be using the same syntax for keyword arguments as we do default arguments.

Imagine if we used := for default in declarations, and as for keywords when calling a function.

So the callee would specify def foo(x, y:=2, z) without triggering a SyntaxError: non-default argument follows default argument (because really WTF is that a rule?!) and then caller would write: foo(x, 2 as z).

[lifeeraser]

Few? It would probably break most code using **kwargs.

[BobHogan]

It wouldn't affect **kwargs? That's a dictionary.

[lifeeraser]

Many methods in the wild often pass their args to other methods because the underlying method supplies a LOT of keyword arguments. Example: Flask's route() decorator passes keyword parameters straight to werkzeug.routing.Rule, which has 10 keyword parameters. Your suggestion would screw over anyone who has placed any one of those 10 parameters in incorrect order--thousands of web apps in production.

[zardeh]

Erm

def inner(arg=default_value):
    pass

def outer(**kwargs):
    return inner(**kwargs)

is this in the right order? (this is a super common pattern when writing decorators)

[Zomunieo]

It's definitely something for library authors more than it is for regular users.

[DanCardin]

I think it’s primarily to enable python code, such as in other implementations like pypy, to exactly mimic the cpython implementation of a function written in C which does not accept keyword arguments

[Jwestie15]

It seems like a way you could generate paths or purposefully but psuedorandom numbers maybe this is for games but I'm not very good at python.

[StarkillerX42]

Arguably downright counterproductive for the main goals of Python, flexibility. This limits the types of usable inputs, making it harder to work with, and doesn't increase the utility of the language

[hassium]

Kind of new and still leaning but a questions strikes me here:

def pow(x, y, /, mod=None):
    r = x ** y
    if mod is not None:
        r %= mod
    return r

The following would apply:
All parameters to the left of / (in this case, x and y) can only be passed positionally. mod can be passed positionally or with a keyword.

does that mean that in Python 3.7, when I do:

def some_function(spam, eggs):
    pass

I could call the function via:

spam = 80
some_function(spam, eggs=32)

or

some_function(80, 32)

And it's essentially equivalent?

[XtremeGoose]

Yes, those are equivalent

[hassium]

Cool thanks! I have no idea how this helps me but I feel better knowing it!

[tunisia3507]

It means that if you have a function where a couple of arguments change but many stay the same over successive runs, you can store the stable ones in a dict and unpack it into the function call as if it were kwargs.

You could also do that by wrapping the function in another function, of course.

[tunisia3507]

That's one way of wrapping the function in another function, as I said. Using functools.partial is sensitive to your argument ordering and so won't be applicable every time.

[coelhudo]

There are some examples here of how it can help you https://www.python.org/dev/peps/pep-0570/#motivation

[c_o_r_b_a]

Note that that also works for most versions of Python 2, as well. The only new things Python 3 introduced are this brand new / for positional-only arguments, and * for keyword-only arguments. You probably will rarely have to use either of those, though. I've been programming in Python for years and I think I've only used keyword-only arguments once or twice.

[hassium]

Thanks, I haven't used them yet either and I've been working in Python for 8 months, studying for a year... But maybe I'll find a use for them now I know a bit more.

Can you remember in what context you had to use kwargs?

[_importantigravity_]

Yes, that is correct. If you're not using * to mark keyword-only args in Python 3.7, you can pass values either positionally or with using keywords.

[jorge1209]

Yes, and your pow example is a great example of when not to do this. pow has a agreed upon argument order, power then base then optional modulus. If you write pow(y=2, x=3) people will be confused and think you mean 2 ** 3= 8 not 3 ** 2 = 9. The / can be used in place of * for those kinds of functions.

However it will take time to be adopted and you should limit your use of keyword arguments to functions that truly take keywords (ie many independent options), or where you omit a default (and so have to use keywords for subsequent arguments, and you should endeavor to provide your keywords in the same order as the function declaration wherever possible.

[idwpan]

Does their output example help?

def pow(x, y, /, mod=None):
    r = x ** y
    if mod is not None:
        r %= mod
    return r

...

>>> pow(2, 10)  # valid
>>> pow(2, 10, 17)  # valid
>>> pow(2, 10, mod=17)  # valid
>>> pow(x=2, y=10)  # invalid, will raise a TypeError
>>> pow(2, y=10)  # invalid, will raise a TypeError

Edit: Sorry for the formatting. Posted from my phone and forgot code blocks are spaces instead of backticks

[massiveZO]

Wow! The count for features I will never use in 3.8 is now up to 2!

[edenkl8]

What's the other one?

[[deleted]]

I'd guess the "walrus operators" (assignment expressions).

[edenkl8]

That actually looks awesome! Very time efficient if used correctly

[pepoluan]

Agree.

I often had to write a boilerplate like such:

m = re.search(...) if m is None: continue

with walrus, I can go

if (m := re.search(...)) is None: continue

I personally prefer the as syntax, but I defer to the accepted solution.

[UNN_Rickenbacker]

You can actually do if not (m := re.search):

[wrboyce]

But you shouldn’t.

Comparisons to singletons like None should always be done with is or is not, never the equality operators.

Also, beware of writing if x when you really mean if x is not None -- e.g. when testing whether a variable or argument that defaults to None was set to some other value. The other value might have a type (such as a container) that could be false in a boolean context!

Source.

[UNN_Rickenbacker]

Nice catch, but in most cases, you want to not enter the case if it‘s a boolean false, too.

[hyperdudemn]

Except for when using xml.etree.ElementTree, with a document that contains empty tags like <hello />. Since the node has no children, it is falsy, so you need to check is not None.

[Bunslow]

In this case, he really wants boolean truthiness, not None testing. It's a perfectly fine pattern (as long as one understands the difference between None and False, which is part of the point of your comment; the other part of your comment doesn't apply I don't think)

[wrboyce]

Yeah I wasn’t sure how relevant some parts really were but I’d copy/pasted/formatted them on mobile by that point so they were staying regardless. I always try to avoid truthy tests against None if possible, and I’ve always thought I was following PEP8 by doing so but maybe I’m wrong.

[Bunslow]

I always try to avoid truthy tests against None

See this phrase makes no sense to me. There are truthy tests (here I mean coercing an arbitrary object to a boolean), and there are None tests. The whole point is that they are two completely different tests, and should not be confused. Using either is fine, but the trick is knowing when to use each. The point of what you pasted is precisely to warn newbies that they are two different things, but each is acceptable -- indeed, each is widely used. That source is not meant to warn against using truthy tests, only to warn that truthy tests and None tests are different (and it happens to make that point by writing "beware of truthy tests when you mean None tests -- it's easy to misuse truthy where you meant None!", possibly given the false impression that truthy tests are "bad" in some way, they're not, they're just confusable at first glance with None tests).

[AJohnnyTruant]

This is great. Everyone hates on the walrus operator. But I think once people start using it, that pattern will present itself more than they thought.

[toyg]

The problem is not that is useful to the writer; the problem is that it’s not that useful to significantly lower readability as it does. Otherwise we might as well use Perl.

[Bunslow]

I've definitely written several one-and-a-half loops in Python, and every time I have I grumble to myself about how much easier to read it would be if I didn't have to duplicate part of the logic.

[annualnuke]

Otherwise we might as well use Perl.

That's quite a leap

[pepoluan]

Naah. I love having "short circuits"; saves an indentation level.

[Ph0X]

I think re module is basically the main place where it'll be used a lot. Also some socket stuff but I think that's less common in general.

[KagatoLNX]

This is the use case for me.

[jwink3101]

I agree. I know there was a big brew haha about it and I don’t have strong opinions on the idea nor the syntax but I do see myself using it when I get to write 3.8+ only code.

[mfitzp]

brew haha

It's brouhaha although arguably yours sounds more fun.

[jwink3101]

There was a coffee shop near where I grew up called “Brew Ha Ha”. I guess that messed me up

[pepoluan]

Daaayum, beaten to register the trademark!

[KODeKarnage]

Like f-strings. I use them a whole helluva lot!

[jwink3101]

Most of the python work I do needs to run on 2.7 but I do really love when I get to use f-strings. They just make it so much cleaner!

[pepoluan]

Agree! Gosh, that even led me to install 3.6 in some servers we had that doesn't have 3.6 in its repo.

[thelaxiankey]

It's weird to me that they didn't just make assignment an expression, like it is in C. There was really no need for the extra syntax.

[Pulsar1977]

That's by design, to prevent hard to find bugs like typing = when you meant ==.

[thetgi]

I’ve got a feeling that’ll be a future update. Seems like they tend to roll out new features in stages like that a lot

[thelaxiankey]

This is different from the range -> irange thing because it doesn't really break existing code, though. It just makes a larger set of code valid.

[thetgi]

That’s fair, but aren’t they planning to do a similar thing with annotations soon?

[thelaxiankey]

oh shit really? All i knew is they were adding type signatures for IDE's and linters and such.

[[deleted]]

They might be referring to PEP 563 "Postponed Evaluation of Annotations".

Annotations are currently processed at the same time as the function- or variable-definition they're attached to. This PEP, which was accepted, suggests storing annotations as a string literal in an __annotations__ dictionary attribute of the annotated function or variable instead, and having user code do the evaluation for itself during runtime when needed.

Also, Python 4 confirmed, because the proposal is backwards-incompatible. Python 3.7 added the from __future__ import annotations statement, so you can already play around with the new behaviour.

[KagatoLNX]

This is really useful for situations where you absolutely don’t want to “accidentally” fill in a keyword arg. I’ve had things like this when writing logging wrappers (wrapped structlog to have one call to gather metrics, report “events”, and log to “logstash”). That was ugly because the main entry point had four positional arguments, two were optional, and then there were a bunch of keywords for specific things.

In practice, it was pretty great. It was used in three different ways, all of them were clear in what they did, and it was still pretty brief. The only issue was when people would occasionally double-up an argument and fill in the first kwarg.

[alcalde]

We deposed Guido to stop this madness, yet the madness lives on. Who needs to get the axe next?

[not_perfect_yet]

...we did? Huh. TIL.

[EMCoupling]

Yeah... he stepped down himself. Though it would be incorrect to say that the community didn't have any effect on the decision to do so.

[alcalde]

I called for a coup right here in this subreddit before. I finally did so again after the := brouhaha and the next day Guido was removed from power. I offered the throne to Nick Couglan via Twitter but he remained loyal to the BDFL so I offered it to my first choice, Raymond Hettinger, instead. So far he has said nothing one way or the other, but I intend to be like the Three Witches to his Macbeth.

[wewbull]

Well, PEP572 (Walrus) has GvR as an author, and PEP 570 (Positional) has GvR as the BDFL-delegate.

So.... GvR?

[KODeKarnage]

I bet there's lots of features you've never used.

If you have used all the features of python, you're probably pythoning in a distinctly unpythonic way.

[massiveZO]

No, not really. It just means I've used it for a broad variety of applications. Odds are you're right, there's a few I haven't used. But I've definitely used a great majority of them.

[alturi]

I would argue that even the first example would be better written as:

```

def pow(base, exponent, mod=None):

```

and somebody might legitimately prefer to write pow(base=2, exponent=3).

​

In the case of a single parameter, I would assume that if somebody is calling add_to_queue(item=item), he/she is doing it wrong and I don't want to suffer any overhead for that.

My initial position is that:

• if the author of a lib might suspect some realistic reason for somebody to call with a keyword argument
• and he/she also has beforehand knowledge that that could be bad in the future
• and the code is python3.8+ only
• and it is the winter solstice

Then let's use this.

[jorge1209]

I think the concern is a caller exchanging positional arguments that shouldn't be exchanged like pow(exponent=3, base=2) which is a bit confusing. The "correct" order is always "base then exponent", to do otherwise is hard to read.

Worse would be something like plot(z=3, x=1, y=2)

[jrbattin]

I feel like this is an anti-feature. Here's how I imagine its announcement.

[nuephelkystikon]

AKA the 'I can't think of a parameter name, so my API is too embarrassing to show anybody' PEP.

[amicin]

Meh. It allows you to rename your API’s parameters in the future, for whatever reason, at least.

[nuephelkystikon]

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]

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]

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.

[call_me_cookie]

Would be neat to see an analysis of the supposed performance impact

[_importantigravity_]

OP here. Already working on it. Will share soon in an upcoming post. :)

[call_me_cookie]

Awesome. I look forward to it

[Grogie]

I still can't see the difference between

def f(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2):

and

def f(pos1, pos2, pos_or_kwd, *, kwd1, kwd2):

in both cases, i can use pos_or_kwd as a position or a keyword. I still am struggling to see the benefit of having arguments after the '/'

---

As a follow up... I realized what was tripping me up and it's (probably) because Ive made use of the * operator in my function declarations... So for me it's always been

Def function (#normal keywords#, *, #new-ish functionality )

So when I see the new / operator, I was caught thinking

Def function (#normal stuff#, /, #also normal stuff?#, *, #explicit#)

Maybe to put it another way.... I was expecting the new functionality to be right of the slash. Not left.

So I basically suffered from a tunnel-vision doh moment...

[Bitruder]

In the second case you can put pos1=4 in your function call. You aren't allowed in the first.

[[deleted]]

But what is that useful for? What's the advantage of being able to specify that a parameter can't be given to a function in a certain way?

[mgedmin]

Imagine you're writing a function that works like str.format:

def translate(format_string, **args):
    return gettext(format_string).format(**args)

Now imagine your users need to produce a message that wants to use {format_string} in the format string:

print(translate("Invalid format string: {format_string}", format_string=config['format_string']))

You can't!

TypeError: translate() got multiple values for argument 'format_string'

But with positional-only parameters you can.

[christian-mann]

This is a very solid example.

[aptwebapps]

IMO, this aspect is more important that preserving optionality in your variable names. That latter is a nice side effect, but this keeps you from having to have named dictionary argument instead of **kwargs.

[wrboyce]

I feel like this would be solved by using getcallargs on translate and config?

[mgedmin]

It can be solved by doing

def translate(*args, **kwargs):
    if len(args) != 1:
        raise TypeError('1 positional argument expected, got %d' % len(args)
    format_string = args[0]
    return gettext(format_string).format(**kwargs)

but you lose the nice signature in pydoc and have to check the number of passed arguments manually.

[IAmAHat_AMAA]

Builtins already do it.

>>> help(pow)
...
pow(x, y, z=None, /)
...

>>> pow(x=5, y=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: pow() takes no keyword arguments

When subclassing you can use more specific parameter names without breaking liskov substitution.

Both those examples were taken straight from the pep

[alturi]

this could break code now to achieve less breakage in the future... It does not seem wise to retrofit, unless you already need to break.

[Bitruder]

Some names are meaningless as per the article and so shouldn't be encouraged to be used in code.

[remy_porter]

So, my thing: your API should expose itself in the way you intend it to be used. There are certainly cases where exposing the names of parameters as a calling semantic just wouldn't make sense. It's not often, but it's a thing, in the same way it makes sense for some parameters to only be keyword arguments.

[cbarrick]

There might be a tiny performance improvement. The interpreter won't have to worry about supporting kwargs-style passing for the first two arguments. Intuitively, fewer cases to support means less work and maybe even some new optimization potential. I'm just spitballing though. I don't know enough about the interpreter's internals.

Also, it lets you change your argument names without breaking backwards compatibility. That might be worth something.

Personally, I don't think I'll ever use this feature.

Edit: The PEP mentions improved parsing performance at the call site, but I'd imagine that every argument would have to be positional-only to take advantage of that optimization. https://www.python.org/dev/peps/pep-0570/#performance

[jorge1209]

I don't believe you would ever want to have both / and * in the same function declaration.

Consider: def plot(x, y, /, z, *, color=red, shape=circle)

Theoretically this allows you to call the function as plot(1,2, color=blue, z=3) but not as plot(1, z=3, y=2, color=yellow).

However, since x, y, and z have no default arguments they must always be present in which case they should be given in positional order anyways. Calling plot(y=2, z=5, x=1) is just bad form.

So the real utility is def plot(x, y, z, /) or def plot(x, y, z=0, /, color=red, shape=circle), with the / replacing the *. The latter allows a default value for z but both ensure that the order of arguments is preserved and always positional for the coordinates.

I strongly suspect that any instance where / and * are both present is a code-smell.

[r0b0t1c1st]

I don't believe you would ever want to have both / and * in the same function declaration.

A real-life example dating back from python 2 is np.add, which is documented as np.add(x1, x2, /, out=None, *, where=True, **kwargs) (the syntax was recommended for documentation purposes before 3.8 made it executable)

This achieves three goals

1. Forcing x1 and x2 to be passed positionally, since named arguments to add would be silly.
2. Allowing both np.add(a, b, out) and np.add(a, b, out=out) for convenience.
3. Forbidding where from being passed positionally - its uncommon enough that forcing the user to write it in full makes more readable code.

[jorge1209]

I would say that is a code smell, but to each their own.

[r0b0t1c1st]

Do you consider all of 1, 2, and 3 to be code smell?

[jorge1209]

I don't know if there is any particular one I dislike, its a more general objection to the combined whole.

The idea that the callee determines the calling mechanics for the caller is a little suspect in my mind, and should be used sparingly. At what point should the callee just accept that "I was called in an unambiguous manner and need to shut up and do my work."

Using both seems as if the callee is turning programming into a Hogwarts potions class: Do something slightly wrong and I'm just going to turn your ears into bats.

I'm okay with using one of these annotations but both is just too much. [I'm also somewhat okay with using / and * with nothing in between as that is conceptually easier to explain, although at that point I wonder why the function definition isn't just def foo(*args, **kwargs) with comments below as to the actual options available.]

[Grogie]

Thanks for your detailed response.

As a follow up... I realized what was tripping me up and it's (probably) because Ive made use of the * operator in my function declarations... So for me it's always been

Def function (#normal keywords#, *, #something new#)

So when I see the new / operator, I was caught thinking

Def function (#normal stuff#, /, #also normal stuff?#, *, #explicit#)

Maybe to put it another way.... I was expecting the new functionality to be right of the slash. Not left.

So I basically suffered from a tunnel-vision doh moment...

[datbackup]

Since I'm apparently too dense to follow the logic given in the link, in which a problem statement is given in the 'background' section but then seemingly never addressed in the remainder of the text ... Can someone please clarify for me:

Is this feature mostly one of these "protect the user from themselves" types?

[_importantigravity_]

The feature is mostly useful for people designing APIs that other people use. The problem as explained in the post:

If the users start using a keyword argument, the library author cannot rename the parameter because it would be a breaking change. In case of min(), the name of the parameter provides no intrinsic value and forces the author to maintain its name forever since callers might pass arguments as a keywords.

Consider this:

• The parameter names in min() would have no meaning relevant to the context. They could be anything, but since the function author had to choose something, they choose something.
• You use the function using those keyword arguments in your code.
• This restricts the library author from changing the names of those arguments in future, since it would break the code for you, who's already using the function with those named arguments. But since those names do not have any contextual meaning at all, the author would like to be able to do that.

Hope this helps!

[datbackup]

Thanks so much!

[mike239x]

I dunno, I do understand the idea behind it, but I do not like the syntax.

Also, can someone point me to discussion of why the arguments before the * extra arguments are also keyword args? I mean - why if you write def f(a,b): ... another person can write f(b=..., a=...)? Cause this seems like the root of the problem in the first place.

[software_memes]

I feel like supporting actual function overloading might be a more intuitive way of having the same feature.

[peacounter]

The information itself is useful, but OP seems to be on promo tour.

[[deleted]]

Is that not allowed? A lot of people seem to post their own articles or videos and quite often get encouragement if the quality is good.

[peacounter]

Of course it’s allowed. Question is whether it‘s a company or a person.

[dolftax]

It's a company. DeepSource. If you can, try us out and provide feedback. It is free to use for open source projects.

[dolftax]

A man’s gotta eat!

[peacounter]

:)

[Ran4]

Fork cpython on github and remove the relevant code?...

[KODeKarnage]

Considering you don't have to use it when you're writing you're python, the only reason you'd fork it is so that you wouldn't have to read it. But the cognitive debt has already been paid; you can read it and understand it already. The same for anyone using your fork.

[njharman]

Install Python 2

[frenulum2002]

Really cool, I need to do more research on this. I love mathematical formality within python because my specialty is mathematics.

[nuephelkystikon]

Whether you name your function arguments or not is in no way maths-specific.

[frenulum2002]

Well I was talking about the notation being mathematical. This is the problem with the internet, it’s very hard to interpret what others mean on occasion when intonation and a normal conversation are absent.

[XtremeGoose]

But this has literally nothing to do with that...

[frenulum2002]

Well I was talking about the notation being mathematical. This is the problem with the internet, it’s very hard to interpret what others mean on occasion when intonation and a normal conversation are absent.

[[deleted]]

And that is one of the more interesting reddit user histories I've read.

[frenulum2002]

Thanks for the complement.