https://kotlinlang.org logo
#python-contributors
Title
# python-contributors
p

Piotr Krzemiński

09/16/2021, 8:29 PM
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
🆒 1
something urgent came up at work, I cannot work on it today 🙈 Sergei, if you like this problem, feel free to take it
s

SerVB

09/17/2021, 11:10 AM
No problem! I'm continuing with new testing. Feel free to work on that Object_create task when you are available
1
p

Piotr Krzemiński

09/18/2021, 7:43 PM
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 😅
💪 1
(shared my notes on wiki in case you have any thoughts)
s

SerVB

09/18/2021, 8:50 PM
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
p

Piotr Krzemiński

09/18/2021, 9:08 PM
Yeah, we'll need to sort out all this stuff related to
self
and inheritance :D
s

SerVB

09/21/2021, 11:50 AM
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...
p

Piotr Krzemiński

09/21/2021, 12:26 PM
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).
s

SerVB

09/21/2021, 12:36 PM
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
p

Piotr Krzemiński

09/21/2021, 12:49 PM
sounds cool, I tried very similar kind of change change (replacing some string that is visible in the output)
loading 1
👌 1
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.
🔥 1
s

SerVB

09/21/2021, 6:34 PM
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...
android dance 1
p

Piotr Krzemiński

09/21/2021, 6:38 PM
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 👍
👍 1
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!
👌 1
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 🤷
s

SerVB

09/27/2021, 4:58 PM
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...
p

Piotr Krzemiński

09/27/2021, 5:00 PM
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'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 :)
👌 1
s

SerVB

09/27/2021, 5:12 PM
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?
👍 1
p

Piotr Krzemiński

09/27/2021, 5:15 PM
Sure thing, with my message i didn't mean to put any pressure :) just shared my today's findings
🆒 1
s

SerVB

10/01/2021, 2:00 PM
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.
p

Piotr Krzemiński

10/02/2021, 7:08 AM
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.
💪 1
2 Views