>
> Le 5 janv. 2018 à 17:15, Dimitris Chloupis <kilon.al...@gmail.com> a écrit :
>
>
>
>
> Python3Generator allows to generate a Python 3 AST programatically. So
> basically you have objects that represent Python 3 AST nodes and some
> messages in top of that to make the generation of the AST easier from Pharo.
>
> E.g.
>
> ast := 'print' asP3GIdentifier callWith: #('Hello world').
>
> ast inspect
>
> yes buy why ? Why you want to generate objects , Python AST nodes are already
> python objects and you already generate AST nodes each time you execute
> python code.
>
> Using the Atlas syntax your above example would be simpler
>
> py = ATLPyParser new
>
> py print:'("Hello World")'
>
> Is there an advantage using your own syntax ? Is there any advantage of
> direct access to Python AST?
In MatplotLibBridge I do some checking/optimisations on the AST generated by
high-level API objects (e.g. for optimisation avoid importing a package twice).
With an AST it is easy with basic Atlas I think this is not possible. Having an
AST allow to do stuff on the code to execute before executing it and this easily
and maintainable (i.e. not using regexes).
>
> <Capture d’écran 2018-01-05 à 13.06.41.png>
>
> If you have a look at the readme on GitHub you will see more complexe
> examples.
>
>
> Yes I did take a look but I still did not know why you bother generating
> identifiers for each python command manually when ATLPyParser does this
> automatically for you.
>
> For example you have this example
>
> "Use and initialize the FFI interpreter."
> P3GInterpreter useFFIInterpreter.
> P3GInterpreter current pathToPython: '/usr/bin/python3'.
>
> instr := P3GInstructionsList new.
>
> json := 'json' asP3GIdentifier.
> file := 'file' asP3GIdentifier.
> os := 'os' asP3GIdentifier.
>
> instr addAll: {
> json import.
> os import.
> file <- ('open' asP3GIdentifier callWith: #('/tmp/osp3g.json' 'w')).
> (file=>#write) callWith: { (json=>#dumps) callWith: {{
> 'os' -> (os=>#name).
> 'uname' -> (os=>#uname) call
> } asDictionary} }.
> ((file=>#close) call)
> }.
>
> instr execute.
>
> Using the ATLPyParser of Atlas would have been much simpler
>
> py = ATLPyParser
>
> Atlas sendMessage:'import json,os'
>
> py
> file:'= open("/tmp/osp3.json","w")';e;
> file write:'(json.dump({"os":os.name <http://os.name/>,"uname":os.uname}))';e;
> file close;e.
>
> Or the point is to fully parse pharo syntax to python ?
What I would like to experiment for fun is translating Pharo Smalltalk to
Python 3.
And as said before with your technique you can not modify the AST easily before
sending it to Python.
>
>
> I wanted that to avoid the user having to set up a Python server listening on
> a socket when it is not needed to get data from Python.
>
> Yep, but if I want to get value from Python into Pharo, I want to have them
> as Pharo objects so as you said some conversion has to be made which means
> more work.
>
> Actually the server is setup at Pharo side, Python side is merely a client.
> All the heavy lifting is taking place via Pharo. The user does not need to do
> anything , its automatic. But yeah if you want to completely liberate
> yourself from sockets I can understand that, though I do not understand why,
> you use sockets every time you access the internet and they are really fast.
> So its not as if you can avoid socket generation.
I agree that sockets are not costly but a problem I see with them is that it
creates a *huge* security issue by letting anyone execute arbitrary Python code
from the outside (except if you configured atlas to only accept connections
from 127.0.0.1). Since I do not need socket to execute arbitrary code I prefer
not using them.
