Even if I learned things from your answer, I think you misunderstood what I was talking about. :p
What I want is a mechanism to describe python’s objects from Pharo and being able to: 1. Serialise those objects from Python 2. Send those object to Pharo (whatever the way it is done: socket, write in a file from python and read from Pharo, etc…) 3. Materialize those serialised Python’s objects as Pharo objects. Basically, I want to be able to transfer data from Python to Pharo easily. Something better than getting the values held by Python objects by parsing their String representation « by hand »... :-) Julien --- Julien Delplanque Doctorant à l’Université de Lille 1 http://juliendelplanque.be/phd.html Equipe Rmod, Inria Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq Numéro de téléphone: +333 59 35 86 40 > Le 10 janv. 2018 à 16:43, Dimitris Chloupis <kilon.al...@gmail.com> a écrit : > > > > On Mon, Jan 8, 2018 at 5:50 PM Julien <julien.delplan...@inria.fr > <mailto:julien.delplan...@inria.fr>> wrote: > Beware that no mechanism to get back values from Python is defined for now > (except if you just want the String > representation of those objects, then you can get that if you use atlas). > > I’d like to have that but it is not easy. I would like a way to describe how > to map Python’s objects to Pharo’s objects > from Pharo and to have the code to do that in Python side generated > automatically but some thinking is needed… > > Julien > > It won't be easy > > I have noted in the past the similarities between Pharo and Python but here > there is also a massive difference. > > In Pharo we have the mentality of reinventing many stuffs ourselves so the > systems is based to a very large extend on Pharo that runs on very efficient > JIT VM. Almost everything is Pharo code. > > Python on the other hand is the exact opposite, Python runs on an extremely > slow VM but more than 50% of its code in written in C, Python itself or its > third party libraries. > > So the irony is that even though in theory and practice Python code is one of > the slowest , in actual scenarios its one of the fastest able to outperform > even Java to a very large extend because its libraries that are made for high > performance like Numpy are predominately C code. Pretty much every C or C++ > library has wrappers for Python which is what made it so popular. Hence the > reason behind the insanity when it comes to top performance Python being > second only to C++. > > So you will have not only map the Python oobjects to Pharo object but also > map the C code. Even though this may sound impossible the good news is that > Python libraries, having the extension pyd , are basically DLLs made > supporting a specific API which is very minimal in design. Similar to our > UFFI , the only major difference is that library is responsible of keeping > track of the reference count, which is used by Python GC to erase no longer > used objects from memory. Which is a very simple increase and decrease. > > So not only you will have to remap the Python objects but also DLLs as well. > > To add salt to the wound , Python has something that Pharo does not. Multiple > inheritance. Which of course makes your goal even harder. Python coder's > generally avoid multiple inheritance as much as we avoid overriding > doesNotUnderstand , but its a feature they use none the less. > > Hence why I did not even consider trying something like that. Plus you will > be gaining no advantage because C code is unportable to Pharo anyway. Sure we > have Slang , but Slang is extra careful with types which normal Pharo code > does not. You will be losing performance because yes porting to Pharo as much > as JIT VM may be great , its no much for Python libraries that merely > leverage C. Plus you will have to update it each time the library changes > etc. > > So my conclusion was that the most efficient way was to let Python execute > the library and just manipulate Python. > > It's much easier to do the exact opposite, which goes against our mentality , > and port your Pharo objects to Python objects. Because a) your objects will > always be far less than a complete library and system b) you wont have to > worry about C code because you wont have any c) all the other negatives I > mention , disappear. > > It usual case of not being able to have your cake and eat it too. >
