Let me try to tackle tomorrow the problem of `Name...

# python-contributors

[Piotr Krzemiński]

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

[Piotr Krzemiński]

something urgent came up at work, I cannot work on it today 🙈 Sergei, if you like this problem, feel free to take it

[SerVB]

No problem!

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

[Piotr Krzemiński]

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 😅

[Piotr Krzemiński]

(shared my notes on wiki in case you have any thoughts)

[SerVB]

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

[Piotr Krzemiński]

Yeah, we'll need to sort out all this stuff related to self and inheritance :D

[Piotr Krzemiński]

FTR, a lot of interesting stuff happens in https://github.com/krzema12/kotlin-python/blob/python-backend/compiler/ir/backend.[…]g/jetbrains/kotlin/ir/backend/py/lower/SecondaryCtorLowering.kt

[SerVB]

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

[Piotr Krzemiński]

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

[SerVB]

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

[Piotr Krzemiński]

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

[Piotr Krzemiński]

I managed to design how the secondary constructors can be emulated, see Iteration 2: https://github.com/krzema12/kotlin-python/wiki/Notes-on-getting-rid-of-%22NameError:-name-'Object_create'-is-not-defined%22#iteration-2 . It's fairly simple and reuses a lot from JS. Python doesn't have secondary constructors, and the closest pythonic thing I found are class methods (@classmethod). Since we already have some JS lowering code, I'll give this path a shot. It's actually pretty similar to @classmethod, the difference is cosmetical.

[SerVB]

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

[Piotr Krzemiński]

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 👍

[Piotr Krzemiński]

I just checked the issue with editing lowering code - it works on my private laptop o.O so no need to check on your side, thanks!

[Piotr Krzemiński]

Almost got it working, I only need to solve one kind of regression. Python is weird, there's another syntax for calling base class's constructor and just a regular class's constructor. I need to deal with it and conditionally produce different code 🤷

[SerVB]

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

[Piotr Krzemiński]

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___

[Piotr Krzemiński]

More details in my draft PR: https://github.com/krzema12/kotlin-python/pull/37

[Piotr Krzemiński]

I'm not good at Python, so if you see a way to simplify it or make it right other way than I write, please let me know :)

[SerVB]

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?

[Piotr Krzemiński]

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

[SerVB]

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.

[Piotr Krzemiński]

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.