On Thu, Oct 12, 2017 at 1:08 AM, 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 replace their methods. > This is what Smalltalk gives you for free. > 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 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. > 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 > 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 > 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 >> >>
