# Alternative call syntax

**URL:** <https://discuss.python.org/t/alternative-call-syntax/53126>\
**Category:** Ideas\
**Created:** [May 11, 2024, 10:17pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126 "2024-05-11T22:17:06Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 11, 2024, 10:17pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/1 "2024-05-11T22:17:06Z")

</div>

Is `X{...}` reserved for something? If it’s not we could use it for ` __alt_call__ ()`:

```python
class Foo:
    def __call__ (self):
        print("bar")

    def __alt_call__ (self):
        print("baz")

foo = Foo()
foo() # bar
foo{} # baz

```

---

<div class="post-metadata">

**Author:** ![da-woods](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/da-woods/32/7507_2.png) [@da-woods](https://discuss.python.org/u/da-woods)\
**Post date:** [May 11, 2024, 10:28pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/2 "2024-05-11T22:28:07Z")

</div>

Why do we want to be able to call and also `alt_call` something? That seems like the more important question before trying to decide a syntax.

---

<div class="post-metadata">

**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\
**Post date:** [May 11, 2024, 10:52pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/3 "2024-05-11T22:52:00Z")

</div>

Before asking if this could be done, did you stop to think whether it should be done?

---

<div class="post-metadata">

**Author:** ![gcewing](https://avatars.discourse-cdn.com/v4/letter/g/3d9bf3/32.png) [@gcewing](https://discuss.python.org/u/gcewing)\
**Post date:** [May 12, 2024, 2:42am UTC](https://discuss.python.org/t/alternative-call-syntax/53126/4 "2024-05-12T02:42:03Z")

</div>

Please don’t steal that syntax, I already have something in mind for  
it… details in a future post.

(And it’s something that couldn’t be implemented with a dunder method.)

---

<div class="post-metadata">

**Author:** ![ZeroIntensity](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zerointensity/32/10639_2.png) [@ZeroIntensity](https://discuss.python.org/u/ZeroIntensity)\
**Post date:** [May 12, 2024, 4:41am UTC](https://discuss.python.org/t/alternative-call-syntax/53126/5 "2024-05-12T04:41:04Z")

</div>

PEP 677 was rejected, why bother mentioning it?

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 5:28am UTC](https://discuss.python.org/t/alternative-call-syntax/53126/6 "2024-05-12T05:28:49Z")

</div>

> [@da-woods](#):
>
> Why do we want to be able to call and also `alt_call` something?

@MegaIng mentioned that it would increase the readability and customizability of DSLs within python.

I think it could also be interesting to have a sync and async method with the same name.

* * *

> [@gcewing](#):
>
> Please don’t steal that syntax, I already have something in mind for  
> it… details in a future post.

Frozen sets and dicts? Because I think these could be implemented like this as this currently raises a TypeError:

```python
foo = frozenset()
bar = {{1, 2, 3}} # TypeError: unhashable type: 'set'
baz = {{}} # TypeError: unhashable type: 'dict'
qux = {{1: "a", 2: "b", 3: "c"}} # TypeError: unhashable type: 'dict'

```

If you think that’s a better idea, I’ll discuss that instead.

* * *

> [@ZeroIntensity](#):
>
> PEP 677 was rejected, why bother mentioning it?

Well, when I think about it more, you would need a protocol anyway because it doesn’t make sense without both a ` __call__ ()` & ` __alt_call__ ()` method.

---

<div class="post-metadata">

**Author:** ![gcewing](https://avatars.discourse-cdn.com/v4/letter/g/3d9bf3/32.png) [@gcewing](https://discuss.python.org/u/gcewing)\
**Post date:** [May 12, 2024, 12:36pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/7 "2024-05-12T12:36:44Z")

</div>

No, it’s Something Completely Different.

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 12:40pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/8 "2024-05-12T12:40:42Z")

</div>

What do you think about the literal frozenset syntax?

---

<div class="post-metadata">

**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\
**Post date:** [May 12, 2024, 1:29pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/9 "2024-05-12T13:29:06Z")

</div>

Ugly busy-work.

I liked someone’s `f{1,2,3}` idea to denote frozensets better, but I so seldom have the need for them over sets and tuples (which can be used for frozen Counters) I’m not requesting that either.

---

<div class="post-metadata">

**Author:** ![gcewing](https://avatars.discourse-cdn.com/v4/letter/g/3d9bf3/32.png) [@gcewing](https://discuss.python.org/u/gcewing)\
**Post date:** [May 12, 2024, 1:30pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/10 "2024-05-12T13:30:29Z")

</div>

I don’t know, I haven’t thought of a good solution for that.

If I had my way, _all_ set literals would be frozen, and if you wanted a  
non-frozen set you would have to use set(). But it’s too late for that.

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 1:35pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/11 "2024-05-12T13:35:30Z")

</div>

If we don’t do that with a keyword, you wouldn’t be able to use `X{}` for anything else (as it wouldn’t work if you named your variable `f`). `{{1, 2, 3}}` doesn’t suffer from that problem.

---

<div class="post-metadata">

**Author:** ![JamesParrott](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/jamesparrott/32/10534_2.png) [@JamesParrott](https://discuss.python.org/u/JamesParrott)\
**Post date:** [May 12, 2024, 2:05pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/12 "2024-05-12T14:05:05Z")

</div>

Again, it’s busywork. It increases the cognitive load of every one who must read Python code, for little gain.

There’s no need to use `X{}` for anything else, any more than there is to find applications for every possible combination of parentheses and delimiters provided by Ascii (that hasn’t been used already).

Do you want to see `::`, `<name>` and `&var` in Python just because they currently are unused?

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 2:57pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/13 "2024-05-12T14:57:42Z")

</div>

My notation for frozen sets was already suggested in 2008, but got not response:

- [[Python-3000] Set literal](https://mail.python.org/pipermail/python-3000/2008-January/011844.html)

And Guido already rejected `f{1, 2, 3}` precisely for the reason I stated earlier:

- [[Python-3000] Set literal](https://mail.python.org/pipermail/python-3000/2008-January/011838.html)

---

<div class="post-metadata">

**Author:** ![MegaIng](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/megaing/32/16162_2.png) [@MegaIng](https://discuss.python.org/u/MegaIng)\
**Post date:** [May 12, 2024, 3:02pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/14 "2024-05-12T15:02:34Z")

</div>

> [@Nineteendo](#):
>
> @MegaIng mentioned that it would increase the readability and customizability of DSLs within python.

Yes, but I didn’t create a thread. Because I know that it will not be implemented. If you want a language that allows this syntax, look at nim. Python does not have DSLs as a design goal. In fact, quite the opposite: The idea of python is that it’s readable without having to know too much about the specifics of the usage context. Adding extra syntax to futher simplify this kind of stuff is not going to fly.

By creating this thread, you are just wasting time: Your own, mine, and everyone elses that looks at this thread.

You shouldn’t create #Ideas threads with the goal of having _something_ added by you. You are constantly creating threads. Find an idea you really, really want to be added to python, and for which you can find evidence that other python programmers (preferably a core dev) are at least open to it being added. And then **you** should be willing to spend a year on getting it implemented. That doesn’t necessarily mean implementing it yourself (although that would be much preferred), but at least you should argue for this idea and writing up a PEP. Constantly swapping ideas like you are currently doing is just creating noise with very little result except that others get annoyed.

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 3:38pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/15 "2024-05-12T15:38:42Z")

</div>

> [@MegaIng](#):
>
> The idea of python is that it’s readable without having to know too much about the specifics of the usage context.

Sorry, you didn’t mention this previously and I didn’t ask for clarification.

* * *

> [@MegaIng](#):
>
> Find an idea you really, really want to be added to python, and for which you can find evidence that other python programmers (preferably a core dev) are at least open to it being added.

As far as I can tell, the only thing worth discussing here are syntax changes. All the rest can just be put on PyPi. That makes it way harder to come up with good ideas.

I do have one idea that involves exposing an internal option I added for the C implementation of `normpath()`, but it could take up to July 10 before that pull request is accepted as I want to do it after another one.

I think frozen set literals and for all & any is something worth persuing, but I’ll have to do some research first.

* * *

> [@MegaIng](#):
>
> And then **you** should be willing to spend a year on getting it implemented. That doesn’t necessarily mean implementing it yourself (although that would be much preferred), but at least you should argue for this idea and writing up a PEP.

I’m happy to contribute on a PEP or to share crazy ideas how to implement it as I currently have no idea how to modify the syntax of Python.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [May 12, 2024, 4:04pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/16 "2024-05-12T16:04:06Z")

</div>

> [@Nineteendo](#):
>
> As far as I can tell, the only thing worth discussing here are syntax changes. All the rest can just be put on PyPi. That makes it way harder to come up with good ideas.

That’s not entirely true. Yes, library changes will get pushback of the form “why can’t this be on PyPI”, but that doesn’t mean they never get accepted. It just means the bar for acceptance is high (a lot higher than simply “I just had a good idea, what do you think?”). But the barrier for acceptance of syntax changes is _also_ high - probably even higher than library changes, notwithstanding the previous point.

The truth is, getting any sort of change into a widely used, mature language like Python is hard. At the moment, it feels like you are throwing ideas out to see which ones will stick. That simply isn’t a productive use of _anyone’s_ time. All you are doing, as has already been mentioned, is using up people’s patience with you to the point where you’re going to start getting ignored and your ideas dismissed.

Very few people have contributed ideas or features to Python without having already established themselves in the community. That means participating in discussions of _other_ people’s ideas, often simply by _listening_, and asking questions that demonstrate that you understand the things that commonly cause proposals to fail. Once you’ve established a reputation like that, then you might find that people are receptive to proposals from you - especially if you take on board all the experience you’ve gained watching how other people’s proposals have fared, and make your own proposal as good as you possibly can.

None of this is easy. Becoming a contributor to Python (even in a minor way) can take months, or even years, of involvement and reputation building. That’s not to say that new people aren’t welcome - far from it! But just because we welcome new voices doesn’t mean they get a free pass to waste people’s time as they learn. Start small, listen _far_ more than you speak, make what you say worth listening to, and you will get much further than you are doing with your current approach.

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 4:31pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/17 "2024-05-12T16:31:32Z")

</div>

> [@pf\_moore](#):
>
> Yes, library changes will get pushback of the form “why can’t this be on PyPI”, but that doesn’t mean they never get accepted.

I mean that right now it’s not worth discussing as they don’t have enough stars. Feel free to take a look at [ansio · PyPI](https://pypi.org/project/ansio).

* * *

> [@pf\_moore](#):
>
> the barrier for acceptance of syntax changes is _also_ high - probably even higher than library changes, notwithstanding the previous point.

At least I can get a useful response instead of “put it on PyPi”…

* * *

> [@pf\_moore](#):
>
> That means participating in discussions of _other_ people’s ideas, often simply by _listening_, and asking questions that demonstrate that you understand the things that commonly cause proposals to fail.

There just aren’t often suggestions posted that aren’t too technical. At least not as often as I would like. So there isn’t much to discuss.

---

<div class="post-metadata">

**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\
**Post date:** [May 12, 2024, 7:37pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/18 "2024-05-12T19:37:35Z")

</div>

> [@Nineteendo](#):
>
> Feel free to take a look at [ansio · PyPI](https://pypi.org/project/ansio).

I don’t see the point. We have `rich` and `curses`. This will never be something that’s going to be in the stdlib. Anyone who does find it useful can get it off PyPI.

Also, you should maybe re-think your goals. Are you interested in providing useful tools for others or in contributing to the core/stdlib? Because if you just want to make your code available to others, putting it onto PyPI is just as effective, if not more so, than getting it in the stdlib. You’ve done that with ansio - why do you think you need to do anything more? If what matters to you is getting to contribute to the core, then you might be better advised to start by helping out on the tracker, reviewing other peoples PRs, triaging issues, etc. That’s a well-understood path to becoming a core contributor, and there are people willing to mentor you on that path. But simply posting half-formed ideas here isn’t particularly helpful towards _either_ goal.

> [@Nineteendo](#):
>
> There just aren’t often suggestions posted that aren’t too technical. At least not as often as I would like. So there isn’t much to discuss.

That in itself tells you something. Specifically, that you need to learn more about how Python works in order to usefully engage in the discussions that are going on. And that shows in your proposals as well, you aren’t backing up your ideas with a discussion of how they would work in practice. I’m not saying you need to be able to implement them (although it would be nice!) but you _do_ need to be able to design and specify them to a good level of technical detail - and at the moment you simply aren’t.

Asi I say, spend more time _reading_ and _listening_ instead of talking. Read the discussions that feel too technical, and do some research until you start to understand them. Try to follow what people are saying, and do some background reading. You’ll make much more progress that way than simply trying to find ideas to post, to “see what people think”.

---

<div class="post-metadata">

**Author:** ![Nineteendo](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/nineteendo/32/19122_2.png) [@Nineteendo](https://discuss.python.org/u/Nineteendo)\
**Post date:** [May 12, 2024, 7:56pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/19 "2024-05-12T19:56:34Z")

</div>

> [@pf\_moore](#):
>
> I don’t see the point. We have `rich` and `curses`. This will never be something that’s going to be in the stdlib. Anyone who does find it useful can get it off PyPI.

As far as I can tell rich doesn’t support keyboard input. And at the moment it doesn’t restore the terminal back to its default settings when the program is terminated (which ansio does): [[BUG] Terminal settings aren't restored · Issue #3354 · Textualize/rich · GitHub](https://github.com/Textualize/rich/issues/3354)

See this thread for information about other libaries I tried:

> [@Cross platform keyboard input](https://discuss.python.org/t/cross-platform-keyboard-input/51979):
>
> I couldn’t find a cross platform library for keyboard input that doesn’t also need special priviliges: curses: doesn’t work on Windows and emposes arbitrary restrictions on output pip install keyboard: requires root on macOS, can’t be included with your code and acts like a keylogger on Windows pip install pynput: not trusted on macOS and can’t be included with your code So, I wrote my own, [AnsI/O](https://pypi.org/project/ansio), providing a low-level interface for input & output. Whenever the program is terminated or suspe…

Do you realise how much time I spent on this. ☹ Because I wanted to support Windows I had to write my own interface library from scratch and this is the second attempt (in the first one I implemented a complete file manager). Wrapper around ansio here: [GitHub - nineteendo/pyvz2 at alpha](https://github.com/nineteendo/pyvz2/tree/alpha)

* * *

> [@pf\_moore](#):
>
> Are you interested in providing useful tools for others or in contributing to the core/stdlib?

I mostly wrote this library for myself, I’m just sharing it because it might be useful for others. My main problem here is probably that `curses` isn’t available on Windows.

* * *

> [@pf\_moore](#):
>
> you _do_ need to be able to design and specify them to a good level of technical detail

See [for-all-any/README.md at main · nineteendo/for-all-any · GitHub](https://github.com/nineteendo/for-all-any/blob/main/README.md) for my work in progress on for all & any. How many ideas should I research?

---

<div class="post-metadata">

**Author:** ![ZeroIntensity](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/zerointensity/32/10639_2.png) [@ZeroIntensity](https://discuss.python.org/u/ZeroIntensity)\
**Post date:** [May 12, 2024, 10:35pm UTC](https://discuss.python.org/t/alternative-call-syntax/53126/20 "2024-05-12T22:35:34Z")

</div>

> [@Nineteendo](#):
>
> How many ideas should I research?

You should probably research all ideas to _some_ extent before creating a thread.

[Next page](https://discuss.python.org/t/alternative-call-syntax/53126.md?page=2)