On Tue, 10 Oct 2017 at 03:41, Dimitris Chloupis <kilon.alios@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 <reg@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