From jorgen.stenarson at bostream.nu Wed Nov 2 15:04:05 2005 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 02 Nov 2005 21:04:05 +0100 Subject: [IPython-dev] Windows share patch Message-ID: <43691BB5.5040500@bostream.nu> Hi, The patch still works as expected for me. I have not run into any problems yet. Fernandez I think I have an idea that will make it possible for you to test the patch even if you are not on a windows network with your windows machine. By enabling sharing on some folder on your computer (do this by right clicking on the folder and choosing share (I'm not sure about the exact wording since I'm on a swedish computer)). Check the share permissions to see that there are reasonable defaults that apply to your account. Then you should be able to access that folder via an explorer window as \\COMPUTER\FOLDER. If this works then you could try it from the command prompt: cd \\COMPUTER\FOLDER will fail because UNC paths are not allowed pushd \\COMPUTER\FOLDER should work by automatically mounting a drive (e.g. Z:/Folder) popd takes you back If this works your ready to try it from IPython. This approach works for me when I'm connected to my home network (with only one apple computer on it). Of course you should be careful about leaving shared folders open for anyone to connect to. /J?rgen From Fernando.Perez at colorado.edu Wed Nov 2 15:42:58 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 02 Nov 2005 13:42:58 -0700 Subject: [IPython-dev] Windows share patch In-Reply-To: <43691BB5.5040500@bostream.nu> References: <43691BB5.5040500@bostream.nu> Message-ID: <436924D2.2090206@colorado.edu> J?rgen Stenarson wrote: > Hi, > > The patch still works as expected for me. I have not run into any > problems yet. > > Fernandez I think I have an idea that will make it possible for you to It's Fernando. Fernandez is a patronimic last name, like Stenarson :) > test the patch even if you are not on a windows network with your > windows machine. By enabling sharing on some folder on your computer (do > this by right clicking on the folder and choosing share (I'm not sure > about the exact wording since I'm on a swedish computer)). Check the > share permissions to see that there are reasonable defaults that apply > to your account. Then you should be able to access that folder via an > explorer window as \\COMPUTER\FOLDER. If this works then you could try > it from the command prompt: > > cd \\COMPUTER\FOLDER will fail because UNC paths are not allowed > pushd \\COMPUTER\FOLDER should work by automatically mounting a drive > (e.g. Z:/Folder) > popd takes you back OK, thanks for the tip. I'll test this and commit if it all works OK. Regards, f ps - you'd asked about emacs and tabs. This is what I have in my .emacs file: ;; Use spaces instead of tabs for indentation (defun indent-spaces-common-hook () (setq indent-tabs-mode 'nil)) and then make sure you run this hook for python files. From stefan at sun.ac.za Thu Nov 3 09:02:22 2005 From: stefan at sun.ac.za (Stefan van der Walt) Date: Thu, 3 Nov 2005 16:02:22 +0200 Subject: [IPython-dev] magic docstrings Message-ID: <20051103140222.GA4659@sun.ac.za> I compiled the iPython docs earlier today, and found some problems in the generated magic.tex. One problem is that LaTeX # character is not escaped, which can be easily fixed: Index: Magic.py =================================================================== --- Magic.py (revision 920) +++ Magic.py (working copy) @@ -264,7 +264,7 @@ """Format a string for latex inclusion.""" # Characters that need to be escaped for latex: - escape_re = re.compile(r'(%|_|\$)',re.MULTILINE) + escape_re = re.compile(r'(%|_|\$|#)',re.MULTILINE) # Magic command names as headers: cmd_name_re = re.compile(r'^(%s.*?):' % self.shell.ESC_MAGIC, re.MULTILINE) The more tricky problem, however, is the use of "\\" in the docstrings. In Python, you do not want "\\" in your docstrings, since they display as "\", but without the "\\" LaTeX won't print a line-feed. Then, there are a few "\n" symbols that need to be printed as is. In Python, they are correctly escaped as "\\n", but under LaTeX they need to be "\textbackslash{}n". I fixed this using @@ -274,10 +274,14 @@ # Paragraph continue par_re = re.compile(r'\\$',re.MULTILINE) + # The "\n" symbol + newline_re = re.compile('\\\\n') + str = cmd_name_re.sub(r'\n\\texttt{\\textsl{\\large \1}}:',str) str = cmd_re.sub(r'\\texttt{\g}',str) str = par_re.sub(r'\\\\',str) str = escape_re.sub(r'\\\1',str) + str = newline_re.sub(r'\\textbackslash{}n',str) return str but you might want to use a more generic solution to, for example, replace all escaped characters like \n, \t, \b. Regards St??fan From stefan at sun.ac.za Wed Nov 9 17:07:21 2005 From: stefan at sun.ac.za (Stefan van der Walt) Date: Thu, 10 Nov 2005 00:07:21 +0200 Subject: [IPython-dev] magic docstrings In-Reply-To: <20051103140222.GA4659@sun.ac.za> References: <20051103140222.GA4659@sun.ac.za> Message-ID: <20051109220721.GA20359@rajah> The problem I mention below is difficult to solve without making use of some markup. Markup tends to look ugly, but I think the ReST guys have a pretty good solution: http://docutils.sourceforge.net/rst.html This solves the problem below, since all example blocks will be clearly identifyable, and can then be processed with a LaTeX filter. St?fan On Thu, Nov 03, 2005 at 04:02:22PM +0200, Stefan van der Walt wrote: > The more tricky problem, however, is the use of "\\" in the > docstrings. In Python, you do not want "\\" in your docstrings, since > they display as "\", but without the "\\" LaTeX won't print a > line-feed. From jorgen.stenarson at bostream.nu Sat Nov 12 06:38:07 2005 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Sat, 12 Nov 2005 12:38:07 +0100 Subject: [IPython-dev] wildcard patch Message-ID: <4375D41F.9070705@bostream.nu> Hi, I have discovered a problem with the wildcard functionality. As it is written now it will only match attributes in an object that are present in its __dict__, and only if there is no __dict__ for the object it builds one by calling dir(object). This means inherited attributes will not be visible for objects with a __dict__. Which means there will be a mismatch between the results you get using dir(object) compared to ?object.* An example of this problem can be found by subclassing dict In [1]:class test(dict): ...: pass ...: In [2]:x=test(a=1) In [3]:x Out[3]:{'a': 1} Without patch In [4]:?x.* With patch In [4]:?x.* x.__class__ x.__cmp__ x.__contains__ x.__delattr__ +many more The attached patch builds the namespace by calling dir on all objects, this should make the wildcard search more consistent with dir. But the operation of dir is not well specified and may change between releases of python. So if someone feels the operation of ?* should be more well defined I'm open to suggestions on how to go about that. /J?rgen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wildcard-patch-20051112 URL: From Fernando.Perez at colorado.edu Sun Nov 13 04:32:50 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 13 Nov 2005 02:32:50 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <4375D41F.9070705@bostream.nu> References: <4375D41F.9070705@bostream.nu> Message-ID: <43770842.2090801@colorado.edu> J?rgen Stenarson wrote: > Hi, > > I have discovered a problem with the wildcard functionality. > > As it is written now it will only match attributes in an object that are > present in its __dict__, and only if there is no __dict__ for the object > it builds one by calling dir(object). This means inherited attributes > will not be visible for objects with a __dict__. Which means there will > be a mismatch between the results you get using dir(object) compared to > ?object.* Thanks for the patch. I'll apply a slightly modified version, because dir() can actually return non-strings on rare occasions (nasty as it is). The tab-completion code in ipython in fact guards against this situation, which we've seen in the wild with wrapped C++ code. In addition, I'll make the behavior of * honor the flags regarding the display of _ and __ names in tab completion. I think that ipython's mechanisms should all be consistent in this regard. Cheers, f From Fernando.Perez at colorado.edu Sun Nov 13 05:25:06 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 13 Nov 2005 03:25:06 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <43770842.2090801@colorado.edu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> Message-ID: <43771482.2070701@colorado.edu> Fernando Perez wrote: > Thanks for the patch. I'll apply a slightly modified version, because dir() > can actually return non-strings on rare occasions (nasty as it is). The > tab-completion code in ipython in fact guards against this situation, which > we've seen in the wild with wrapped C++ code. OK, I committed the patch with these extra safeties in place and some other changes. > In addition, I'll make the behavior of * honor the flags regarding the display > of _ and __ names in tab completion. I think that ipython's mechanisms should > all be consistent in this regard. Scratch this. I'd forgotten that the * system already has a flag to deal with underscores, so I left that alone. One comment: as I use this system more and more, I'm wondering if we shouldn't make the default search be case sensitive. Python is a case sensitive language, so I think that the search should by default match the language. I think it's a good idea to offer the case insensitive alternative, for when you really don't know what something may be even vaguely called, but I'm leaning towards having this facility more closely follow language defaults. I haven't committed any changes in thir regard though, so I'll be happy to hear opinions. Cheers, f From jorgen.stenarson at bostream.nu Sun Nov 13 12:12:25 2005 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Sun, 13 Nov 2005 18:12:25 +0100 Subject: [IPython-dev] wildcard patch In-Reply-To: <43771482.2070701@colorado.edu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> Message-ID: <437773F9.6040303@bostream.nu> Fernando Perez wrote: ... > One comment: as I use this system more and more, I'm wondering if we > shouldn't make the default search be case sensitive. Python is a case > sensitive language, so I think that the search should by default match > the language. I think it's a good idea to offer the case insensitive > alternative, for when you really don't know what something may be even > vaguely called, but I'm leaning towards having this facility more > closely follow language defaults. > > I haven't committed any changes in thir regard though, so I'll be happy > to hear opinions. > > Cheers, > > f > I can see your point in having a case sensitive search but I mainly use this to look for things I'm not sure about... So at this time I think I prefer case insensitive. But perhaps this should be put in ipythonrc as an option since this is certainly a matter of taste. But perhaps that work should be left for the branch. /J?rgen From Fernando.Perez at colorado.edu Sun Nov 13 15:31:35 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 13 Nov 2005 13:31:35 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <437773F9.6040303@bostream.nu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> Message-ID: <4377A2A7.3010603@colorado.edu> J?rgen Stenarson wrote: > Fernando Perez wrote: > ... > >>One comment: as I use this system more and more, I'm wondering if we >>shouldn't make the default search be case sensitive. Python is a case >>sensitive language, so I think that the search should by default match >>the language. I think it's a good idea to offer the case insensitive >>alternative, for when you really don't know what something may be even >>vaguely called, but I'm leaning towards having this facility more >>closely follow language defaults. > > I can see your point in having a case sensitive search but I mainly use > this to look for things I'm not sure about... So at this time I think I > prefer case insensitive. But perhaps this should be put in ipythonrc as > an option since this is certainly a matter of taste. But perhaps that > work should be left for the branch. OK, I propose a compromise: I'll change the default behavior to be case sensitive, but I'll also make it an ipythonrc option. That way you can set it to your liking from day one, and nothing will change for you, while we get what I think is a more 'pythonic' design (it's not just 'foolish consistency' either, I actually find it useful to query only for names with specific case more often than the insensitive version). I promise not to commit anything until I actually provide you with the rc option, so the system will never default to case-sensitive without giving you the option to get the behavior you like. Since you wrote this to begin with, I think it's the least I can do :) How does that sound? f From mantegazza at ill.fr Mon Nov 14 02:43:54 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Mon, 14 Nov 2005 08:43:54 +0100 Subject: [IPython-dev] wildcard patch In-Reply-To: <4377A2A7.3010603@colorado.edu> References: <4375D41F.9070705@bostream.nu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> Message-ID: <200511140843.55122.mantegazza@ill.fr> Le Dimanche 13 Novembre 2005 21:31, Fernando Perez a ?crit : > OK, I propose a compromise: I'll change the default behavior to be case > sensitive, but I'll also make it an ipythonrc option. That way you can > set it to your liking from day one, and nothing will change for you, > while we get what I think is a more 'pythonic' design (it's not just > 'foolish consistency' either, I actually find it useful to query only for > names with specific case more often than the insensitive version). It is ok for me (I prefer case sensitive behavior). Thank's -- Fr?d?ric From jorgen.stenarson at bostream.nu Mon Nov 14 12:28:48 2005 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Mon, 14 Nov 2005 18:28:48 +0100 Subject: [IPython-dev] wildcard patch In-Reply-To: <4377A2A7.3010603@colorado.edu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> Message-ID: <4378C950.4060401@bostream.nu> Fernando Perez wrote: > I promise not to commit anything until I actually provide you with the > rc option, so the system will never default to case-sensitive without > giving you the option to get the behavior you like. Since you wrote > this to begin with, I think it's the least I can do :) > > How does that sound? > Sounds good to me /J?rgen From Fernando.Perez at colorado.edu Mon Nov 14 15:02:07 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 14 Nov 2005 13:02:07 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <4378C950.4060401@bostream.nu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu> Message-ID: <4378ED3F.8010400@colorado.edu> J?rgen Stenarson wrote: > Fernando Perez wrote: > >>I promise not to commit anything until I actually provide you with the >>rc option, so the system will never default to case-sensitive without >>giving you the option to get the behavior you like. Since you wrote >>this to begin with, I think it's the least I can do :) >> >>How does that sound? >> > > Sounds good to me OK, glad you like that one. What comes next is worse :) I've been working on the wildcard code some, and I started to dislike the existing API a little, for consistency/maintainability reasons. The magic functions have an option parsing system based on the stdlib's getopt(), and provide uniform unix-like syntax: %cmd -opt1 -opt2 -opt_with_value=foo arg1 arg2 ... Currently, the wildcard system makes up its own unique syntax, using - both for options (c/a) and to delete namespaces from the search list. I really don't like special cases such as this, and I apologize for not having thought more carefully about this earlier. I like the functionality a lot, and I didn't want to discourage you from contributing, so I think I didn't pass a picky enough comb over the original implementation. I think we should clean this up a little, even at the cost of introducing slightly more verbose syntax. As the Zen of pyhton says: Special cases aren't special enough to break the rules. Here's a patch that begins to implement that. The docstrings aren't fixed yet, the ipythonrc option isn't implemented yet, and I'll work more on your code. But you can test it a little and let me know what you think. Now things are %psearch [-e exclude1 -s search_add1 -i -a] PATTERN [TYPESPEC] So intstead of -/+ you use -e/-s to exclude/search namespaces. Let me know what you think of this as I rework it... Cheers, f -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: wildcard_fp.patch URL: From Fernando.Perez at colorado.edu Tue Nov 15 03:55:10 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 15 Nov 2005 01:55:10 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <43790148.3030200@bostream.nu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu> <4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu> Message-ID: <4379A26E.6090300@colorado.edu> J?rgen Stenarson wrote: > I'm all for making the psearch follow the ipython convention. I'll test > your patch tomorrow. Don't bother with the patch, please update SVN. I had committed some changes earlier which inadvertedly broke badly globals handling. At this point it was easier to just finish up and commit than to try to disentangle that earlier bad patch (it wasn't all bad, as I needed part of it, but it required refining). Anwyay, the point is that rather than fight patch problems, I just went ahead and finished the wildcard rework. The only thing missing is probably a mention in the Lyx manual; the actual docstrings and code are now in place, as well as the ipythonrc support. Just add this section to your ipythonrc file: # Wildcard searches - IPython has a system for searching names using # shell-like wildcards; type %psearch? for details. This variables sets # whether by default such searches should be case sensitive or not. You can # always override the default at the system command line or the IPython # prompt. wildcards_case_sensitive 1 And set the value to 0/1 according to your liking. Let me know of any problems you encounter. Cheers, f From jorgen.stenarson at bostream.nu Tue Nov 15 12:53:06 2005 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 15 Nov 2005 18:53:06 +0100 Subject: [IPython-dev] wildcard patch In-Reply-To: <4379A26E.6090300@colorado.edu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu> <4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu> <4379A26E.6090300@colorado.edu> Message-ID: <437A2082.5010009@bostream.nu> Fernando Perez wrote: > > Let me know of any problems you encounter. > the new wildcard functionality seems to work ok. However I have found a bug that seems to have been introduced with rev 923. If there is an alias command that do not define a new alias but only lists them in the ipythonrc file then ipython crashes. Like if you just uncomment alias at the end of the ipythonrc file, I believe this used to be the default some revisions ago. I get the crash on both PC and mac. /J?rgen From Fernando.Perez at colorado.edu Tue Nov 15 13:03:41 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 15 Nov 2005 11:03:41 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <437A2082.5010009@bostream.nu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu> <4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu> <4379A26E.6090300@colorado.edu> <437A2082.5010009@bostream.nu> Message-ID: <437A22FD.4020405@colorado.edu> J?rgen Stenarson wrote: > Fernando Perez wrote: > >>Let me know of any problems you encounter. >> > > > the new wildcard functionality seems to work ok. However I have found a > bug that seems to have been introduced with rev 923. If there is an > alias command that do not define a new alias but only lists them in the > ipythonrc file then ipython crashes. Like if you just uncomment alias at > the end of the ipythonrc file, I believe this used to be the default > some revisions ago. I get the crash on both PC and mac. OK, thanks for the report. I'll look into what's going on here tonight. Cheers, f From Fernando.Perez at colorado.edu Tue Nov 15 15:25:11 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 15 Nov 2005 13:25:11 -0700 Subject: [IPython-dev] wildcard patch In-Reply-To: <437A22FD.4020405@colorado.edu> References: <4375D41F.9070705@bostream.nu> <43770842.2090801@colorado.edu> <43771482.2070701@colorado.edu> <437773F9.6040303@bostream.nu> <4377A2A7.3010603@colorado.edu> <4378C950.4060401@bostream.nu> <4378ED3F.8010400@colorado.edu> <43790148.3030200@bostream.nu> <4379A26E.6090300@colorado.edu> <437A2082.5010009@bostream.nu> <437A22FD.4020405@colorado.edu> Message-ID: <437A4427.8060600@colorado.edu> Fernando Perez wrote: > J?rgen Stenarson wrote: >>the new wildcard functionality seems to work ok. However I have found a >>bug that seems to have been introduced with rev 923. If there is an >>alias command that do not define a new alias but only lists them in the >>ipythonrc file then ipython crashes. Like if you just uncomment alias at >>the end of the ipythonrc file, I believe this used to be the default >>some revisions ago. I get the crash on both PC and mac. > > > OK, thanks for the report. I'll look into what's going on here tonight. Fixed in SVN r924. Cheers, f From pythondevdang at lazytwinacres.net Fri Nov 18 08:06:25 2005 From: pythondevdang at lazytwinacres.net (Daniel 'Dang' Griffith) Date: Fri, 18 Nov 2005 08:06:25 -0500 Subject: [IPython-dev] Interesting announcement Message-ID: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net> I've only been following the posts for ipython very passively, but I found this announcement interesting, as the subject of chaining several commands together has come up on occasion over the years. It's an interesting approach. It's licensed with GPL; I don't know if this is incompatible with the BSD license that IPython uses. Still, you might consider talking with them to see if it could be dual-licensed; I've seen a few things lately being released that way. Announcement: http://comments.gmane.org/gmane.comp.python.announce/5728 Home page: http://geophile.com/osh/ --dang From Fernando.Perez at colorado.edu Fri Nov 18 12:23:43 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 18 Nov 2005 10:23:43 -0700 Subject: [IPython-dev] Interesting announcement In-Reply-To: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net> References: <6.2.1.2.2.20051118080003.03365010@mail.jencospeed.net> Message-ID: <437E0E1F.2070600@colorado.edu> Daniel 'Dang' Griffith wrote: > I've only been following the posts for ipython very passively, but I found > this announcement interesting, as the subject of chaining several commands > together has come up on occasion over the years. It's an interesting > approach. It's licensed with GPL; I don't know if this is incompatible > with the BSD license that IPython uses. Still, you might consider talking > with them to see if it could be dual-licensed; I've seen a few things > lately being released that way. > > Announcement: > http://comments.gmane.org/gmane.comp.python.announce/5728 > Home page: > http://geophile.com/osh/ Yes, I had seen this and had a look at it a while ago. While it looks interesting, it's a bit orthogonal to ipython in that in introduces a whole new syntax which is not python: @foo [ shell command ] ^ out ... @foo is a cluster, not a decorator, [] is used to pass commands, not to retrieve sequence/mapping elemnts, etc. So while I have no doubt that this can be very handy for spreading commands over a cluster, it's not really python anymore. Additionally, it is not interactive, but rather a one-shot executable (it's a bit strange that the homepage is titled 'Osh - Object oriented shell', but the second paragraph starts with 'osh is not a shell'). The chainsaw branch of ipython implements cluster/parallel support, but within the ipython framework. I personally prefer the idea of keeping the full python language as is, and providing suitable localized extensions to help system interaction, rather than trying to reinvent yet another whole new language. Going that route is ill-advised, IMO, because it requires users to learn yet another set of syntax and rules which are orthogonal to those of python, and also because it's highly unlikely that you'll do a better job at language design than Guido and the whole python community. Specialized mini-languages do have a place, but they carry a price (time and cognitive load, to begin with). I don't think this is a context where the price is worth paying. In addition, his restriction to non-interactive, command-line usage makes the system somewhat limited in my view. For any system where the price of learning is worth paying, you want to be able do do complex things. That inevitably means looping, logic, branching, etc; all things that require more than single-line input. So while I like the core idea of 'piping python objects', I'm not sure that I personally would have made the specific implementation decisions of Osh. For that same task (quickly spreading commands to a cluster) I long ago wrote my own little (very limited) python script which satisfies my needs. I am sure that Osh can be very useful, and I really don't want this post to sound like I'm bashing it in any way. I had it bookmarked already, and I'll keep an interested eye on its evolution. I just wanted to provide some clear reasons why at this point, I don't see too many points of contact with ipython. Cheers, f From vivian at vdesmedt.com Sun Nov 27 07:15:51 2005 From: vivian at vdesmedt.com (Vivian De Smedt) Date: Sun, 27 Nov 2005 13:15:51 +0100 Subject: [IPython-dev] Debugger patch Message-ID: <4389A377.1010608@vdesmedt.com> Fernando, Few times ago I send to the IPython mailing list a patch proposition that in my opinion improve the python debugger usability in the spirit of IPython. - it make the completion working when IPython run in debugger mode, - it colorize Python stack the same way IPython do for Exception stacks, - it hide some of the stack level that that do not belong to the script being debugged (actually IPython levels not relevant for the developper) I was wondering if you still think it is worth valuable addition and if you plan to merge it into the IPython code? Since it impact more that one files you could consider the integration as a long task. If it these kind of considerations that slow down the integration of the patch I'll be glad to split my patch by feature to make the integration process more transparent and less stressful :-) Tell me if I can help. Kindest regards, Vivian. From mantegazza at ill.fr Mon Nov 28 05:35:22 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Mon, 28 Nov 2005 11:35:22 +0100 Subject: [IPython-dev] Getting executed code Message-ID: <200511281135.22399.mantegazza@ill.fr> Hello, Is there a way to retreive the currently executed code ? The ipshell.buffer contains the code, but in the case of a multiline code, how can I know what is the current line executed, in my custom exception handler ? -- Fr?d?ric From mantegazza at ill.fr Tue Nov 29 07:21:57 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Tue, 29 Nov 2005 13:21:57 +0100 Subject: [IPython-dev] IPython prompt delay Message-ID: <200511291321.57840.mantegazza@ill.fr> Hello Ferndando, Is possible to add a short fixed delay before the prompt is printed again, after some code has been executed ? Where can I add it in the 0.6.15 version code ? Thank's, -- Fr?d?ric From Fernando.Perez at colorado.edu Tue Nov 29 15:08:51 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 29 Nov 2005 13:08:51 -0700 Subject: [IPython-dev] IPython prompt delay In-Reply-To: <200511291321.57840.mantegazza@ill.fr> References: <200511291321.57840.mantegazza@ill.fr> Message-ID: <438CB553.9060405@colorado.edu> Fr?d?ric Mantegazza wrote: > Hello Ferndando, > > Is possible to add a short fixed delay before the prompt is printed again, > after some code has been executed ? Where can I add it in the 0.6.15 > version code ? The prompt system is fully dynamic, so the easiest way is to insert a time.sleep() call into your prompt :) Alternatively, you can override the prompt's display() method, but that's a little bit more work. Cheers, f From Fernando.Perez at colorado.edu Tue Nov 29 15:20:02 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 29 Nov 2005 13:20:02 -0700 Subject: [IPython-dev] Debugger patch In-Reply-To: <4389A377.1010608@vdesmedt.com> References: <4389A377.1010608@vdesmedt.com> Message-ID: <438CB7F2.3080202@colorado.edu> Hi Vivian, Vivian De Smedt wrote: > Fernando, > > Few times ago I send to the IPython mailing list a patch proposition > that in my opinion improve the python debugger usability in the spirit > of IPython. > > - it make the completion working when IPython run in debugger mode, > - it colorize Python stack the same way IPython do for Exception stacks, > - it hide some of the stack level that that do not belong to the script > being debugged (actually IPython levels not relevant for the developper) > > I was wondering if you still think it is worth valuable addition and if > you plan to merge it into the IPython code? > > Since it impact more that one files you could consider the integration > as a long task. > If it these kind of considerations that slow down the integration of the > patch I'll be glad to split my patch by feature to make the integration > process more transparent and less stressful :-) I'll certainly be happy to integrate this into ipython, and splitting it into reasonable chunks will help me a lot. As I mentioned to you, hacking pdb is quite unpleasant, so this may take some effort. The current status with ipython is that we have a fair amount of new things sitting in SVN, so at some point I should make a new release. All new work is going to take place on the chainsaw branch, but I plan on picking pieces from trunk to put in there rather than refactoring wholesale: this will lead to a cleaner design, I hope. It also means that I'm less worried about keeping the current codebase alive for a while, since I won't try to make full merges: the new code is being structured very differently, and I'm only pulling the good pieces out of the existing one. For a new release, Ville's patch is still in the queue, along with anything you may submit. I have all of Jorgen's wildcard work already committed, and a few more things sitting on my Inbox that need to be looked at and committed as well. So in summary: send it in, but broken into small pieces. Please keep the guidelines from: http://projects.scipy.org/ipython/ipython/wiki/DeveloperGuidelines in mind when you make the patches. They are simple, and meant to keep all of us working on code rather than dealing with patch mixups. Cheers, and many thanks for the interest in tackling a beast as nasty as pdb! f From Fernando.Perez at colorado.edu Tue Nov 29 15:22:11 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 29 Nov 2005 13:22:11 -0700 Subject: [IPython-dev] Getting executed code In-Reply-To: <200511281135.22399.mantegazza@ill.fr> References: <200511281135.22399.mantegazza@ill.fr> Message-ID: <438CB873.50409@colorado.edu> Fr?d?ric Mantegazza wrote: > Hello, > > Is there a way to retreive the currently executed code ? The ipshell.buffer > contains the code, but in the case of a multiline code, how can I know what > is the current line executed, in my custom exception handler ? At that point, you need to use python's exception inspection machinery. IPython feeds entire blocks for execution to the interpreter, so it can't know at what line the error occurred. But that information is stored in the traceback objects, so you can retrieve it. Look at ultraTB.py for details of how ipython builds that information for display. Cheers, f From mantegazza at ill.fr Wed Nov 30 03:46:59 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Wed, 30 Nov 2005 09:46:59 +0100 Subject: [IPython-dev] Getting executed code In-Reply-To: <438CB873.50409@colorado.edu> References: <200511281135.22399.mantegazza@ill.fr> <438CB873.50409@colorado.edu> Message-ID: <200511300947.00276.mantegazza@ill.fr> Le Mardi 29 Novembre 2005 21:22, Fernando Perez a ?crit : > > Is there a way to retreive the currently executed code ? The > > ipshell.buffer contains the code, but in the case of a multiline code, > > how can I know what is the current line executed, in my custom > > exception handler ? > > At that point, you need to use python's exception inspection machinery. > IPython feeds entire blocks for execution to the interpreter, so it can't > know at what line the error occurred. But that information is stored in > the traceback objects, so you can retrieve it. Look at ultraTB.py for > details of how ipython builds that information for display. Ok, thanks. -- Fr?d?ric From mantegazza at ill.fr Wed Nov 30 06:57:32 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Wed, 30 Nov 2005 12:57:32 +0100 Subject: [IPython-dev] IPython prompt delay In-Reply-To: <438CB553.9060405@colorado.edu> References: <200511291321.57840.mantegazza@ill.fr> <438CB553.9060405@colorado.edu> Message-ID: <200511301257.33338.mantegazza@ill.fr> Le Mardi 29 Novembre 2005 21:08, Fernando Perez a ?crit : > The prompt system is fully dynamic, so the easiest way is to insert a > time.sleep() call into your prompt :) You mean like this : argv = ["-pi1", "${time.sleep(0.2)}PyMAD>>> ", "-po", " ", "-profile", "pymad"] ipshell = IPShellEmbed(argv) It works, but it displays 'None' before PyMAD. It is because time.sleep() returns None, I presume. How can I make it return an empty string, instead ? -- Fr?d?ric From Fernando.Perez at colorado.edu Wed Nov 30 13:05:58 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Wed, 30 Nov 2005 11:05:58 -0700 Subject: [IPython-dev] IPython prompt delay In-Reply-To: <200511301257.33338.mantegazza@ill.fr> References: <200511291321.57840.mantegazza@ill.fr> <438CB553.9060405@colorado.edu> <200511301257.33338.mantegazza@ill.fr> Message-ID: <438DEA06.3010106@colorado.edu> Fr?d?ric Mantegazza wrote: > Le Mardi 29 Novembre 2005 21:08, Fernando Perez a ?crit : > > >>The prompt system is fully dynamic, so the easiest way is to insert a >>time.sleep() call into your prompt :) > > > You mean like this : > > argv = ["-pi1", "${time.sleep(0.2)}PyMAD>>> ", > "-po", " ", > "-profile", "pymad"] > ipshell = IPShellEmbed(argv) > > It works, but it displays 'None' before PyMAD. It is because time.sleep() > returns None, I presume. How can I make it return an empty string, > instead ? Wrap it: def mysleep(t): time.sleep(t) return '' Cheers, f