Piotr Krzemiński
09/16/2021, 8:29 PMNameError: name 'Object_create' is not defined
, it's top 1 of box tests failure reasonsSerVB
09/17/2021, 11:10 AMPiotr Krzemiński
09/18/2021, 7:43 PMObject_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 😅SerVB
09/18/2021, 8:50 PMin function, ifThis is not that simple I guess... In general case, this means our code doesn't use the correct parameter name. Here, for example,is not known, remove it from any callsself
self
is hardcoded: https://github.com/krzema12/kotlin-python/blob/7661c014451b1f2bd4eb6e1302b81df8a96[…]nd/py/transformers/irToPy/IrElementToPyExpressionTransformer.ktPiotr Krzemiński
09/18/2021, 9:08 PMself
and inheritance :DSerVB
09/21/2021, 11:50 AMPiotr Krzemiński
09/21/2021, 12:26 PMSerVB
09/21/2021, 12:36 PMPiotr Krzemiński
09/21/2021, 12:49 PM@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
09/21/2021, 6:34 PM@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
09/21/2021, 6:38 PMSerVB
09/27/2021, 4:58 PMPython is weird, there's another syntax for calling base class's constructor and just a regular class's constructorInteresting: 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
09/27/2021, 5:00 PMA.__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___
SerVB
09/27/2021, 5:12 PMPiotr Krzemiński
09/27/2021, 5:15 PMSerVB
10/01/2021, 2:00 PMvsA.__init__(self, someArg)
.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 anotherI guess the first one is___init___
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
10/02/2021, 7:08 AM