> This is what Smalltalk gives you for free. > Sorrry for being rude but I wll use the two usually heavily annoying word, at least for me :D
It depends See there is a problem for Python here. Ideology. The zen of python has been both a joke a serious mantra in the python world . Its a joke because its obviously oversimplify decision making in such a complex subject as language designe but is serious because it clearly illustrates the philosophy of its creator, Guido van Rossum. https://www.python.org/dev/peps/pep-0020/ Guido is not any less of a rock star to Pythoners than Alan Kay is for Smalltalkers. The zen has become so popular that is even included in python implementation and can be fetched as the link says using the "import this" in any implementation of Python. It's the very sould of python as messages and objects are the very soul of Smalltalk. So the problem here is that a live coding enviroment brakes the second rule. "explicit is better than implicit". Because live coding in Pharo and Smaltalk is about replacing old instances with new while keeping the state it non the less an implicit behavior and especially become is a no go scenario for python because not only replaces references to an object it also breaks the references to the other object. Of course the old object is garbage collected and RIP. Python follows this rule very strictly. Thus means that not only that Python will not offer a live coding enviroment in the future as the basis of its implementation . It means it does not want to. It may offer it as part of its extensive library. That also leads us to the inescapable conclusion that nothing comes free, everything has a cost. Because there will be scenarios you dont want to lose your old instances or not affect them at all and instead affect only the classes or maybe you dont even want to do that and want to do something else. > So while Python has the flexibility for you to program such a system > yourself, you don't get it for free like Smalltalk. > > >> So it does have a wide application. Python can give you back the >> references to and from an object (via gc module) but the problem is that >> when an object is created its already referenced by many internal stuff so >> it can get messy soon. >> > > Smalltalk handles this for free. You need #become: > https://gbracha.blogspot.com.au/2009/07/miracle-of-become.html > Note one of the comments links to user code that apparently does the same > thing in Python. But again this is Python "allows" you to, not "Python" > gives it to you, but it could be good enough for you. > > First the python example is not an actual become the way I understand it, because not only it does not change the references to the object , it exchanges only the variables not the methods http://wargle.blogspot.gr/2009/07/smalltalks-become-in-python.html __CLASS__ is reference to the class object. __DICT__ is a reference to the instance object dictionary contains basically the names of the variables but not references to the methods themselves . Which means this wont work for live coding. His example works because both classes share the same methods with same code in them but we know this is the polar opposite of live coding. You can get references to the modified methods using this code my_class_ref = (globals()[self.__class__.__name__]) found_methods=[eval("my_class_ref()." + entry,{'my_class_ref':my_class_ref}) for entry in dir(my_class_ref()) if eval("type(my_class_ref()." + entry + ").__name__",{'my_class_ref':my_class_ref}) == 'method'] Globals is used to fetch the reference to the class object. eval is used because names are passed as strings of course and basically eval executes a string as a collection of python commands and returns its value. In this case the value is a reference to an object, a method object. Dir returns all names , including both variables and methods, instance and class, including all superclasses. You do then something similar to get the old methods , and then you iterate checking the names and replacing the references with simple assignments. You end up with a become that is I would say around , if I brake down the list comprehension to multiple lines, 20 lines of code. It wont be still a Smalltalk become but it will support live coding and live replacement of instance objects. > Plus Python is not exactly a high performance language , >> > > We now have this for improved performance... > https://hal.inria.fr/hal-01152610/file/partialReadBarrier.pdf > > Here come the two ugly words "it depends" See what the python becomes does is essentially better than the smalltalk becomes. I know its hard to not throw tomatoes at me but if you take a closer look at the Elito's paper you linked you will see why. Python solution really becomes an object to another because its swaps its contents and not the entity of the object, this includes variables and methods and the class it points to. By entity here I mean its place in memory and by you I mean the person implementing the VM. In Smalltalk becomes is not really become but rather replaceReferences , because it brakes the references to the object and then replace them with references to another object. Unfortunately this creates problems because you have to find to references to the objects and that comes with a cost if thousands of things reference it. Hence why Eliot had to optimise this. But python solution has no cost because you dont have to change the references to the object. And references to the members of an object (variables and methods) have to pass through the reference to the object itself. So python in this cases does not have to optimise,because it deals with a lot less references.. Smalltalk has to. Why Smalltalk does it this way, I do not know , this is VM territory and clearly Eliot outranks me to a great degree on the subject of VM design but I am sure there is a technical reason. > unless you use third party libraries focusing on performance (basically C >> libraries wrapped for Python). >> > > And how does such C libraries impact your live coding? Its not longer > turtles all the way down (or its turtles walking off a cliff) > Of course, the same applies for FFI with Pharo, and one of the reasons > that Smalltalk historically has been view as insular, living in its own > world avoid using non-Smalltalk libraries - because the lose of live coding > here is a big impact. > > cheers -ben > > Sorry I cannot resist :D It depends Technically speaking your are wrong not only for Python but also for Pharo too. The reason being that even in the case of imported c functions they are wrapped inside objects. So it is indeed turtles all the way down. At least to the function level. The arguments passed to the c functions itself are also objects, the access to the memory also objects, pointers are also objects. C data types also object. Of course you need VM primitives to make the actual calls but those are wrapped into objects. So yes the room is full of turtles and there is no escape for you :D Python goes an extra step with its Python C API. This is an API used to build a DLL that is compatibe with Python. Essentially Python then can import this DLL as if it was a python source code file and use it as such. Most of the Python third party libraries use this approach. Cython also uses this approach too. The API forces you to use PyObject which is a C function that wraps a C function around a Python object. So when you access it from Python its now an object. Also remember that in Python , python functions are object too. So there is no escape. I have no idea how Pharo VM does this, I know it supports plugins in a similar function and I suspect that it forces you to wrap then in Smalltalk objects at least at bytecode level but no clue if that is the actual case. Again the experts can jump in and enlighten us. Of course wrapping the C function to be called as an object does not mean that you will wrap all the functions called by the C function. If those C functions are not meant to be used by the user then they wont be objects but they will also not be accessible. Always talking about Python C API. Talking about FFI, whether Pharo (UFFI) or Python (ctypes) there is no way around object creation that I am aware of. So you cannot avoid objects even if you want to. Of couse those object does not necessarily mean they offer you all your usual comfort , they may come with some small letter disclaimers but then we go back to the never ending "it depends" rabbit hole. > > >> In my case its easy to do because I care about live coding my own project >> and do not care about code outside of it, because I wont be changing it >> anyway. But if I had to do this the Pharo way , providing a full live >> enviroment it would be easy because I would have to find a mechanism to >> accomodate for tons of Python code that does not follow live coding >> standards by a long margin. So my goal is not to come up with full blown >> live coding enviroment like Pharo does, that is simply not possible because >> there is like a ton of python code out there and I am sure there so many >> scenarios that live coding in python can go wrong that I am not even aware >> of. But if live code is only for my code and my code alone , I dont think I >> will have any major issues. Afterall even when I use Pharo I use live >> coding strictly for my code and rarely touch the enviroment with the >> exception of once messing with UI theme classes. >> >> But then again I am so new to this that at any point I may come up for a >> solution about this too, who knows :) >> >> On Wed, Oct 11, 2017 at 7:05 PM Pierce Ng <pie...@samadhiweb.com> wrote: >> >>> On Sat, Oct 07, 2017 at 01:41:17AM +0000, Dimitris Chloupis wrote: >>> > execution. Hence live coding, the Python VM replaces objects lively. >>> Python >>> > can also compile any size of code including individual methods. >>> > That happens with one line of code importlib.reload(mymodule) >>> >>> AFAIK in Python when you modify and reload source, existing instances >>> are not >>> "reshaped" to the modified code. Not live enough. Of course with Python >>> objects >>> it is easy to add per-instance inst-vars, but still this needs to be >>> scripted >>> and doesn't come free with the programming environment. >>> >>> Pierce >>> >>>
