Next thing I'm going to work on is making `println...

# python-contributors

[Piotr Krzemiński]

Next thing I'm going to work on is making println("Hello world!") work 🙂 now there's some issue with property initialization, output is not defined. In JS version the initializer function is executed at the very end. Maybe we should get back to lazily initiated properties, so I'll try to rebase my still-as-draft PR from a month ago and see if it helps. @SerVB I remember some TODO from your recent PRs that could address this. Is it in scope that you worked on yesterday and didn't send to review yet?

[Piotr Krzemiński]

Asking because I don't want to interfere with what you work on, I can easily take some separate task :)

[SerVB]

I see in my merged PR with static fields something is changed around output field. From what I see now, it's still not working since this field is always None. Maybe it's that TODO that skips initial values, maybe something else.

I also see that those output classes contain some super calls that I'm going to fix.

Everything else seems not in the scope of my PR.

Well, if you ask me, I would say to support output we should learn how to mess up with stdlib. And then just remove this output field and classes for browser and nodejs, and make println call python's print. And regarding plain print, we could do it intrinsic for now just to convert its call to python's print(args, end="").

Something like that, sounds extremely cool and totally separated from my near tasks

[SerVB]

Another option is to shelve intrinsic stuff till optimization times. And for now just declare kotlin's print with JsName to avoid clash with python's print, but also to declare external python's print as private in stdlib and delegate calls to it

[Piotr Krzemiński]

I'm actually hoping to get something basic working from stdlib, that's why I didn't think about such short-term approaches :) I thought about println because it should be simple and would be useful in many other examples that we can prepare in the future. Equally tempting for me are collection functions like map or filter. Since the changes that you are working on may influence these, let me work on e. g. covering some missing translations first :)

[Piotr Krzemiński]

I'll take care of exceptions (simple throwing and catching). Seems pretty important and isolated from your topics 👍

[Piotr Krzemiński]

Darn, exceptions need class hierarchy as well 😅

[SerVB]

Oh... Should be solved by my PR.

Could you maybe postpone exceptions for a week.

Since the changes that you are working on may influence these

Well, if you start extracting our own stdlib-py instead of our current stdlib-js, it shouldn't collide with anything. Wdyt?

[Piotr Krzemiński]

I already started with simple ("shallow") translation of stuff from missing.txt, so that we somehow translate these instead of having "visit..." in the code. Stdlib-py is an interesting idea, it will require some research how the JS one is created, why each platform has its own, and so on 🤔