And not to worry I won’t bother with discussing such issues again it’s clear the community is unwilling to deal with such discussions. I have no problem with that , it’s a free world. On Tue, 10 Oct 2017 at 03:41, Dimitris Chloupis <kilon.al...@gmail.com> wrote:
> I never claimed that Python , which refers to CPython to the vast majority > of python coders, is offering live coding out of the box. The fact that you > have to reload modules manually would make such claims ridiculous. > > From the very first post I was crystal clear that there is a need for > creating a library that handles live coding for you and gave general > instructions of what this library will have to do. > > My claim is that Python and other languages CAN do live coding. > > I NEVER claimed also that Python is a live coding environment which it > stores in an image format. In short Python IS NOT Pharo. Period. > > Can python reload modules ? Yes > Can python trigger the debugger in case of error ? Yes > Can python replace methods and variables during execution ? Yes > Can python recompile individual methods and classes and replace their > previous instances ? Yes > Can python make you coffee ? Nope > Etc etc > > Depending how deep you want to go live coding wise your live coding > library will enlarge. > > From my experience around 100 lines of code are enough to offer most of > Pharo’s basic live coding functionality. Such task that needs to happen > only once and then simply reused in each project that wants to utilize live > coding , for my standards it is easy. It won’t be easy for a beginner > python coder cause he may not even know what OOP is. So obviously I am > referring to experienced coders. It won’t be easy if you want to fully > replicate Pharo’s live coding capabilities , because you will Definetly go > way beyond 100 lines. > > > I stated this before and I will state this again Pharo IS HANDS DOWN THE > BEST LIVE CODING ENVIRONMENT I have ever used. > > My point is that other languages CAN do what Pharo does. Even though they > are NOT live coding environments. They just have the features to be live > coding environments. > > Jython has had a lot of problems using CPython libraries, live coding is > the least of its problems. This is the reason CPython has almost the > monopoly of python coding. > > I just don’t like it when other languages are illustrated as garbage and > Pharo as the holy grail. They all have their pros and cons. > > Can’t help with Jython , I used it on the premise that I may need Java > libraries, I ended up finding what I wanted in CPython and have not touched > it since. > > My post were not made to pick a fight but rather to inform and demolish > the wrong assumptions that other languages CANNOT DO live coding. > > > If we are to compare them the least we can do is do it in a fair and > sincere way. > On Mon, 9 Oct 2017 at 20:06, webwarrior <r...@webwarrior.ws> wrote: > >> kilon.alios wrote >> > Care to explain what difficulty you experienced in live coding with >> > Python. >> > Or what Pharo can do that Python can’t live code wise ? Maybe I will >> learn >> > something. >> >> It's funny that one of main reasons why I discovered and started using >> Pharo >> was failure to get live coding working for Python (Jython in particular). >> >> And now time after time kilon.alios states that live coding in Python is >> "easy" and no big deal. >> >> I will tell you, Pharoers, about code reloading in Python, and let you >> decide for yourselves how it compares to Pharo. >> >> >> Out of the box in Python you can execute some Python code and reload >> modules >> with reload() function. >> >> What reload() does is it reads code from file (in Python each source file >> corresponds to module), executes it, and replaces reference to [that >> module] >> in current module. >> From that moment, any code in current module, when referencing reloaded >> module, will point to new version of it. >> >> All implicitly imported names will (like from foo import bar, from foo >> import *, etc.) will point to old version. Also all other modules except >> current will not be affected. >> >> There are, however, third-party libraries, that take care of it. >> >> But that's not all. All instances and subclasses of old classes will point >> to old versions of classes. >> To counter that, instead of replacing old module you could replace its >> contents by newer variables/functions and patch classes by replacing their >> contents. >> Some third-party libraries do that. >> >> That's still not all. If you store references to >> functions/methods/classes, >> that references will point to old versions. >> reimport library takes care of that, but it uses implementation-specific >> feature of CPython's GC, which lets you get all references to some object. >> Unfortunately, it doesn't work in Jython, and probably in other >> alternative >> Python implementations. >> >> But wait, what if you rename a class or function, or change its base >> class(-es)? >> You're out of luck. Theoretically you could handle such change if recent >> code change consists of a single rename, but that's it. >> >> I may have missed some other edge cases and haven't talked about tools >> support, but I hope you get the idea. >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >>
