Alternative call syntax

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

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

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

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

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.

11 Likes

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

7 Likes

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.)

PEP 677 was rejected, why bother mentioning it?

@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.


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

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.


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.

No, it’s Something Completely Different.

1 Like

What do you think about the literal frozenset syntax?

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.

1 Like

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.

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.

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?

4 Likes

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

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

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.

14 Likes

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


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.


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.

1 Like

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.

19 Likes

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.


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


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.

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.

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”.

5 Likes

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

See this thread for information about other libaries I tried:

Do you realise how much time I spent on this. :frowning: 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


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.


See for-all-any/README.md at main · nineteendo/for-all-any · GitHub for my work in progress on for all & any. How many ideas should I research?

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