Re: Difference in Python and Ruby interactive shells
Lou Pecora <[EMAIL PROTECTED]> wrote: > Impressive, but YIKES, there ought to be a simpler way to do this. I > think during the development phase editing and reloading would be very > common and you'd want everything updated. Sorry I missed this thread... This is what I use which is easy and works just fine. I only type it once and then press up arrow to get it back! import workinprogress; reload(workinprogress); del(workinprogress); from workinprogress import * That gives you the module and all its globals rebound. -- Nick Craig-Wood <[EMAIL PROTECTED]> -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
Peter Otten <[EMAIL PROTECTED]> wrote: > Alex Martelli wrote: > > > Michele Simionato <[EMAIL PROTECTED]> wrote: > > > >> You want this recipe from Michael Hudson: > >> > >> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 > >> > >> "automatically upgrade class instances on reload()" > > > > Note that the version in the printed Cookbook (2nd edition) was > > substantially enhanced (mostly by me and Michael working together), I > > don't know if Michael updated his ASPN recipe to reflect that but at any > > rate you can download all the code from the printed Cookbook as a > > zipfile from O'Reilly's site (sorry, I don't recall the URL). > > http://examples.oreilly.com/pythoncook2/cb2_examples.zip > > The files are named cb2_6_21_*.py, but the book has the recipe in chapter > 20.15. Ah, yes, good point: there's an "off by one" numbering issue there, due to the fact that the O'Reilly Safari online verbatim version of the book numbers the preface as "1" while the printed version doesn't, so chapter 1 in the printed version is 2.something on Safari, etc. Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
Alex Martelli wrote: > Michele Simionato <[EMAIL PROTECTED]> wrote: > >> You want this recipe from Michael Hudson: >> >> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 >> >> "automatically upgrade class instances on reload()" > > Note that the version in the printed Cookbook (2nd edition) was > substantially enhanced (mostly by me and Michael working together), I > don't know if Michael updated his ASPN recipe to reflect that but at any > rate you can download all the code from the printed Cookbook as a > zipfile from O'Reilly's site (sorry, I don't recall the URL). http://examples.oreilly.com/pythoncook2/cb2_examples.zip The files are named cb2_6_21_*.py, but the book has the recipe in chapter 20.15. Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
Thanks all for the responses. Extra kudos to Steve J and Michele S. that cleared it up for me. the context of my question comes from reading up on Lisp in "Loving Lisp - the Savy Programmer's Secret Weapon", http://www.markwatson.com/opencontent/lisp_lic.htm, where the author described building up a large system during test, that took a long to to load. He was showing one reason why a dynamic language was more productive than a statically compiled language. -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
Lou Pecora enlightened us with: > Impressive, but YIKES, there ought to be a simpler way to do this. > I think during the development phase editing and reloading would be > very common and you'd want everything updated. I hardly ever reload stuff manually during development. I write a script, and execute it. The few times I use reload() it's no big deal to do x = B(). > So why is it done the other way, the reference stays the same? Is > that useful? It's predictable. Variables point to one and the same thing, unless you manipulate them directly. > Maybe time for a 'switch' to set in Python to choose which behavior > you want. That wouldn't be pythonic. People would start using that switch in their programs too, causing a single command to act differently in each program. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
In article <[EMAIL PROTECTED]>, "Michele Simionato" <[EMAIL PROTECTED]> wrote: > You want this recipe from Michael Hudson: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 > > "automatically upgrade class instances on reload()" Impressive, but YIKES, there ought to be a simpler way to do this. I think during the development phase editing and reloading would be very common and you'd want everything updated. So why is it done the other way, the reference stays the same? Is that useful? Maybe time for a 'switch' to set in Python to choose which behavior you want. -- Lou Pecora (my views are my own) REMOVE THIS to email me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
Michele Simionato <[EMAIL PROTECTED]> wrote: > You want this recipe from Michael Hudson: > > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 > > "automatically upgrade class instances on reload()" Note that the version in the printed Cookbook (2nd edition) was substantially enhanced (mostly by me and Michael working together), I don't know if Michael updated his ASPN recipe to reflect that but at any rate you can download all the code from the printed Cookbook as a zipfile from O'Reilly's site (sorry, I don't recall the URL). Alex -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
I think reload should be preceded by import. Example: Online code modification: upon modifying and saving mytest.py issue on the interactive shell: >>>import mytest >>>reload(mytest) The shell should respond with "" (NOT:mytest.pyc) Note that modules importing mytest should not use 'import * from mytest' but 'import mytest'; This requires qualifying all objects as mytest.obj -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
You want this recipe from Michael Hudson: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164 "automatically upgrade class instances on reload()" -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
> In both languages, you can start up the interactive interpreter > ('python' and 'irb'), load source files and do stuff, like create > objects and call their methods. When you want to change something, you > can edit those same source files outside the environment and reload > them from within the interactive environment. But, here is the > difference: with Python, when you reload the source file (module in > Python terms), it seems that your existing variables stay bound to the > implementations from the old version of the module. In Ruby, after a > reload, your existing variables point to the new implementation. At > least, that is what happens with classes and their methods. This means > that in Python, if you have an application built up interactively, with > references to objects, data structures pointing to objects, etc., you > would have to reconstruct that application to get the new > implementation. With Ruby, when you load the new implementation, you > get it immediately. I don't know ruby enough to comment on _how_ they achieve that. But I know python enough to tell you that your observation is correct, and perfectly consistent with what python ususally does. The problem here stems from the fact that in python, there are names and values. The latter (also referred to as objects) can be bound to a name. Now loading a module creates class-objects, and binds them under a name - the class-name. But this name is by no means special. You can e.g. do class Foo: pass Foo = 10 That will create a class that is bound to the name Foo - and the rebind that very name to something completely different(tm). Now creating an instance of that class creates an object, that has a _reference_ to its class - not its name! Which means that there is no connection to the _name_ of that class! Well, one can get to that, because the class knows the name it was bound to when it was created - but that is only for documentary purposes. When reloading a module, a new class object is created. And bound to the name same name as before - but all instances created before keep a reference to their old class. Which makes perfect sense: in python, it is possible to create classes individually for each instance, if one wants to - by metaclasses, or factoryfunctions like this: def createClass(): class Foo: pass return Foo So - if that works, there is no way how one can know that this reloading of a module is anything special. Regards, Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
dmh2000 wrote: > I am experimenting with the interactive interpreter environments of > Python and Ruby and I ran into what seems to be a fundamental > difference. However I may be doing something wrong in Python. Please > comment and correct me if I am wrong > > In both languages, you can start up the interactive interpreter > ('python' and 'irb'), load source files and do stuff, like create > objects and call their methods. When you want to change something, you > can edit those same source files outside the environment and reload > them from within the interactive environment. But, here is the > difference: with Python, when you reload the source file (module in > Python terms), it seems that your existing variables stay bound to the > implementations from the old version of the module. In Ruby, after a > reload, your existing variables point to the new implementation. At > least, that is what happens with classes and their methods. This means > that in Python, if you have an application built up interactively, with > references to objects, data structures pointing to objects, etc., you > would have to reconstruct that application to get the new > implementation. With Ruby, when you load the new implementation, you > get it immediately. This is correct. I'm a bit fuzzy on the details, so some of this might be wrong, but here's what's going on (I'm pretty sure): When Python loads (or reloads) a module, it encounters a `class' block, which causes it to create a new type in memory. The instances created from this type are bound to the type object. This means that after a reload, your "B" class is pointing to a different object in memory. However, all of your previous instances are still bound to the old definition (which is still in memory, it's just not bound to the "B" name any more). As a simple test, do 'x.__class__ is y.__class__'. This should return False. Ruby, on the other hand, allows you to redefine classes on the fly. So when Ruby reads a 'class' block, it's either (1) redefining a previously defined object's definition, or (2) creating a new class with the definition in the block. I *think* that the reason for this is that the Python virtual machine (aka, the interpreter) is much more efficient than the Ruby VM. So if you want fast code, I'd stick with Python. However, if you regularly build large applications in memory from an interactive interpreter, then perhaps Ruby is the way for you to go. :-) Cheers. -- Steve Juranich Tucson, AZ USA -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
dmh2000 enlightened us with: > When you want to change something, you can edit those same source > files outside the environment and reload them from within the > interactive environment. But, here is the difference: with Python, > when you reload the source file (module in Python terms), it seems > that your existing variables stay bound to the implementations from > the old version of the module. IMO this is the only proper way of doing things. A variable points to something in memory. When a module is reloaded, that thing in memory is still there - because it is referenced, it does not get garbage collected. > Ruby interactive shell (irb.exe) > > C:\home\dh0072\rq>irb > > # load a local file b.py for test > > irb(main):001:0> load "b.rb" >=> true > > # instantiate an object and call a method > > irb(main):002:0> x = B.new >=> # > irb(main):003:0> x.p > B >=> nil > > # edit b.py offline to change method 'p' to do something different then > reload > > irb(main):004:0> load "b.rb" >=> true > irb(main):005:0> x.p > >=> nil > > # binding of variable 'x' IS changed. points to new version IMHO this is nasty. An assignment has already been performed. Reloading some module should not (again, IMHO) change anything that happened before it was reloaded. Sybren -- The problem with the world is stupidity. Not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? Frank Zappa -- http://mail.python.org/mailman/listinfo/python-list
Re: Difference in Python and Ruby interactive shells
dmh2000 wrote: > I am experimenting with the interactive interpreter environments of > Python and Ruby and I ran into what seems to be a fundamental > difference. However I may be doing something wrong in Python. Please > comment and correct me if I am wrong > > In both languages, you can start up the interactive interpreter > ('python' and 'irb'), load source files and do stuff, like create > objects and call their methods. When you want to change something, you > can edit those same source files outside the environment and reload > them from within the interactive environment. But, here is the > difference: with Python, when you reload the source file (module in > Python terms), it seems that your existing variables stay bound to the > implementations from the old version of the module. In Ruby, after a > reload, your existing variables point to the new implementation. At > least, that is what happens with classes and their methods. This means > that in Python, if you have an application built up interactively, with > references to objects, data structures pointing to objects, etc., you > would have to reconstruct that application to get the new > implementation. With Ruby, when you load the new implementation, you > get it immediately. I am not fully sure it is what you are speaking about, but I mean, that you have overlooked, that in the IDLE menu item [Shell] you have the option to restart the shell what takes you back to the initial state. It would be interesting to know for me here, if there is in Ruby the option to keep the old values when starting a new run? Claudio > > here is a simple example: > > --- > Python interactive shell (python.exe) > > C:\home\dh0072\rq>python > Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] > on win32 > Type "help", "copyright", "credits" or "license" for more information. > > # load a local file b.py for test > > import b > > > # instantiate an object and call a method > > x = b.B() x.p() > > B > > # edit b.py offline to change method 'p' to do something different then > reload > > reload(b) > > x.p() > > B > > # binding of variable 'x' IS NOT changed. points to old version > > y = b.B() y.p() > > B > > # new instance of 'b' points to new version > > > --- > Ruby interactive shell (irb.exe) > > C:\home\dh0072\rq>irb > > # load a local file b.py for test > > irb(main):001:0> load "b.rb" > => true > > # instantiate an object and call a method > > irb(main):002:0> x = B.new > => # > irb(main):003:0> x.p > B > => nil > > # edit b.py offline to change method 'p' to do something different then > reload > > irb(main):004:0> load "b.rb" > => true > irb(main):005:0> x.p > > => nil > > # binding of variable 'x' IS changed. points to new version > > irb(main):006:0> y = B.new > => # > irb(main):007:0> y.p > > => nil > > # new instance of 'b' points to new version > -- http://mail.python.org/mailman/listinfo/python-list