Let me try to tackle tomorrow the problem of

NameError: name 'Object_create' is not defined

, it's top 1 of box tests failure reasons

No problem! I'm continuing with new testing. Feel free to work on that Object_create task when you are available

I dug a bit deeper deeper and the

Object_create

issue reaches as deep as to the standard library: https://github.com/krzema12/kotlin-python/wiki/Notes-on-getting-rid-of-%22NameError:-name-'Object_create'-is-not-defined%22 I guess next time I'll start learning how the stdlib for JS is created and how one should look for Python 😅

in function, if

self

is not known, remove it from any calls

This is not that simple I guess... In general case, this means our code doesn't use the correct parameter name. Here, for example,

self

is hardcoded: https://github.com/krzema12/kotlin-python/blob/7661c014451b1f2bd4eb6e1302b81df8a96[…]nd/py/transformers/irToPy/IrElementToPyExpressionTransformer.kt

Yeah, we'll need to sort out all this stuff related to

self

and inheritance :D

Nice research! I almost haven't taken a look into lowerings; my focus is on the final ir2py for some reason. AFAIR I've only disabled some lowerings...

the time has come to look at them 🤣 I mean, some them work fine for Python, but some of the like here are too JS-specific and they simply need adjusting. I'll take care of it next time I have a chance. Today I wanted to try out some idea, so I modified the code in the above file, but it wasn't reflected in the out_ir.py 🤔 I'd be grateful if you could check on your side if you see the same (not urgent).

Sure, I can take a look on Friday. Is there any specific kind of change you want me to try? I can, for example, try to change the generated function name: SecondaryCtorLowering.kt#L174

sounds cool, I tried very similar kind of change change (replacing some string that is visible in the output)

Thanks, now I understand the problems we have now. We can postpone

@classmethod

for a bit later, right? We can now use just those global functions generated already, but need to adjust them. Also, it seems we can get rid of

*_Init_

functions and use only

*_Create_

ones. The need of

*_Init_

ones seem to be caused by JS specifics, IIUC. --- By the way, also there is

mask0 & 2 == 0

stuff – it's probably because there is a lowering that changes default arguments to this. In Python, we can try using Python's native default args, but I doubt we need to handle it now...

True, everything what you wrote makes sense :D I'll try to solve it with least effort first and we'll see if it's enough for now 👍

Python is weird, there's another syntax for calling base class's constructor and just a regular class's constructor

Interesting: could you show an example or clarify it please? For now, I guess it's the same in Kotlin: we call a constructor of a base class via

: super(args)

, but a regular object creation is

ClassName(args)

. Maybe you are talking about something else...

A.__init__(self, someArg)

vs

A(someArg)

. From the perspective of IR, both are constructor calls, but we need to produce the right form of Python depending on the context. The first one should be used if called from within another

___init___

No problem. I need some time to think, though... Your PR isn't trivial for me, remembering that it's the end of a working day 😅 Don't you mind if I postpone it to Friday?

Sure thing, with my message i didn't mean to put any pressure :) just shared my today's findings

Hey Piotr, I have taken a look. I've caught a compilation crash, written about it in the PR.

A.__init__(self, someArg)

vs

A(someArg)

.

From the perspective of IR, both are constructor calls, but we need to

produce the right form of Python depending on the context. The first one

should be used if called from within another

___init___

I guess the first one is

DelegatingConstructorCall

and the last one is just

ConstructorCall

(tell me if I'm wrong, I'll think again). AFAIU we have

DelegatingConstructorCall

in both places so we compile both places identically and this is our problem. Two ideas how we can solve this problem: 1. I see in

SecondaryConstructorLowering.generateInitBody

there is

transformChildrenVoid

call, maybe we can add one more transformer in this lowering that will transform

DelegatingConstructorCall

to

ConstructorCall

? This way, it will be compiled without

___init___

later. 2. Maybe there is different

expression.origin

in

IrElementToPyExpressionTransformer.visitDelegatingConstructorCall

, so we can use a condition to understand how to compile:

A.__init__(self, someArg)

or

A(someArg)

. Other ideas would be to take a look at other lowerings, for example: 3. maybe

ES6ConstructorLowering

can help us (or if it's not needed for us, it's a good moment to remove this JS stuff 😅). 4. maybe initial IR clearly differentiates between

DelegatingConstructorCall

and

ConstructorCall

but some lowering is called before

SecondaryConstructorLowering

and transforms

ConstructorCall

to

DelegatingConstructorCall

, maybe if there is such place, it needs to be adjusted.

Thanks a lot for your insights! I already checked idea #2 last week and it didn't lead me to anything - the origin wasn't different in a way that would help (unless I overlooked something). I think I'll go with idea #4, that is: checking the pre-lowerings IR. Long-term, it makes sense to understand stuff from the beginning rather than patching existing JS lowering.