Yes sorry for not making this clear. I was wrong in this case. A module reload will only replace class objects not instance objects. So if you create a new instance after the reload it will have the updated version but your old instance would not.
I try to test something before I make a claim but in this case I failed because I forgot the obvious. The tiny fact I was reinitialising my objects in the python project I am currently using live coding, so of course my instances were updating instantenously because I was in a loop that was recreating them every few milliseconds. When webwarrior mentioned this it draw my supisions and I tested it outside my code in the interpreter and it became obvious I was wrong. This why my reply I dont claim he is wrong and I am talking about injecting methods to old objects. I have no problem admitting when I am wrong but in this case maybe I was not clear enough considering I am responsible for exploding this thread , I hope in a good way. So yes its possible to do in Python but no it is not coming already available to you, so you can restrain yourself from abandoning Pharo for Python ;) Python is not there yet. I still keep the opinion that is easy to do , method injection is just regular assignment, you cannot get any easier than assignment but this means you have to keep track of the instances of a class and repace their methods. The good news is that if you replace just the methods and not the entire object , you can keep the references to the old instance because keeping track of the references as well would be trickier. So this way you would not brake your references and having to rebuild them to point to a new instance because you continue to use the old instance but with updated methods. You can do this also with adding / removing / editing variables and/or methods. 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. Plus Python is not exactly a high performance language , unless you use third party libraries focusing on performance (basically C libraries wrapped for Python). 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 > >
