major mistake i meant to say "providing a full live enviroment it would NOT be easy because I would have to find a mechanism to accomodate for tons of Python code that does not follow live coding standards "
On Wed, Oct 11, 2017 at 8:08 PM Dimitris Chloupis <kilon.al...@gmail.com> wrote: > 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 >> >>
